Improve error handling for rd.live.ram=1 when image does not fit into RAM

[fenixleon]

Describe the bug
Passing the parameters vmlinuz initrd=initrd.img root=live:CDLABEL=Fedora-WS-Live-35-1-2 rd.live.image rd.live.check rd.live.ram=1 or vmlinuz initrd=initrd.img root=live:CDLABEL=Fedora-WS-Live-35-1-2 rd.live.image rd.live.check rd.live.ram results with the system halting. The system starts the boot process with no errors and returns The media check is complete, the result is: PASS, followed by Copying live image to RAM, (this may take a minute) and ends with a system halt message.

Passing the parameters vmlinuz initrd=initrd.img root=live:CDLABEL=Fedora-WS-Live-35-1-2 rd.live.image rd.live.ram nomodeset rhgb ends with the same issue of the system halting.

Starting Fedora Workstation Live 35 boots successfully.

Distribution used
Fedora 35 Workstation

Dracut version
055-5.fc35

Init system
systemd 249 (v249.4-2.fc35)

To Reproduce

• Plug USB into laptop/PC
• Press tab
• Add rd.live.ram=1 or rd.live.ram parameters

Expected behavior

• System to boot cleanly
• Ability to remove USB and for the system to run in RAM only.

Additional context
kernel - 5.14.10-300.fc35.x86_64
architecture - x86_64 64 bits
machine - HP Pavilion dv6 Notebook PC
BIOS or Legacy mode only. No EFI/UEFI support

[johannbg]

Hmm sounds more like the live image has dropped the script that supported this ( the boot to ram option on live images got removed like a decade ago but the workaround rd.live.ram kept in place ), @Conan-Kudo are you aware of any changes that involve removed the rd.live.ram support on live images in Fedora?

[fenixleon]

@johannbg, the DRACUT.CMDLINE(7) Manual Page suggests that it's still a dracut kernel command line option.

[johannbg]

@fenixleon that it's an available kernel commandline option does not mean that the script that are/were? used to make use of that available kernel command line option are still present on the live image that is being create in Fedora.
I suggest you create a bug downstream in Fedora then those that are responsible for that live image creation will move it here upstream if it's actually our bug.

[johannbg]

Also you should try this with older/newer Fedora images to narrow down when it broke in Fedora which will help them ( or us if our bug ) to narrow down what might be the root cause for this but I suspect this simply have been deprecated in downstream Fedora by the team responsible for the live images you are using.

[Conan-Kudo]

Hmm sounds more like the live image has dropped the script that supported this ( the boot to ram option on live images got removed like a decade ago but the workaround rd.live.ram kept in place ), @Conan-Kudo are you aware of any changes that involve removed the rd.live.ram support on live images in Fedora?

Not that I know of. I didn't even know about rd.live.ram...

[johannbg]

@Conan-Kudo from quick googling it has been broken since atleast F32 which would mean dracut <=50 but I suspect changes have been made to squashfs-tools at that time ( F32 or earlier ) that broke this in Fedora. If it was something broken with us I'm pretty sure the KIWI NG team would have pinged us about it by now ( or any vendor that supports deploy and running a system in a ram disk which would be using this )

[fenixleon]

@johannbg , I'm guessing this is a known issue now? If yes, I'm assuming that you and the team will explore it further and there is no further action for me?

[johannbg]

@fenixleon As I mentioned earlier you need to file a bug with the team at Fedora that creates the live media you are having problem with. If and then when that team has tracked this to a regression in dracut we will look into it until then we do nothing since from the looks of it the issue you are experiencing has nothing to do with dracut and this has been broken in Fedora since atleast F32 if not earlier ( but seems to be working fine for other vendors ).

[fenixleon]

@johannbg, sure if you can guide me where I should raise it.

[johannbg]

You are using Fedora so that's where you should raise it, downstream with Fedora, with the team that created that live media for you so raise an issue with the Fedora workstation working group. They will have the individuals that are responsable for creating the live media look into that as well as look into if they want to (continue?) support rd.live.ram for future Fedora workstation images.

[fenixleon]

There're a few Fedora repositories so if you can guide/confirm, that'd be great.

[bcling]

rd.live.ram is still supported, but post-Fedora 32, memory requirements increased by 2.5x (Fedora 32 booted on 4 GB, Fedora 33+ required 10 GB). The failure occurs after an interrupted squashfs copy to RAM as a result of insufficient ram disk space.

The 2.5x increase appears to be across the board, and would indicate that compression was not set.

[LaszloGombos]

Is this issue even in scope for dracut ?

The failure occurs after an interrupted squashfs copy to RAM as a result of insufficient ram disk space.

Perhaps dracut can improve the error message when this would happen ?

[Conan-Kudo]

The 2.5x increase appears to be across the board, and would indicate that compression was not set.

Fedora live media currently doesn't use plain squashfs yet. It's still a filesystem wrapped in a disk image, so it's not compressible the normal way. Something to explore, I suppose...

[LaszloGombos]

Thanks @Conan-Kudo ..

Fedora live media ...Something to explore, I suppose...

Sure, but this exploration would not happen in the dracut project, would it ? I am just trying to understand what action remains here for the dracut project that is not Fedora specific.

[Conan-Kudo]

Probably the only thing would be providing a more useful error message? Beyond that, this is pretty much an issue with how the live media works rather than a dracut issue itself.

[LaszloGombos]

related new issue - #2550