15.4 boot failure - NVME / filesystem not found by latest kernel
UEFI booting. pi3p16s154 is nvme0n1p16 ext4 root filesystem LABEL. crypto is not employed anywhere on the PC. 5.14.21-150400.19 kernel boots normally. 5.14.21-150400.22 kernel is not recognizing USB stick insertion, so there's no way I know to get /run/initramfs/rdsosreport.txt onto a stick for susepasting, and susepaste isn't in the emergency shell. Neither does the shell include grep. I rebuilt initrd with add_dracutmodules+=debug but still no susepaste or grep, or lsblk, or fdisk, or improvement. Selected excerpts from rdsosreport.txt: systemd-modules-load.service: Failed with result 'exit-code'. Failed to start Load Kernel Modules. systemd-modules-load...Failed to look up module alias 'sg': Function not implemented condition check resulted in dracut pre-trigger hook being skipped dracut-initqueue...Warning: dracut-initqueue: timeout, still waiting for following initqueue hooks: /lib/dracut/hooks/initqueue/finished/devexists-/dev/disk/by-label-pi3p16s154.sh "if ! grep After=remote-fs-pre.target /run/systemd/generator/systemd-cryptsetup@*.service 2>/dev/null; then [ -e " /dev/disk/by-label/pi3p16s154" ] ... Warning: dracut-initqueue: starting timeout scripts Warning: Could not boot. systemd[1]: Starting Dracut Emergency Shell.... Is there anything above that suggests why the .22 initrd failed to enable nvme / filesystem to be found? https://paste.opensuse.org/57952814 is output from lsinitrd /boot/initrd. I did essentially the same dup to 15.4 a week ago on another PC with same Intel b250 chipset, also UEFI & nvme, and no trouble. I copied each of 3 .22 initrds from the first PC to the second. The first boots normally. The second not, initially stopping at starting dracut initqueue hook, winding up in emergency shell. So did the #3 initrd. The initrd from the update last week copied to today's also fails in same manner. The big difference between the two PCs: the problem PC contains 2 HDDs with multiple partitions, about half of which comprise several mdraid devices, none of which have anything to do with booting the problem 15.4 installation. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 25.05.2022 02:42, Felix Miata wrote:
UEFI booting. pi3p16s154 is nvme0n1p16 ext4 root filesystem LABEL. crypto is not employed anywhere on the PC. 5.14.21-150400.19 kernel boots normally. 5.14.21-150400.22 kernel is not recognizing USB stick insertion, so
What exactly does it mean? You do not see GUI popup when USB is inserted?
there's no way I know to get /run/initramfs/rdsosreport.txt onto a stick for susepasting, and susepaste isn't in the emergency shell. Neither does the shell include grep. I rebuilt initrd with add_dracutmodules+=debug but still no susepaste or grep, or lsblk, or fdisk, or improvement.
Your initrd does not include debug module according to the link further down. And in any case, nothing prevents you from adding any program you need to initrd.
Selected excerpts from rdsosreport.txt: systemd-modules-load.service: Failed with result 'exit-code'. Failed to start Load Kernel Modules. systemd-modules-load...Failed to look up module alias 'sg': Function not implemented condition check resulted in dracut pre-trigger hook being skipped dracut-initqueue...Warning: dracut-initqueue: timeout, still waiting for following initqueue hooks: /lib/dracut/hooks/initqueue/finished/devexists-/dev/disk/by-label-pi3p16s154.sh "if ! grep After=remote-fs-pre.target /run/systemd/generator/systemd-cryptsetup@*.service 2>/dev/null; then [ -e " /dev/disk/by-label/pi3p16s154" ] ... Warning: dracut-initqueue: starting timeout scripts Warning: Could not boot. systemd[1]: Starting Dracut Emergency Shell....
Is there anything above that suggests why the .22 initrd failed to enable nvme / filesystem to be found?
https://paste.opensuse.org/57952814 is output from lsinitrd /boot/initrd.
I did essentially the same dup to 15.4 a week ago on another PC with same Intel b250 chipset, also UEFI & nvme, and no trouble. I copied each of 3 .22 initrds from the first PC to the second. The first boots normally. The second not, initially stopping at starting dracut initqueue hook, winding up in emergency shell. So did the #3 initrd. The initrd from the update last week copied to today's also fails in same manner.
The big difference between the two PCs: the problem PC contains 2 HDDs with multiple partitions, about half of which comprise several mdraid devices, none of which have anything to do with booting the problem 15.4 installation.
Andrei Borzenkov composed on 2022-05-25 07:47 (UTC+0300):
Felix Miata wrote:
UEFI booting. pi3p16s154 is nvme0n1p16 ext4 root filesystem LABEL. crypto is not employed anywhere on the PC. 5.14.21-150400.19 kernel boots normally. 5.14.21-150400.22 kernel is not recognizing USB stick insertion, so
What exactly does it mean? You do not see GUI popup when USB is inserted?
I boot into emergency shell. # dmesg -w I insert a USB stick containing FAT and EXT2 filesystems on partitions. Nothing happens. Now that the system is no longer objecting the original initrd, I can't reproduce this exactly. To induce emergency shell, I make root= parameter in Grub invalid. But in the emergency shell this way, the kernel discovers USB insertion. OTOH, it doesn't mknod stick or any of the 6 partitions, among them VFAT and EXT2. From dmesg: New high-speed USB device number 6 using xhci_hcd ...Cruzer Edge...SanDisk... uas: Unknown symbol usb_stor_sense_invalidCDB (err -2) uas: Unknown symbol usb_stor_adjust_quirks (err -2) Searching for either of the 2 err lines above in Google produced 0 hits. An Adata 3.2 stick with only 1 (VFAT) partition produces equivalent results. Several other sticks with various partitioning (none with only 1 partition as type 83 formatted ext2) were all recognized in dmesg, but with none did anything like [644978.764904] sdh: sdh1 sdh2 sdh3 sdh4 < sdh5 sdh6 > result.
there's no way I know to get /run/initramfs/rdsosreport.txt onto a stick for susepasting, and susepaste isn't in the emergency shell. Neither does the shell include grep. I rebuilt initrd with add_dracutmodules+=debug but still no susepaste or grep, or lsblk, or fdisk, or improvement.
Your initrd does not include debug module according to the link further down. And in any case, nothing prevents you from adding any program you need to initrd.
I uploaded that before rebuilding initrd to contain debug. Nice to know about freedom in adding. :) -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
For inexplicable reasons, after several other boots to other installations on same PC, 15.4 decided it was OK to boot normally using the originally generated .22 initrd. Felix Miata composed on 2022-05-24 19:42 (UTC-0400):
UEFI booting. pi3p16s154 is nvme0n1p16 ext4 root filesystem LABEL. crypto is not employed anywhere on the PC. 5.14.21-150400.19 kernel boots normally. 5.14.21-150400.22 kernel is not recognizing USB stick insertion, so there's no way I know to get /run/initramfs/rdsosreport.txt onto a stick for susepasting, and susepaste isn't in the emergency shell. Neither does the shell include grep. I rebuilt initrd with add_dracutmodules+=debug but still no susepaste or grep, or lsblk, or fdisk, or improvement.
Selected excerpts from rdsosreport.txt: systemd-modules-load.service: Failed with result 'exit-code'. Failed to start Load Kernel Modules. systemd-modules-load...Failed to look up module alias 'sg': Function not implemented condition check resulted in dracut pre-trigger hook being skipped dracut-initqueue...Warning: dracut-initqueue: timeout, still waiting for following initqueue hooks: /lib/dracut/hooks/initqueue/finished/devexists-/dev/disk/by-label-pi3p16s154.sh "if ! grep After=remote-fs-pre.target /run/systemd/generator/systemd-cryptsetup@*.service 2>/dev/null; then [ -e " /dev/disk/by-label/pi3p16s154" ] ... Warning: dracut-initqueue: starting timeout scripts Warning: Could not boot. systemd[1]: Starting Dracut Emergency Shell....
Is there anything above that suggests why the .22 initrd failed to enable nvme / filesystem to be found?
https://paste.opensuse.org/57952814 is output from lsinitrd /boot/initrd.
I did essentially the same dup to 15.4 a week ago on another PC with same Intel b250 chipset, also UEFI & nvme, and no trouble. I copied each of 3 .22 initrds from the first PC to the second. The first boots normally. The second not, initially stopping at starting dracut initqueue hook, winding up in emergency shell. So did the #3 initrd. The initrd from the update last week copied to today's also fails in same manner.
The big difference between the two PCs: the problem PC contains 2 HDDs with multiple partitions, about half of which comprise several mdraid devices, none of which have anything to do with booting the problem 15.4 installation.
-- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
participants (2)
-
Andrei Borzenkov -
Felix Miata