#8646 Create Fedora LiveOS images using plain squashfs root filesystem
Opened 2 years ago by chrismurphy. Modified 2 years ago

  • Describe the issue

Currently all Fedora images have a squashfs.img that is squashfs, with an embedded image file that contains an ext4 filesystem on which exists the root file system for booting. Ext4 was chosen in order to make the root file system read/write, where squashfs is read-only. But using overlayfs, it's no longer necessary to depend on a nested ext4 system.

Anaconda now has a feature to support creating a plain squashfs root file system, and dracut has all the parts to support assembly during boot as well. We should use it.


  • When do you need this? (YYYY/MM/DD)


  • When is this no longer needed or useful? (YYYY/MM/DD)

Some time before the heat death of the universe

  • If we cannot complete your request, what is the impact?

Not the end of the world. The problems with the existing device-mapper based overlay are ugly but well known.

The existing nested ext4 on squashfs might be contributing to #8581.

  • Additional info

If/when this change happens, it affects livecd-tools's l-i-t-d feature for creating media with persistent overlays. Track coordination in this issue so they aren't caught surprised.

I posted sizes for various mksquashfs outputs in #8581, relevant to this issue is dropping the nested ext4 image reduces the size of the image by about 3%. And it also drops the consumer side /dev/loop1 CPU hit by 1/3; with this change it's necessary to profile /dev/loop0 (there is no loop1), and it never goes above 10% CPU. Details in:

I can confirm inserting this plain squashfs.img into the ISO startsup without any changes, automatically using overlayfs. And once the following change appears in Fedora, which I just tested, Anaconda will also understand it.

The gotcha right now, is even with level 22 selected, block size 256K, and plain squashfs image, the resulting squashfs.img is ~5% bigger than the current squashfs.img method. I think I know why, and have filed a bug here:


NOTE: That means all "level 22" sizes mentioned before 20190818 might actually be level 19.

Two added advantages of plain squashfs (overlayfs) over nested ext4 (device-mapper):

-We're no longer limited to the baked in ext4 rootfs size, which right now limits debugging the environment. Anything requiring installation of debuginfos exceeds this space quickly. Instead the limit depends on the backing device: either RAM or an independent persistent file system layered using overlayfs.

-Folks depending on persistent write media, SoaS, and others using livecd-iso-to-disk, no longer get the inevitable blowup and corruption of their root file system, necessitating reset. Note lines 116-126.

So, I am not sure what you want releng to do here.

Decide if we want to move to this? It sounds like it has a lot of advantages. So, perhaps we try it out in rawhide and give a long ramp to the f32 release?

Is the default going to change or will we need to pass livemedia-creator something? (if so, might need some koji changes).

The default isn't going to change anywhere. Fedora would need to make the change, by using livemedia-creator --squashfs-only

The two changes needed to support it are these PRs, but I'm not sure what version of lorax and anaconda contain those changes.


It is valid to consider #8646 and #8581 together or separately, but I figured on separate just because it might be easier to troubleshoot any face plants. And also get a more clear picture of the size and time increase on the compose side, and see if those are acceptable tradeoffs for consumer side CPU reduction and performance improvements.

The default isn't going to change anywhere. Fedora would need to make the change, by using livemedia-creator --squashfs-only

Which means we need koji changes, because we use pungi that in turn just calls koji to make the live media.

So, either we need to change the default in koji, or koji needs to grow a way for us to configure this. Can you open a koji ticket? Or would you like me to do so?

Small clarification: this presently will affect so-called "Live" ISOs only, not netinstall or DVD.

Metadata Update from @kevin:
- Issue tagged with: backlog

2 years ago

Metadata Update from @amoloney:
- Custom field blockedby adjusted to https://pagure.io/koji/issue/1622

2 years ago

This issue is blocked by https://pagure.io/koji/issue/1622 before it can be resolved.

Login to comment on this ticket.