rd.live.overlay.overlayfs=1 is broken on Fedora 39 LiveOS about dracut

[FGrose]

The 2 problems you identified at the top are fixed in an update of Fedora 39 such as in the live-respin, https://dl.fedoraproject.org/pub/alt/live-respins/F39-WORK-x86_64-LIVE-20240401.iso
Those problems are not related to the rd.live.overlay.overlayfs option.

The dracut documentation #Booting live images is incomplete. It should rather say:

SquashFS (read-only) base filesystem image
Note — There are 3 separate overlay types available:

• Device-mapper snapshots (the original offering),
• Device-mapper thin provisioning snapshots (see rd.live.overlay.thin,
  a later offering), and
• OverlayFS based overlay mounts (a more recent offering).

Using one of these technologies, the system will provide a writable overlay for
the base, read-only SquashFS root filesystem. These methods enable a relatively
fast boot and lower RAM usage.

With the original Device-mapper snapshot overlay, users must be careful to
avoid writing too many blocks to the snapshot device. Once the blocks of the
snapshot overlay are exhausted, the whole root filesystem becomes read-only
leading to application failures. The snapshot overlay device is marked
'Overflow', and a difficult recovery is required to repair and enlarge the
overlay offline.

When rd.live.overlay= is not specified for persistent overlay storage, or
the specified file is not found or writable, a Device-mapper snapshot based
non-persistent or temporary overlay is automatically created as a sparse file
in RAM of the initramfs. This file will only consume content space as required
blocks are allocated. This snapshot based overlay defaults to an apparent size
of 32 GiB in RAM, and can be adjusted with the rd.live.overlay.size= kernel
command line option. This file is hidden (and appears deleted) when the boot
process switches out of the initramfs to the main root filesystem but its loop
device remains connected to the Device-mapper snapshot.

Even with large Device-mapper overlay files for write space, the available root
filesystem capacity is limited by the total allocated size of the base root
filesystem, which often provide only a small number of gigabytes of free space.

This shortage could be remedied by building the root filesystem with more
allocated free space, or the OverlayFS based overlay mount method can be used.

When the rd.live.overlay.overlayfs option is specified or when
rd.live.overlay= points to an appropriate directory with a sister at
/../ovlwork, then an OverlayFS based overlay mount is employed. Such a
persistent OverlayFS overlay can extend the available root filesystem storage
up to the capacity of the LiveOS disk device.

For non-persistent OverlayFS overlays, the /run/overlayfs directory in the
/run tmpfs is used for temporary storage. This filesystem is typically sized
to one half of the RAM total in the system.
The command: mount -o remount,size=<nbytes> /run will resize this virtual
filesystem after booting.

Cross reference link dracut-ng/dracut-ng#137

[mahdiaqallal]

Food for thoughts: couldn't it be related with SELinux rules because of the folders where /run/overlayfs stores all modified files and directories after thoses unpacked from squashfs in the live boot ?

I found this thread in Fedora Discussion and this and that bugzilla report

Can't be sure if it helps or not, it is well beyond my understanding

I didn't use any of the livecd-tools to reproduce this issue. The Fedora 39 LiveOS was directly written into an usb using following command
sudo dd if=/<path-to-Fedora 39 LiveOS.iso> of=/dev/sdb

Then the usb drive was booted and it's grub.cfg modified according to my description above

FYI: livecd-tools can't be used as of Fedora 39 and since Fedora 35+ because the structure of the .iso files has been changed and an appropriate release still needs to be available from the official Fedora repos. see this issues livecd-tools/livecd-tools#244 and livecd-tools/livecd-tools#253 in livecd-tools repository

[mahdiaqallal]

@FGrose : thanks for your reply .
It might need some elaboration though:

Which kernel command line parameter is needed to activate on a Fedora Worsktation Live .ISO, the "Device-mapper snapshot based non-persistent overlays":

Device-mapper snapshot based non-persistent overlays are
sparse files in RAM that only consume content space as required blocks are
allocated. These snapshot based overlays default to an apparent size of 32 GiB
in RAM.

Regarding live-respins

The 2 problems you identified at the top are fixed in an update of Fedora 39 such as in the live-respin, https://dl.fedoraproject.org/pub/alt/live-respins/F39-WORK-x86_64-LIVE-20240401.iso

Are live-respins natively corrected for rd.live.overlay.overlayfs=1 ?
Does this mean that on Fedora 40 Worsktation Live ISO the bug for rd.live.overlay.overlayfs=1 is fixed too ?

I'll try soon sudo mount -o remount,size=70% /run (on 32GiB RAM laptop) on Fedora 40 Workstation LIve ISO and will provide feedback

[mahdiaqallal]

@FGrose Thanks for updating the man page.
Please it needs some enhancement like examples for the two use cases below so I can test it on Fedora 40beta Workstation LIve ISO command line parameters and provide feedback

What are the minimal kernel command line parameters to activate (on a freshly created Fedora 40beta Workstation Live USB):

1. Temporary in memory ove
   OR
2. Permanent boot reristant on disk overlay (provided a dedicated vfat or ext4 or btrfs partition has been created)