After upgrading to kernel 6.17.12 my laptop won’t boot.
The main error shown in the textual plymouth screen is about dev-gpt/x2droot.device and there is no way to enter a working console. After pressing Enter, an error is shown in red Failed to connect to system scope bus via local transport: No such file or directory.
previous kernel 6.17.11 works fine (I’m typing this right now after rebooting)
To get into the root account you need to set a password for it.
Then you should be able to login and have a look around for a cause of the problem.
This is also happening to me after an automated boot. Going back to 6.17.11 makes things functional… but the nonfree nvidia drivers don’t work. For me the failure is “Job dev-gpt\x2dauto\x2droot.device/start” times out. I can’t make any sense of why it failed.
I enabled the root password and can now look around. When this happens it’s still in the ‘initramfs’ environment. Not sure what changed between 6.17.11 and 6.17.12 for this. The /dev/gpt-auto-root comes from the systemd-gpt-auto-generator https://www.freedesktop.org/software/systemd/man/latest/systemd-gpt-auto-generator.html?__goaway_challenge=meta-refresh&__goaway_id=079915518f65ac451fe6e97acdba5f68&__goaway_referer=https%3A%2F%2Fwww.google.com%2F . Regenerating the initramfs doesn’t change anything.
systemd seems to suddenly be able to figure out with is the root filesystem with 6.17.12. The root for me is /dev/sda3… a btrfs with multiple subvolumes (set up by an earlier fedora installer… prior to Fedora 41.) The partition named ‘root’ is not the btrfs “default”. (In fact, the default was set to something that doesn’t exist.)
By booting to the working 6.17.11 kernel, I did: btrfs subvolume set-default / and rebooted. However, this didn’t seem to change things.
I then rebooted to 6.17.12 but added root=/dev/sda3… and this gets the system to boot. But that’s just a workaround.
After having set the btrfs default… for an unrelated reason I ran sudo grub2-mkconfig -o /boot/grub2/grub.cfg and it added options root=UUID=**redacted-uuid** ro rootflags=subvol=root to each kernel conf file (/boot/loader/entries/*.conf).
So, inspecting logs… my older kernels would always boot with these flags enabled. However, for some unknown reason, the root= flag was missing for the new kernel.
The root= should be for the UUID.
Here for example is what I have in a kde plasma VM.
$ lsblk -f
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
sr0
zram0 swap 1 zram0 b7bd8452-71ae-4d12-829d-264496141d30 [SWAP]
vda
├─vda1 vfat FAT32 37C4-004F 562.3M 6% /boot/efi
├─vda2 ext4 1.0 8aa10d8b-8612-4e0e-9090-799ffaf5166d 282.7M 64% /boot
└─vda3 btrfs fedora 8bdec6ac-fe6b-4bbd-9370-ba04f888cc60 54.8G 10% /home
/
$ sudo grubby --info=ALL
[sudo] password for barry:
index=0
kernel="/boot/vmlinuz-6.17.12-300.fc43.aarch64"
args="ro rootflags=subvol=root $tuned_params"
root="UUID=8bdec6ac-fe6b-4bbd-9370-ba04f888cc60"
initrd="/boot/initramfs-6.17.12-300.fc43.aarch64.img $tuned_initrd"
title="Fedora Linux (6.17.12-300.fc43.aarch64) 43 (KDE Plasma Desktop Edition)"
id="1067dd5f79a6447cb830674ea7155f3c-6.17.12-300.fc43.aarch64"
I checked and the root=UUID part is missing for the 6.17.12 entry, but present for earlier versions. Manually adding it is enough for the system to boot without further actions.
When you next do an update that installs a new kernel check to see if the root= is dropped before you reboot. If it does get removed there is someiong odd your system that we can investigate.
Edit: fixed markup
$ sudo grubby --info=ALL
index=0
kernel=“/boot/vmlinuz-6.17.12-300.fc43.x86_64”
args=“selinux=0 $tuned_params”
initrd=“/boot/initramfs-6.17.12-300.fc43.x86_64.img $tuned_initrd”
title=“Fedora Linux (6.17.12-300.fc43.x86_64) 43 (Workstation Edition)”
id=“9fce731640434dc0982612d0a1b0d0fd-6.17.12-300.fc43.x86_64”
index=1
kernel=“/boot/vmlinuz-6.17.11-300.fc43.x86_64”
args=“ro rootflags=subvol=root rhgb quiet $tuned_params selinux=0”
root=“UUID=1c6f7b05-9ca7-4cc6-9c64-7c25b7fac580”
initrd=“/boot/initramfs-6.17.11-300.fc43.x86_64.img $tuned_initrd”
title=“Fedora Linux (6.17.11-300.fc43.x86_64) 43 (Workstation Edition)”
id=“9fce731640434dc0982612d0a1b0d0fd-6.17.11-300.fc43.x86_64”
index=2
kernel=“/boot/vmlinuz-6.17.10-300.fc43.x86_64”
args=“ro rootflags=subvol=root rhgb quiet $tuned_params selinux=0”
root=“UUID=1c6f7b05-9ca7-4cc6-9c64-7c25b7fac580”
initrd=“/boot/initramfs-6.17.10-300.fc43.x86_64.img $tuned_initrd”
title=“Fedora Linux (6.17.10-300.fc43.x86_64) 43 (Workstation Edition)”
id=“9fce731640434dc0982612d0a1b0d0fd-6.17.10-300.fc43.x86_64”
index=3
kernel=“/boot/vmlinuz-0-rescue-9fce731640434dc0982612d0a1b0d0fd”
args=“ro rootflags=subvol=root rhgb quiet selinux=0”
root=“UUID=1c6f7b05-9ca7-4cc6-9c64-7c25b7fac580”
initrd=“/boot/initramfs-0-rescue-9fce731640434dc0982612d0a1b0d0fd.img”
title=“Fedora (0-rescue-9fce731640434dc0982612d0a1b0d0fd) 34 (Workstation Edition)”
id=“9fce731640434dc0982612d0a1b0d0fd-0-rescue”
index=4
kernel=“/boot/memtest86+x64.efi”
args=“”
initrd=“/boot”
title=“Memory test (memtest86+x64.efi)”
id=“9fce731640434dc0982612d0a1b0d0fd-0-memtest86+”
I think this will put back the root= for you.
sudo grubby '--args=root=“UUID=1c6f7b05-9ca7-4cc6-9c64-7c25b7fac580”' --update-kernel=vmlinuz-6.17.12-300.fc43.x86_64
Thank you, the command sudo grub2-mkconfig -o /boot/grub2/grub.cfg posted by @gabrbedd worked well. As you said, it’s worth keeping an eye for future kernel upgrades.
@steko glad it helped!! I suspect there’s a bug somewhere that causes grub2-mkconfig sometimes do the wrong thing. Either a race condition or post-install process that didn’t complete. I’ll do a little sniffing around to see if I can figure it out.
Just for the record, I had the same problem already with kernel 6.17.8-300.fc43.x86_64
when I tried to boot it on the 19th of November. I booted back to 6.17.7-300 and almost forgot about it. Then the same happened with 6.17.9-300.fc43 and 6.17.12-300.fc43.
So, two days ago, 6.17.7-300 being the newest kernel I was able to use, I finally decided to mount my hard drive in rescue mode when 6.17.12 fails to start and copy the suggested /run/initramfs/rdsosreport.txt there and took a picture of the failing startup screen for reporting, but found this thread and checked the
grub2-mkconfig -o /boot/grub2/grub.cfg
solution, and it worked for me too.
Thanks.
Here, the ASCII double quotes were replaced by opening and closing double quotes when I view your post on this iPad, but are correct in the quote. Auto-correction across different browsers/OS’s/editors has been inserting bugs in Linux configurations files and shell scripts for years
The same problem happened again today with the upgrade to 6.18.3.
I rebooted with the older kernel and fixed again, but this is quite annoying!
So, as previously mentioned:
you need to provide more details to help us understand why this problem keeps reappearing.
The “solution” using grubby just changes the entries for the specified kernels, so the missing root= must be due to a more basic “something” that needs fixing so new kernels will get the fix without manual intervention. Here:
% sudo grep -R root= /etc/grub.d/
/etc/grub.d/10_linux:# btrfs may reside on multiple devices. We cannot pass them as value of root= parameter
/etc/grub.d/10_linux: local cmdline="root=${LINUX_ROOT_DEVICE} ro ${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_DEFAULT}"
/etc/grub.d/10_linux: set kernelopts="root=${LINUX_ROOT_DEVICE} ro ${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_DEFAULT}"
/etc/grub.d/10_linux: linux ${rel_dirname}/${basename} root=${linux_root_device_thisversion} ro ${args}
/etc/grub.d/20_linux_xen:# btrfs may reside on multiple devices. We cannot pass them as value of root= parameter
/etc/grub.d/20_linux_xen: ${module_loader} ${rel_dirname}/${basename} placeholder root=${linux_root_device_thisversion} ro ${args}
/etc/grub.d/30_os-prober: multiboot /boot/gnumach.gz root=device:${mach_device}
Assuming your system has the same entries,
/etc/fstab entry for the root filesystem provide a UUID?Yes, I have the same exact output from sudo grep -R root= /etc/grub.d/
This is my /etc/fstab
#
# /etc/fstab
# Created by anaconda on Fri Jun 11 08:33:24 2021
#
# Accessible filesystems, by reference, are maintained under '/dev/disk/'.
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.
#
# After editing this file, run 'systemctl daemon-reload' to update systemd
# units generated from this file.
#
/dev/sda3 / btrfs subvol=root,compress=zstd:1 0 0
UUID=9986d3b1-0a87-4030-b3f5-489fa10ef17f /boot ext4 defaults 1 2
UUID=744C-7883 /boot/efi vfat umask=0077,shortname=winnt 0 2
/dev/sda3 /home btrfs subvol=home,compress=zstd:1 0 0
Apparently the root filesystem doesn’t provide a UUID, only /boot has one
I can’t check what happens before reboot because the upgrade is installed through a full reboot - as is normal with Fedora system upgrades afaik
You should be able to edit your fstab to provide the UUID for / and /home. You can get the UUID for /dev/sdc using Gnome Disks or lsblk. As it happens, one of my systems has root on /dev/sdc3:
% lsblk --output UUID /dev/sdc3
UUID
53f6b5e3-bbac-453c-b002-67f732e2294a
% grep 53f6b5e3-bbac-453c-b002-67f732e2294a /etc/fstab
UUID=53f6b5e3-bbac-453c-b002-67f732e2294a / btrfs subvol=root,compress=zstd:1 0 0
UUID=53f6b5e3-bbac-453c-b002-67f732e2294a /home btrfs subvol=home,compress=zstd:1 0 0
This was a fresh install made on 1 January this year. Was your system an upgrade?
AFAICT, the grub stuff all gets updated BEFORE you reboot. There’s a trigger on a new kernel that calls /bin/kernel-install and through a chain of responsibilites lands on /usr/bin/grubby. Inside grubby it lands on the function update_bls_fragment(). And inside this function is some logic that, to me, smells bad.
Specifically, it appears to completely ignore /etc/fstab and there’s a strange relationship between /etc/defaults/grub and /etc/kernel/cmdline . In particular, it looks like things can get out of whack if /etc/default/grub has a non-empty GRUB_CMDLINE_LINUX.
@steko , can you please post the contents of /etc/kernel/cmdline and /etc/default/grub ?