Fedora 41 - Root and arguments are not retained when the kernel is updated

Ask Fedora
1
  1. I upgraded My Fedora Workstation from version 40 to 41.
  2. At the end of the upgrade I ran the “Optional post-upgrade tasks” mentioned in the “Upgrading Fedora Linux Using DNF System Plugin” document.
  3. In particular after regenerating the rescue kernel with the recommended command:
sudo rm /boot/*rescue*
sudo kernel-install add "$(uname -r)" "/lib/modules/$(uname -r)/vmlinuz"

and rebooting the system at boot this problem occurs:

[FAILED] Failed to start initrd-switch-root.service - Switch Root.
See 'systemctl status initrd-switch-root.service' for details.
  1. After an analysis I found out with grubby that the kernel update
    inserts only these parameters for the updated kernel:
args="$tuned_params"

instead of:

args="ro resume=UUID=97b1943a-db79-4442-9198-b7b877d7ecbd rhgb quiet $tuned_params"
root="UUID=64253472-17eb-423a-98d1-61f260329449"

Does anyone know what causes this problem?

2

The kernel-install command takes the command line from the file /etc/kernel/cmdline. This file is re-generated when you run grub2-mkconfig based on information in the file /etc/default/grub if /etc/default/grub is newer than the file /etc/kernel/cmdline.

If the file /etc/kernel/cmdline doesn’t exist and the file /usr/lib/kernel/cmdline also doesn’t exist, the command line is taken from /proc/cmdline.

So check those files.

3 Likes
3

Thanks. The file /etc/kernel/cmdline exists but is empty and the file /usr/lib/kernel/cmdline does not exists. Can I safely copy the /proc/cmdline contents into /etc/kernel/cmdline to solve the problem for the next kernel update?

4

No, not directly. You forgot about /etc/default/grub and how the grub2-mkconfig will transfer the date from that file to /etc/kernel/cmdline.

5

The file /proc/cmdline contains this:

BOOT_IMAGE=(hd0,gpt5)/boot/vmlinuz-6.14.5-200.fc41.x86_64 root=UUID=64253472-17eb-423a-98d1-61f260329449 ro resume=UUID=97b1943a-db79-4442-9198-b7b877d7ecbd rhgb quiet

So the solution is to try to manually run the command grub2-mkconfig?

6

You first check the contents of /etc/default/grub and make sure that file is newer than the /etc/kernel/cmdline file. Especially check the value of the GRUB_CMDLINE_LINUX= line. By the way, you can drop the resume= entry unless you are using hibernation, aka suspend-to-disk.

7

/etc/default/grub and /etc/kernel/cmdline have the same date and time and the content of the first is:

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="resume=UUID=97b1943a-db79-4442-9198-b7b877d7ecbd rhgb quiet"
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG=true

But does the lack of root="UUID=64253472-17eb-423a-98d1-61f260329449" also depend on this?

8

Then you just run

sudo touch /etc/default/grub
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Then the file /lib/kernel/cmdline should have the correct contents. You can also run sudo grubby --info=ALL to check that all grub2 configuration is OK.

9

I forgot to specify that this command also solves the problem until the next kernel update when the problem occurs again:

sudo grubby --update-kernel=/boot/vmlinuz-6.14.5-200.fc41.x86_64 --args="root=UUID=64253472-17eb-423a-98d1-61f260329449 ro resume=UUID=97b1943a-db79-4442-9198-b7b877d7ecbd rhgb quiet"