http://bugzilla.opensuse.org/show_bug.cgi?id=1205261 http://bugzilla.opensuse.org/show_bug.cgi?id=1205261#c3 --- Comment #3 from Felix Miata --- (In reply to Antonio Feijoo from comment #2)

I recommend you to create a new conf snippet with a higher number, because this will be overwritten after a dracut update.

I haven't touched it. Wouldn't changing it from "by-uuid" to "by-label" just change the usr/lib/dracut/hooks/emergency failure from a wrong ID to a wrong label? Is this recommendation just an aside for future use? I've now created 13-persistent-local.conf containing persistent_policy="by-label", but I have at least 40 more TW installations on other multiboot PCs subject to disk upgrades and restoring from backup. For / filesystem there is Grub linu line option root= to override initrd, but what is there for whatever this usr/lib/dracut/hooks/emergency is there for? Once a Grub menu selection has been made, there's no need for anything to read the ESP again before init completes (absent any encrypted filesystems), is there? What man page covers usr/lib/dracut/hooks/emergency? man /etc/dracut.conf.d/10-persistent_policy.conf is unhelpful. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1205261 http://bugzilla.opensuse.org/show_bug.cgi?id=1205261#c7 --- Comment #7 from Felix Miata --- I still do not understand why failure to find a filesystem that won't be needed before switchroot is complete at the earliest can hang a boot in a dracut emergency shell. The non-intuitive extra complication restoring from backups or migrating disks is why I reported this. Yes, the workaround works, but why is it needed for boot to continue? Same question re root filesystem, since by default and tradition every bootloader stanza contains root= that overrides root= in initrd. Logic tells me these two dracut elements should be complementary fallbacks, not mandatory. It seems like otherwise rd.hostonly=0 should be included on every Grub linu line that contains root=. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1205261 http://bugzilla.opensuse.org/show_bug.cgi?id=1205261#c11 --- Comment #11 from Felix Miata --- (In reply to Felix Miata from comment #1)

ToDo: rebuild the RAID TW's initrds and retest.

I tried rebuilding initrds for the RAID installation several times and couldn't get the / filesystem to be found until I chrooted into it and dup'd from 20221008 to 20221205, which rebuilt the latest kernel at least 4 times. First and subsequent boots worked with the the last built whether starting from the ESP on NVME or from original MBR/EXT2 /boot/ filesystem on SATA. Only the first boot failure landed me in a dracut shell. All subsequent to beginning initrd rebuilds simply hung due to unlimited timeout failing to find / on /dev/md3, which turned out to be dracut was excluding 2/3 of the raid lines included in a working initrd. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1205261 http://bugzilla.opensuse.org/show_bug.cgi?id=1205261#c13 --- Comment #13 from Felix Miata --- Created attachment 865661 --> http://bugzilla.opensuse.org/attachment.cgi?id=865661&action=edit /boot/grub2/custom.cfg on TW / filesystem from which all installations are booted through TW's Grub; and rdsosreport.txt This is nuts. Similar situation to comment #0 on different PC. I used ddrescue to clone from 120G NVME to 512G NVME. GPT partitions 7-16 each have a Linux OS, with TW on #7, and in control of UEFI boot. After the cloning I shutdown and removed the source. I then booted a live media in order to re-unique all UUIDs and volume labels before attempting to boot from the new NVME. 11 of the 12 installations boot as if nothing ever was changed. The oddball failing is TW. With the original initrd for its default 6.2.1 kernel, whether I have neither or either or both rd.hostonly=0 and rd.auto or rd.auto=1, boot halts in dracut shell after "reached target initrd root device". Last line prior to announcing generation of /run/initramfs/rdsosreport.txt is a warning that /dev/disk/by-label/ZM2P01ESP does not exist. That label is the obsolete LABEL from the old NVME. /etc/fstab has been completely adapted to the new LABELs and UUIDs, which means ZM2P01ESP is not coming from /etc/fstab. I tried twice to chroot from TW rescue CD 20230318 into TW to rebuild the default initrd. Using either result, boot fails much sooner, last line before emergency shell is "Starting dracut initqueue hook". Both ESP and / filesystems "does not exist". In this shell I'm unable to find any way to get any kind of filesystem mounted so that rdsosreport.txt can be captured for analysis, and there is nothing I can find in the shell from which to view any but its tail. grep, head and less are absent commands. /dev/nvme* and /dev/sd* do not exist. Even if I mknod /dev/sda and /dev/sda1 to try to mount a USB stick, no joy. All older kernels with original initrds, e.g. 6.1.12 or 6.0.12 or 5.19.13, stop @ "Reached target Basic System.", whether I have neither or either or both rd.hostonly=0 and rd.auto or rd.auto=1. Chrooting from 15.5 on nvme0n1p11 to TW on nvme0n1p7 I was able to install kernel-default-6.2.6, with result it boots normally. Rebuilding older initrds with mkinitrd while booted to 6.2.6 only succeeded for booting the 6.2.1 kernel. For 6.1.12, boot stops at "Starting dracut initqueue hook..." Apparently the rc.* workarounds no longer are functional. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1205261 http://bugzilla.opensuse.org/show_bug.cgi?id=1205261#c15 Felix Miata changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |malcolmlewis@linuxmail.org, | |nwr10cst-oslnx@yahoo.com --- Comment #15 from Felix Miata --- arvidjaar in forums[1] told someone (without any real detail) he needs to bind-mount /sys/firmware/efi/efivars to be able to chroot successfully for the purpose of initrd regeneration. I've never seen that direction before. Coming from him, I have to think it to be true. Could it explain why chroot-built initrds haven't worked for me? [1] https://forums.opensuse.org/t/reinstalling-grub-after-losing-dual-boot/16516... -- You are receiving this mail because: You are on the CC list for the bug.