Since F30 and the associated upgrade of grub and friends, I find that all new kernels show up the same: Fedora 30 (Thirty)
The boot entries from F29 were converted and did include the kernel version, so initially I had three distinct menu entries to boot from. But after the third F30 kernel was installed, I have three menu entries that look alike.
I know how to handle it, but is it really intended to be this way? As I read the Boot Loader Specification it seems the idea was to show the version from the configuration file when there are more than one file with the same title.
Does this happen to everyone, or is it just me? Do others (who don’t hide their menus altogether) see menu entries including the kernel version after a couple of upgrades?
Mine shows the kernel release for each option. The entry title strings are stored in the /boot/loader/entries/ files, e.g:
$ grep -h title /boot/loader/entries/*
title Fedora (0-rescue-5593b6f732944ad491ba36d3b37def31) 30 (Thirty)
title Fedora (5.1.20-300.fc30.x86_64) 30 (Thirty)
title Fedora (5.2.5-200.fc30.x86_64) 30 (Thirty)
title Fedora (5.2.7-200.fc30.x86_64) 30 (Thirty)
Looks like kernel-install add is responsible for creating the entries, and the plugins in /usr/lib/kernel/install.d/ control its operation. I’d start there.
So you @ferdnyc actually have title lines including the version number in your config files. As I understood the BLS specs I thought the blscfg module should add the version numbers at boot time if and only if there were more than one config file with the same title. But when I read the change description you @vgaetera linked to one more time, I see it says version isn’t supported.
I took a look in /usr/lib/kernel/install.d/ as you suggest. I actually have two files in there which create a BLS config file!
20-grub.install from the package grub2-common creates a config file which includes the version number in the title line. It looks like that is what you have, @ferdnyc .
90-loaderentry.install from the package systemd-udev which creates a configuration file where only PRETTY_NAME from /etc/os-release is on the title line.
Since 20 comes before 90, the second file should will “win”. Indeed, looking at the details of the files generated on my system, it is pretty clear they come from 90-loaderentry.install. Now I wonder, why does that not happen to you? What is different? Can you see any explanation? There are a number of ways for the latter file not to do anything, but none seems very likely.
You do have a file /usr/lib/kernel/install.d/90-loaderentry.install owned by your systemd-udev, don’t you?
You do have a file /etc/machine-id, don’t you?
You do have one of the directories for ENTRY_DIR_ABS selected from line 94 and on in /usr/bin/kernel-install, don’t you?
@goeran, I can confirm that menu titles containing kernel version as @ferdnyc posted – is what I see on my system too, and I assume it should be the norm.
I’d say that means that second file get executed after the first one, not that it wins.
I’ve tried running kernel-install manually
kernel-install --verbose add 5.2.7-200.fc30.x86_64 /boot/initramfs-5.2.7-200.fc30.x86_64.img
+/usr/lib/kernel/install.d/00-entry-directory.install add 5.2.7-200.fc30.x86_64 /boot/355b843bc6c64a1eb034f91522e9ad13/5.2.7-200.fc30.x86_64 /boot/initramfs-5.2.7-200.fc30.x86_64.img
+/usr/lib/kernel/install.d/20-grub.install add 5.2.7-200.fc30.x86_64 /boot/355b843bc6c64a1eb034f91522e9ad13/5.2.7-200.fc30.x86_64 /boot/initramfs-5.2.7-200.fc30.x86_64.img
+/usr/lib/kernel/install.d/20-grubby.install add 5.2.7-200.fc30.x86_64 /boot/355b843bc6c64a1eb034f91522e9ad13/5.2.7-200.fc30.x86_64 /boot/initramfs-5.2.7-200.fc30.x86_64.img
+/usr/lib/kernel/install.d/50-depmod.install add 5.2.7-200.fc30.x86_64 /boot/355b843bc6c64a1eb034f91522e9ad13/5.2.7-200.fc30.x86_64 /boot/initramfs-5.2.7-200.fc30.x86_64.img
Running depmod -a 5.2.7-200.fc30.x86_64
+/usr/lib/kernel/install.d/50-dracut.install add 5.2.7-200.fc30.x86_64 /boot/355b843bc6c64a1eb034f91522e9ad13/5.2.7-200.fc30.x86_64 /boot/initramfs-5.2.7-200.fc30.x86_64.img
+/usr/lib/kernel/install.d/51-dracut-rescue.install add 5.2.7-200.fc30.x86_64 /boot/355b843bc6c64a1eb034f91522e9ad13/5.2.7-200.fc30.x86_64 /boot/initramfs-5.2.7-200.fc30.x86_64.img
cp: cannot stat '/boot/bls.conf': No such file or directory
sed: can't read /boot/loader/entries/355b843bc6c64a1eb034f91522e9ad13-0-rescue.conf: No such file or directory
+/usr/lib/kernel/install.d/90-loaderentry.install add 5.2.7-200.fc30.x86_64 /boot/355b843bc6c64a1eb034f91522e9ad13/5.2.7-200.fc30.x86_64 /boot/initramfs-5.2.7-200.fc30.x86_64.img
+/usr/lib/kernel/install.d/95-kernel-hooks.install add 5.2.7-200.fc30.x86_64 /boot/355b843bc6c64a1eb034f91522e9ad13/5.2.7-200.fc30.x86_64 /boot/initramfs-5.2.7-200.fc30.x86_64.img
+/usr/lib/kernel/install.d/99-grub-mkconfig.install add 5.2.7-200.fc30.x86_64 /boot/355b843bc6c64a1eb034f91522e9ad13/5.2.7-200.fc30.x86_64 /boot/initramfs-5.2.7-200.fc30.x86_64.img
It looks like them all got running… ))
The resulting entry file in my case is identical to what I had prior to running the command, except new one contains line id fedora-20190812054231-5.2.7-200.fc30.x86_64 (old entry file haven’t had such a line).
Exactly. There are a lot of exit 0 conditions in 90-loaderentry.install (which is present on my system, too), so even if it’s run it’s possible that 20-grubby.install having “gotten there first” means that 90-loaderentry.install will be preempted and do nothing.
Which seems to be the case, as its entry titles would take the form Linux $KERNEL_VERSION which isn’t what you’re seeing either, @goeran. (Your entries are titled Fedora $RELEASE.)
…Actually, there are also exit 77 calls in 20-grub.install and 20-grubby.install which, as I read the comments adjacent to them, will terminate the processing of plugins, so the higher-numbered ones will never get to run.
It looks like it’s 20-grub.install (not 20-grubby) that’s formatting our “correct” entries:
mkbls() {
local kernelver=$1 && shift
local datetime=$1 && shift
local debugname=""
local debugid=""
local flavor=""
if [[ "$kernelver" == *\+* ]] ; then
local flavor=-"${kernelver##*+}"
if [[ "${flavor}" == "-debug" ]]; then
local debugname=" with debugging"
local debugid="-debug"
fi
fi
cat <<EOF
title ${NAME} (${kernelver}) ${VERSION}${debugname}
version ${kernelver}${debugid}
linux /vmlinuz-${kernelver}
initrd /initramfs-${kernelver}.img
options \$kernelopts
id ${ID}-${datetime}-${kernelver}
grub_users \$grub_users
grub_arg --unrestricted
grub_class kernel${flavor}
EOF
}
I too believe that is the intention. It makes sense. I just can’t figure out what prevents 90-loaderentry.install from overwriting the file for everyone but me! (Yes coming later and overwriting the file is more accurate, “winning” was just loosely speaking.)
Would you (or anyone else) consider adding -xv on the first line of 90-loaderentry.install, the #! line, and then run kernel-install manually once more? I’d appreciate it very much.
You are right, and that was the file I was looking in. I just missed there were two almost identical when cut-and-pasting in my message, and picked the wrong one at that time. (They are confusingly similarly named.)
I still don’t believe that’s what’s happening. As I said a few comments back, 90-loaderentry.install would create entry titles starting with “Linux…”, not “Fedora…”, which isn’t what you’re seeing.
(Edit: Hmmm… unless $PRETTY_NAME is set before the script is even run. Then it could be set to something else.)
The difference between your system and my system is that you do not have a directory /boot/${MACHINE_ID} which I do. Since that directory doesn’t exist on your machine, 00-entry-directory.install will not create any /boot/${MACHINE_ID}/${KERNEL_VERSION}, which in turn will cause 90-loaderentry.install to quit early on.
You solved the mystery!
(As in any science, a new finding will bring new questions. In this case:
When and why was the machine id directory created on my machine? I didn’t do it manually, I’m pretty sure.
Is it really intended the existence of that directory should affect the format of the boot records?)
Edit: Probable anser to question 1: kernel-install created the directory unconditionally previously. I may have used such a version, and then it remains that way.
Have you updated your system to F30 or installed it cleanly? I remember seeing such directories on some previous Fedora releases.
But then there’s quite a few people here on Ask Fedora who upgraded their installations from previous Fedora releases, and you’re the first one with this weird bug.
Also you can look at directory and files creation/modification times (unless you’ve already removed it, of course).
I’ve updated; it’s a long time since the affected machines were initially installed.
Unfortunately, looking at the time stamps of the directory doesn’t say much. On each kernel upgrade upgrade, a new subdirectory for the new kernel is created, so the time stamps gets updated.
This feels like a bug. I tested it locally and you’re right, having a directory /boot/${MACHINE_ID} pre-existing will change the title of the entries created to generic ${PRETTY_NAME} strings.
Which is nonsensical, because while kernel-install --verbose ... shows that if that directory’s there 00-entry-directory.install does a mkdir -p /boot/${MACHINE_ID}/${KERNEL_RELEASE}, it also shows that if it’s not there, the mkdir -p doesn’t happen but /boot/${MACHINE_ID}/${KERNEL_RELEASE} is still passed in as an argument to all of the plugins, as if it’s supposed to mean something.
I feel like some code evolved in confusing ways, and this is the fallout. This bit of the kernel-install script would seem to support that theory:
if ! [[ $MACHINE_ID ]] && ! rmdir "$ENTRY_DIR_ABS"; then
echo "Warning: In kernel-install plugins, requiring ENTRY_DIR_ABS to be preset is deprecated." >&2
echo " All plugins should not put anything in ENTRY_DIR_ABS if the environment" >&2
echo " variable KERNEL_INSTALL_MACHINE_ID is empty." >&2
rm -rf "$ENTRY_DIR_ABS"
((ret+=$?))
fi
As @goeran said, " kernel-install created the directory unconditionally previously", and the plugins seem to have been written to expect the name of that directory as one of their arguments.
But then someone must’ve decided they didn’t want the functionality that’s keyed on that directory to be used, so they made the directory’s creation conditional on the existence of the parent. As long as it’s not there, the subdirectory isn’t created, and other functionality is disabled because it first checks for the existence of that dir.
But, relying on a side effect like that is the wrong way to disable unwanted functionality. For justification, see this entire bug.
(Yes coming later and overwriting the file is more accurate, “winning” was just loosely speaking.)
In this case: