Open pomac303 opened 1 year ago
Example: dracut: Stored kernel commandline: dracut: rd.driver.pre=btrfs dracut: rd.md.uuid=ad61bd77:84b8fb62:cb201669:f728008a dracut: root=PARTUUID=410af5b1-02 rootfstype=btrfs rootflags=rw,noatime,compress=lzo,ssd,discard=async,space_cache,autodefrag,subvolid=5,subvol=/
Actual boot commandline: [ 0.000000] Command line: root=UUID=6076d17e-1e73-4933-a0aa-7ba2c7a4b3ae fastboot quiet crashkernel=128M init=/usr/lib/systemd/systemd scsi_mod.use_blk_mq=Y vga=0 console=ttyS1,115200n8 console=tty0
And since that is one partition in a btrfs raid1 it actually looses the raid1 functionality and breaks any chance of easy repair.
Actually, If i change to space_cache=v2 - it will not be able to mount the filesystem....
@pomac303 maybe I do not understand this fully (yet), but could you just temporary overrule the "saved in to the image" arguments in the bootloader. One of the (expected) feature of dracut that bootloader arguments should overrule "saved in the image" arguments.
so it completely ignores root=UUID etc f.ex. so unless you have to provide something specific to dracut then no, this is the issue - it statically saves what it should mount and how in configuration files within the actual image that was generated.
How do i know, well, i replaced my root disks on a machine and i was fighting this for quite a while - as stated, even booting a linux image and chrooting in to the old system to regenerate the dracut image does nothing since generationtime looks at what the kernel booted with - not fstab (atleast not by default, you can specify that it should)
IMHO it should check the kernel command line and use that, it could have some state saved and use it if the supplied boot options doesn't work.... But in general they should...
The example above is from my firewall machine, running dracut on commandline in a booted machine, and having it ignore most things - i could solve it with dracut -f --fstab however.
IMHO the defaults could be more sane, like checking boot= and then remount with the information from fstab
@pomac303 just so that we can understand and reproduce better, can you post full dracut command line - in particular are you using hostonly or not ?
Full commandline: "dracut -f"
And yes. I am using host only to avoid nfsroot issues...
Full commandline: "dracut -f"
And yes. I am using host only to avoid nfsroot issues...
You could do non-hostonly and manually include/omit modules (such as nfs).. This part of dracut is confusing indeed
Host only: yes dracut: rd.driver.pre=btrfs dracut: rd.md.uuid=ad61bd77:84b8fb62:cb201669:f728008a dracut: root=PARTUUID=410af5b1-02 rootfstype=btrfs rootflags=rw,noatime,compress=lzo,ssd,discard=async,space_cache=v2,autodefrag,subvolid=5,subvol=/
The partuuid is not specified by me anywhere and it's actually wrong.
12M /boot/initramfs-6.4.7.img
host only: no 32M /boot/initramfs-6.4.7.img
this is with: omit_dracutmodules+=" nfs " compress="zstd -9" squash_compress="zstd"
However you are correct in that it doesn't seem to output anything about the root device
@pomac303 At least with "host only: no" you should be able to set "root=UUID" (e.g. in bootloader). Did that worked ?
Yes, but 20 mb more with good compression, all the tools to actually do this properly is in the image - why not do it properly?
And it gets even worse, filesystems listed as non auto is now forced in to systemd, it seems like it doesn't matter if you have hostonly=yes or not
I have a system breaking because a noauto filesystem isn't available on boot... Well, there is a reason for that...
Describe the bug A clear and concise description of what the error is.
When moving root filesystem to new disks the initramfs will not boot
Distribution used Which distribution was this behaviour seen in?
Gentoo
Dracut version Which dracut version was this behaviour seen in?
059-r3
Init system Which init system is being used?
Systemd
To Reproduce Steps or code to reproduce the behavior.
Switch out the devices, or just boot with a liveusb device and chroot in to regenerate your initramfs
Expected behavior A clear and concise description of what you expected to happen.
I expect dracut to figure some things out on boot, not on initramfs generation time.
Additional context Add any other context you like about the problem here.
One of my ssd:s failed, so I scrambled to move to two new disks before the last one fails.
The problem is that you have to end up in 'failed' boot with a shell and: mount /sysroot
cd sysroot
mount -o bind /dev dev
mount -o bind /proc proc
mount -o bind /sys sys
mount boot
chroot . /bin/bash
And now you can regenerate a working initramfs - anything else will fail since the kernel commandline is "wrong" and saved in to the image.