On Mon, Jan 20, 2020 at 4:24 AM Adam Williamson
On Sun, 2020-01-12 at 15:02 -0700, Chris Murphy wrote:
> Do you have any tests to compare plain squashfs xz with zstd? The nested
> ext4 stuff is really pointless now because Fedora hasn't used 'dd' +
> resizing the ext4 file system as an installation method in a long time
> (going back to Fedora 18 I think). All of the Live installations use rsync.
I am not entirely clear on what this proposal covers (it would actually
be nice if this was specified on the Change page; it's not immediately
clear *which of Fedora's images* are affected by this Change), but are
you sure of this? Do we not do it even for Cloud image deployments or
ARM disk image deployments? ISTR there being a filesystem resize
involved there, which is why I ask...
Cloud images don't use squashfs so they can be ignored. (But yes, some
cloud related images do fs resize on first boot.)
With one exception , all ISO images I've looked at have a squashfs
image file on them containing a LiveOS used as system root. If the
change proposal implements plain squashfs images, startup assembly
will use overlayfs. The current ISOs have a nested ext4 in that
squashfs image, and startup assembly uses device-mapper.
Also with one exception , any ISO with the word "Live" in the
filename, might switch from rsync based installation to unsquashfs.
The netinstalls and DVD ISOs are unaffected.
Fedora CoreOS, fedora-coreos-31.20200113.3.1-live.x86_64.iso
(congratulations on the final release btw), which has an initramfs
based LiveOS, uses dd for installation, with ignition doing
provisioning on first boot that also includes GPT fixup and fs resize.