Created attachment 1847797 [details] wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error. Please check the attached screenshot. dracut-initqueue: mount: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error. dracut: FATAL: failed to find a root filesystem on /run/initramfs/squashed.img. dracutRefusing to continue.
The Cinnamon spin also doesn't work with the option. Let's try "vanilla".
The default workstation image (Fedora-Workstation-Live-x86_64-35-1.2.iso) doesn't boot with the same errors.
I've given the VM 8GB of RAM which should be plenty.
Does this package have maintainers? Anyone? Does anyone care? Is this a bug tracker or just a useless website no one attends to?
Fedora is a community project anyone can contribute to. Feel free to send a PR, if you think it's a packaging issue: https://docs.fedoraproject.org/en-US/ci/pull-requests/ Also, there's a project upstream, in which you can help fix or file an issue: https://github.com/dracutdevs/dracut/ Lastly, your bug report is missing a dracut version (nvr), proper steps to reproduce (apart from the subject - but come on, is it that hard to write it clearly, in case there's a new maintainer who tries to find his way? Not everyone is and expert.), and a sosreport would be helpful as well: https://fedoraproject.org/wiki/How_to_debug_Dracut_problems On the matter, my first guess would be that some executable might be missing for it to work - like the decompression algorithm. Feel free to experiment, add it, regenerate dracut and let us know! Example: https://github.com/dracutdevs/dracut/pull/1545/
Created attachment 1871575 [details] Expected rdsosreport from Fedora 35 Live Workstation
Created attachment 1871576 [details] Actual rdsosreport from Fedora 35
Error appears to have been introduced between Fedora 32 and Fedora 33, and continues through Fedora 35. dmsquash-live-root attempts to mount /run/initramfs/squashed.img and fails to mount because /run/initramfs/squashed.img created by rd.live.ram is corrupted in Fedora 33 (and 35). Manual attempts to mount from emergency mode with dmsquash-live-root generate the same errors. Analysis of rd.live.ram created squashed.img files from Fedora 32, 33, and 35 Live Workstation disks show that Fedora 32 unpacks as expected with unsquashfs, but both Fedora 33 and Fedora 35 generate this error when analyzing the files offline: # unsquashfs squashed.img Read on filesystem failed because EOF FATAL ERROR: File system corruption detected Fedora 35 is running dracut 055-5.fc35 I migrated ahead to dracut 56 (on Fedora 35) and it still has this issue. rdsosreports from Fedora 32 (expected behavior) and Fedora 35 (failure behavior) attached.
Disregard attachments - I discovered the underlying problem - those squashed.img files are truncated because ram disk space is full. Fedora 32 only required *4 GB* for rd.live.ram (dracut 50). Subsequent Fedora Workstation spins (33-36 Beta) require *10 GB* RAM. What needs to be done to reduce memory usage on initial boot?
I ran livecd-creator to generate a 4 GB spin that previously required 8 GB RAM. Now it requires 20 GB RAM. Compared with the above numbers, there's a 2.5x increase in RAM requirements, and supports Pavel's comment above, except it appears *compression* is missing. I looked but couldn't find where this occurs - any pointers will be appreciated to help resolve this.
This message is a reminder that Fedora Linux 35 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '35'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 35 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 35 entered end-of-life (EOL) status on 2022-12-13. Fedora Linux 35 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.
tip for Artem S. Tashkinov
*** Bug 2156004 has been marked as a duplicate of this bug. ***
Artem S. Tashkinov 2022-12-23 11:07:20 WET Created attachment 1934245 [details] [https://bugzilla.redhat.com/attachment.cgi?id=1934245] Boot error Fedora 37 is equally affected.
Created attachment 1973708 [details] Fedora 38 failure Fedora 38 fails too. Does anyone care? Why does this option exist?
The bug will soon be 3 years of age.
> Does anyone care? no I tried reproduce and understand this bug once ... why rd.live.ram=1 is needed or wanted and what benefits have it ?
with Fedora-Workstation-Live-x86_64-38-1.6.iso, I see the error you mention here , is an error only in live images , I guess. But without any grub entry change, it boots fine with 2 gigas of RAM !
(In reply to Sergio Basto from comment #18) If this option is no longer supported, I politely request to remove it. Thank you. Your questions sound preposterous coming from a package maintainer. It's your job to know why the option is there and what it does. This option makes dracut load the entire boot image into RAM, so that everything works faster. It is specially important for DVD and slow flash sticks users. DVD random seek times can be as slow as a few seconds which makes booting off a DVD super slow.
I'm VirtualBox maintainer and not dracut maintainer, (In reply to Artem S. Tashkinov from comment #20) > (In reply to Sergio Basto from comment #18) > > If this option is no longer supported, I politely request to remove it. It boots well on a normal instalation , only fails on Live isos > Thank you. > > Your questions sound preposterous coming from a package maintainer. It's > your job to know why the option is there and what it does. > > This option makes dracut load the entire boot image into RAM, so that > everything works faster. It is specially important for DVD and slow flash > sticks users. > > DVD random seek times can be as slow as a few seconds which makes booting > off a DVD super slow. thanks for information , I think I can't help further ...
This is unrelated to VirtualBox, you need to give it 2.5 times more memory than expected if you enable rd.live.ram for a live boot, whether in a VM or a physical machine. The released ISOs should boot for you with this option on a 10 GB machine. Going back to an earlier comment, sometime after dracut 50, squashed.img was no longer compressed effectively and expanded by 2.5 times its previous size - tested with several custom spins created with livecd-creator. This option enables users to boot many machines in sequence with one (or few) boot media, and provides lower latency for commands since it is loaded into memory. It also frees up DVD drives or ports - critical on laptops for output instead of keeping the boot media attached. I have used this option regularly for hundreds (if not thousands) of boots since it was introduced, please keep the option and let’s get it fixed (yes, someone cares).
Hi, Sorry for a long delay, I just drop a few notes that I collected , which ssems to be similar problems https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org/thread/VZCR3BZMUJNIFAZTPMIXRHTYQBK3H54G/ https://bugzilla.redhat.com/show_bug.cgi?id=1019440#c6 To get back the old behavior I did this set of things (don't know for sure they are all necessary, but they do work): 1. Create the file /etc/modules-load.d/loop.conf that just contains the word "loop" on a line by itself. This makes sure systemd arranges for the loop module to be loaded. 2. Create the file /etc/modprobe.d/eightloop.conf that contains the line: options loop max_loop=8 Despite the name, that makes the min number of loop devices by 8 (which was the default kernel setting before they changed it). 3. Run (as root) "dracut --force" to rebuild the initrd with the new module options included. 4. Reboot and see 8 loop devices pre-created in /dev
Upstream PR - https://github.com/dracutdevs/dracut/pull/2551
merged upstream https://github.com/dracut-ng/dracut-ng/pull/17
This message is a reminder that Fedora Linux 38 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 38 on 2024-05-21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '38'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 38 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Hopefully it's gonna be fixed in Fedora 41.