Changed boot args with grubby now boot loader entries not correct for new kernels

Ask Fedora
1

I created a bug here:system fails to boot with new kernels after changing args in grubby

After using grubby as follows:
grubby --args=usb_storage.quirks=0x0bc2:0x3322:,0x0bc2:0xab80:,0x0bc2:0xab81:,0x0bc2:0xab82:,0x0bc2:0xab38: --update-kernel=ALL

it appears that future kernel entries are not built properly. System boot fails by going into recovery mode.

Here is the entry for 6.3.8 kernel:

title Fedora Linux (6.3.8-200.fc38.x86_64) 38 (Workstation Edition)
version 6.3.8-200.fc38.x86_64
linux /vmlinuz-6.3.8-200.fc38.x86_64
initrd /initramfs-6.3.8-200.fc38.x86_64.img
options root=UUID=365d160f-bac9-4a1c-9ee5-7be7b4f7207d ro rhgb quiet usb_storage.quirks=0x0bc2:0x3322:,0x0bc2:0xab80:,0x0bc2:0xab81:,0x0bc2:0xab82:,0x0bc2:0xab38:
grub_users $grub_users
grub_arg --unrestricted
grub_class fedora

Here is the entry that was built for 6.3.9 kernel:

title Fedora Linux (6.3.9-200.fc38.x86_64) 38 (Workstation Edition)
version 6.3.9-200.fc38.x86_64
linux /vmlinuz-6.3.9-200.fc38.x86_64
initrd /initramfs-6.3.9-200.fc38.x86_64.img
options usb_storage.quirks=0x0bc2:0x3322:,0x0bc2:0xab80:,0x0bc2:0xab81:,0x0bc2:0xab82:,0x0bc2:0xab38:
grub_users $grub_users
grub_arg --unrestricted
grub_class fedora

I found that I can workaround the issue by manually editing the /boot/loader/entry/*.conf files and correcting the option line to be:

options root=UUID=365d160f-bac9-4a1c-9ee5-7be7b4f7207d ro rhgb quiet usb_storage.quirks=0x0bc2:0x3322:,0x0bc2:
0xab80:,0x0bc2:0xab81:,0x0bc2:0xab82:,0x0bc2:0xab38:

but I shouldn’t have to do that. Does anyone know what might be happening, and how to fix?

Thanks!

2

That looks like a grubby error, possibly with the way the command was structured.
From the grubby man page I see

       --args=kernel-args
              When  a  new  kernel is added, this specifies the command line arguments which should be passed to the kernel by default (note they are merged with the arguments of
              the default entry if --copy-default is used).  When --update-kernel is used, this specifies new arguments to add to the argument list. Multiple, space separated ar‐
              guments  may be used. If an argument already exists the new value replaces the old values. The root= kernel argument gets special handling if the configuration file
              has special handling for specifying the root filesystem.

It appears that you used grubby - then added the rest on the following line. According to the synopsis it probably should have been a single line entry without the - in that location.
The man page shows it as grubby --args=..... I suspect the way it was entered changed the behavior.

3

Thanks for the reply… no I entered the command on the same line. When I cut and pasted that is the way discourse formatted it since the line was so long. I’ll see if I can correct. Since that is the case, do you have any other ideas what might be happening?

4

Have you tried using --copy-default?

5

Actually, no.

I had tested with grubby before I posted that and things worked as expected, both adding and removing arguments.
Where did you get the 6.3.9 kernel from? Testing? It does not yet appear to be released for fedora 38.

EDIT
I even tried with installing the 6.3.9 kernel from the testing repo and grubby also worked as expected for me with that kernel.

Is your system fully up-to-date and in sync? dnf distro-sync --refresh

6

Thanks for the reply. Yeah, my system is up-to-date. Geez, I’m finding all kinds of bizarre things lately… :pensive:

7

Yeah, the problem isn’t manually issuing the grubby command, that works fine. The problem I’m having is when I update the kernel. The new entry generated doesn’t have any args, include the root= which causes the boot to fail.

As I mentioned, I can manually edit the file and all works fine, but I shouldn’t have to… two issues in one week that no one can figure out… I’m on a roll… :wink:

8

Found this by using bard.google.com:

This is a known issue with some distributions, such as Fedora. The GRUB bootloader does not automatically update the kernel arguments when you upgrade the kernel. This means that the GRUB entry for the old kernel will still be present, but it will not contain the arguments for the new kernel.

To fix this issue, you need to manually update the GRUB entry for the new kernel. You can do this by running the following command:

sudo grub2-mkconfig -o /etc/grub2.cfg

Use code with caution. Learn more

This will regenerate the GRUB configuration file and update the kernel arguments for the new kernel.Here are the steps on how to manually update the GRUB entry for the new kernel: Open a terminal window. Run the following command: sudo grub2-mkconfig -o /etc/grub2.cfg`

Use code with caution. Learn more

Reboot your computer. After you have rebooted your computer, the GRUB entry for the new kernel should now contain the correct kernel arguments.If you are still having problems, you can try running the following command to force GRUB to update the kernel arguments: 'sudo grubby --update-kernel --args="your_kernel_args"

Use code with caution. Learn more

Replace your_kernel_args with the kernel arguments for the new kernel.

Kind of weird I’ve never had this issue before. Maybe it only happens sporadically and hasn’t been fixed.

9

I believe (hopefully) I figured it out. It appears that somehow my /etc/default/grub file was changed and for some reason this line was changed to: GRUB_CMDLINE_LINUX=""

This file is used as input when “grub2.cfg” is changed, which happens when you run either the grub2-mkconfig or update the kernel. I’m guessing that when I added the long usb_storage.quirks line that the utility that changes the /etc/default/grub file couldn’t deal with the line length and just changed it to “”. That’s a hypothesis on my part, but that is the only thing that I changed. I’ll update the grubby ticket with that info and see what they say.

Edit: Marking this as solution. I’ve installed several kernels for testing and the /boot/loader/entries/ appear to be updated correctly. Seems this is a known issue that happens from time to time. Here are the contents of a working /etc/default/grub file for comparison purposes:

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="rhgb quiet usb_storage.quirks=0x0bc2:0x3322:,0x0bc2:0xab80:,0x0bc2:0xab81:,0x0bc2:0xab82:,0x0bc2:0xab38:"
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG=true
10

Koji, but a newer version is now in testing.