Workaround for missing bugfix `0da23ad` | rpms / grubby

Solultion: Modify hardcoded UUID in /etc/kernel/cmdline

root=UUID=******** ro rootflags=subvol=root rhgb quiet

Keywords: UEFI, kernel-install, /boot/grub2/grub.cfg, /etc/kernel/cmdline, UUID, Root Partition, GRUB2, Bootloader Spec, BLS, grubby, $kernelopts, kernelopts

Hi @fd-user, welcome to the community.

Sorry, this is not clear at all. What is this the solution for please?

If you can please edit your first comment here to describe the issue, and then add a comment with the solution, we can mark it as a solution to follow the design of this forum software.

I do not have this file on F36 Workstation!
Do you have some references where you could link, that we can see about what you are talking?

And by the way please read also #start-here to see how the communication works here. Normally the OP describes a fact, deliverers enough inputs and we then give answers alias help to make a bug request if something is not working as usual.

1 Like

I have /etc/kernel/cmdline of my freshly install F37 beta.

1 Like

I have 3 different machines running F36. Strangely enough 2 have the /etc/kernel/cmdline file and one does not. Am not sure when or how that file was created, nor how long it has existed. None are running btrfs, so it would seem that is not necessarily a factor though it might be. The OP shows a structure that is specifically limited to btrfs with the rootflags=subvol=root portion of his entry. With my systems using LVM even the UUID is unused in my kernel command line as shown in /boot/loader/entries/UUID*.conf files

On one system ls -l shows /etc/kernel/cmdline with a date of Sept 3, and on the other Sept 26.

Maybe someone can tell us how and under what conditions that file is created.

I also note, as does @sampsonf, that my F37 beta system (VM) does have that file. The file shows a date of Oct 19. However nothing seems to own it

# dnf provides /etc/kernel/cmdline
Last metadata expiration check: 1 day, 15:23:04 ago on Sat 12 Nov 2022 06:47:45 PM CST.
Error: No matches found. If searching for a file, try specifying the full path or using a wildcard prefix ("*/") at the beginning.

I thought BLS requires (?) UEFI. Sounds like OP found that the BLS boot entries were reading these files to generate them. So are the machines that don’t have them BIOS, not UEFI?

According to above, kernel-install will use /etc/kernel/cmdline to specify kernel parameters when adding new kernel.

From man kernel-install

ILES
       /usr/lib/kernel/install.d/*.install /etc/kernel/install.d/*.install
           Drop-in files which are executed by kernel-install.

       /usr/lib/kernel/cmdline /etc/kernel/cmdline /proc/cmdline
           Read by 90-loaderentry.install. The content of the file /etc/kernel/cmdline specifies the kernel command line to use. If that file does not exist,
           /usr/lib/kernel/cmdline is used. If that also does not exist, /proc/cmdline is used.

All my systems are UEFI boot, including the VM

You are linking to a systemd-boot reference. I am using the default grub2 boot.

That man page shows that the kernel-install process reads /etc/kernel/cmdline if it exists, but does not say anything about how it is created. It does state that /etc/kernel/cmdline takes precedence over all the other sources read, so to have a user created command line the inference is that /etc/kernel/cmdline would be the place to add user preferences or customizations.

Digging further into my 3 systems I find that the laptop does not have either /etc/kernel/cmdline or /usr/lib/kernel/cmdline. My desktops both have /etc/kernel/cmdline and do not have /usr/lib/kernel/cmdline. All 3 have /proc/cmdline. My F37 VM is the same as the 2 desktops.

My impression is even with grub2, when upgrading kernel version, kernel-install will be called. kernel-install is not specific to systemd-boot .

How /etc/kernel/cmdline is created is interesting to find out.

How to compare the version of kernel-install ?

From my laptop and both desktops I see

# dnf provides /usr/bin/kernel-install
systemd-udev-250.8-1.fc36.x86_64 : Rule-based device node and kernel event manager
Repo        : @System
Matched from:
Filename    : /usr/bin/kernel-install

I belive it’s made during the install and updated by grubby and/or mkconfig.

/etc/grub.d/10_linux, lines 164 - 171
and
/usr/sbin/grubby, lines 531 - 543

If /etc/kernel/cmdline does not exist, then the current options as found in /proc/cmdline is used to create the options line in the new BLS snippets during kernel update.

If you run grub2-mkconfig the file /etc/kernel/cmdline is created based on information found in /etc/default/grub. At some point this didn’t work properly creating a bad /etc/kernel/cmdline with the result that the system could not boot after kernel update. This is now fixed.

Also, when running grub2-mkconfig the options line found in the BLS snippets are updated as well.

4 Likes

Ok, I just did a test on my laptop with F36.

My laptop has been updated repeatedly with each kernel update so the new files in /boot have been created each time. It has never created the /etc/kernel/cmdline file with this process.

I manually ran grub2-mkconfig today and sure enough it did create the /etc/kernel/cmdline file.

On my F37 VM system I have never run grub2-mkconfig and the file was created.

Seems that something is missing in the kernel update process on F36 that prevents the creation of that file, but it does get created when grub2-mkconfig is run.
Yet it seems the kernel update process on F37 does create that file.

Maybe kernel-install should create it but does not??

It was run during installation of grub2-common.

That implies that the install of grub2-common changed between F36 and F37 since my vanilla F36 on my laptop has never previously had that file created. Only today when I ran grub2-mkconfig did it appear.

It also shows that kernel updates on F36 do not ever create nor update that file.

Yes it was changed during the F36. If you remember all the problem some people had after upgrading the kernel during F36, that was caused teaching grub2 to create the /etc/kernel/cmdline. The first few updates of grub2 has bugs with the result the /etc/kernel/cmdline was created with bad data. Then it was fixed and it was still bad. And a few more times until it was finally fixed properly.

If you want the details, checkout the git repository at https://github.com/rhboot/grub2.git and switch to branch “fedora-36”.

2 Likes

I remember the discussion on those errors, but I never encountered the problem and never have had the file improperly created. ISTR that it was at about kernel 5.19.8 or 5.19.9 that happened.

On my desktops I have run grub2-mkconfig in the past, but on my laptop not until I did so today.

Again, it seems that the kernel updates should have created the file if it did not exist, and not just installing grub2-common since that is seldom upgraded. On the manual side it seems that grub2-mkconfig is the only thing that creates it.

My F37 vm was installed from the beta 1.5 iso and upgraded from there so it is logical that it would be created on that system.

The topic is a bit understandably. If someone could change/propose to a more simple one it would be great.

Is there a change log link ?

If /etc/kernel/cmdline did not exist and if you did not run grub2-mkconfig then there would be no problem. Kernel install would then use /proc/cmdline instead and everything would be fine.

If /etc/kernel/cmdline did exist and if it already had the correct contents you would also be fine as long as you did not run grub2-mkconfig.

Run

 rpm -q --changelog grub2-common

Also the git repositories from https://src.fedoraproject.org/rpms/grub2.git
and from https://github.com/rhboot/grub2.git.

Then git log has all the changelog.

2 Likes