Bug 2035641 - Fedora live images cannot be booted with rd.live.ram=1 due to dracut errors
Summary: Fedora live images cannot be booted with rd.live.ram=1 due to dracut errors
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: dracut
Version: 40
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: dracut-maint-list
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 2156004 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-12-26 10:58 UTC by Artem S. Tashkinov
Modified: 2024-05-07 15:47 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 2156004 (view as bug list)
Environment:
Last Closed: 2024-05-07 15:47:04 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error. (23.45 KB, image/png)
2021-12-26 10:58 UTC, Artem S. Tashkinov
no flags Details
Expected rdsosreport from Fedora 35 Live Workstation (65.36 KB, text/plain)
2022-04-09 06:33 UTC, bcling
no flags Details
Actual rdsosreport from Fedora 35 (4.00 KB, text/plain)
2022-04-09 06:34 UTC, bcling
no flags Details
Fedora 38 failure (20.63 KB, image/png)
2023-07-02 06:50 UTC, Artem S. Tashkinov
no flags Details

Description Artem S. Tashkinov 2021-12-26 10:58:13 UTC
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.

Comment 1 Artem S. Tashkinov 2021-12-26 11:09:06 UTC
The Cinnamon spin also doesn't work with the option. Let's try "vanilla".

Comment 2 Artem S. Tashkinov 2021-12-26 11:20:18 UTC
The default workstation image (Fedora-Workstation-Live-x86_64-35-1.2.iso) doesn't boot with the same errors.

Comment 3 Artem S. Tashkinov 2021-12-26 11:21:26 UTC
I've given the VM 8GB of RAM which should be plenty.

Comment 4 Artem S. Tashkinov 2022-03-31 13:51:52 UTC
Does this package have maintainers? Anyone? Does anyone care? Is this a bug tracker or just a useless website no one attends to?

Comment 5 Pavel Valena 2022-04-05 19:32:47 UTC
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/

Comment 6 bcling 2022-04-09 06:33:05 UTC
Created attachment 1871575 [details]
Expected rdsosreport from Fedora 35 Live Workstation

Comment 7 bcling 2022-04-09 06:34:39 UTC
Created attachment 1871576 [details]
Actual rdsosreport from Fedora 35

Comment 8 bcling 2022-04-09 06:36:10 UTC
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.

Comment 9 bcling 2022-04-11 05:13:23 UTC
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?

Comment 10 bcling 2022-04-11 15:17:10 UTC
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.

Comment 11 Ben Cotton 2022-11-29 17:33:07 UTC
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.

Comment 12 Ben Cotton 2022-12-13 16:11:23 UTC
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.

Comment 13 Sergio Basto 2023-01-04 23:34:11 UTC
tip for  Artem S. Tashkinov

Comment 14 Sergio Basto 2023-01-04 23:34:41 UTC
*** Bug 2156004 has been marked as a duplicate of this bug. ***

Comment 15 Sergio Basto 2023-01-04 23:36:02 UTC
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.

Comment 16 Artem S. Tashkinov 2023-07-02 06:50:22 UTC
Created attachment 1973708 [details]
Fedora 38 failure

Fedora 38 fails too.

Does anyone care?

Why does this option exist?

Comment 17 Artem S. Tashkinov 2023-07-02 06:51:43 UTC
The bug will soon be 3 years of age.

Comment 18 Sergio Basto 2023-07-03 22:07:55 UTC
> 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 ?

Comment 19 Sergio Basto 2023-07-03 22:53:38 UTC
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 !

Comment 20 Artem S. Tashkinov 2023-07-04 10:28:16 UTC
(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.

Comment 21 Sergio Basto 2023-07-04 10:37:27 UTC
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 ...

Comment 22 bcling 2023-07-04 16:17:30 UTC
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).

Comment 23 Sergio Basto 2023-09-05 23:42:32 UTC
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

Comment 24 Laszlo 2024-03-03 03:07:37 UTC
Upstream PR - https://github.com/dracutdevs/dracut/pull/2551

Comment 25 Laszlo 2024-04-18 10:54:44 UTC
merged upstream https://github.com/dracut-ng/dracut-ng/pull/17

Comment 26 Aoife Moloney 2024-05-07 15:44:51 UTC
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.

Comment 27 Artem S. Tashkinov 2024-05-07 15:47:04 UTC
Hopefully it's gonna be fixed in Fedora 41.


Note You need to log in before you can comment on or make changes to this bug.