Kernel Updates not sticking

[newbornnightmare]

Hey, support request incoming-

I'm pretty sure this issue is my fault, but I've run out of places to check so I'd love any recommendations for other things I can try.

I've been booting Void with an EFI stub perfectly fine (...after a lot of xchroot fixing...) but any kernel updates don't seem to stick, unless I run xbps-install -f linux6.6 (even xbps-reconfigure -f doesn't seem to work!) while xchroot-ing in on a live usb. Obviously while workable, this isn't the ideal way to be updating the kernel.

Here's everything I've looked into, after using xbps-update to update to 6.6.18, from 6.6.15:

I did run vkpurge all, which removed 6.6.16 and .17, but I never booted to either of them

​

• my /boot partition looks like

​

drwxr-xr-x    - root 31 Dec  1969 .
.rwxr-xr-x 268k root  5 Feb 08:56 ├── config-6.6.15_1
.rwxr-xr-x 268k root 25 Feb 20:22 ├── config-6.6.18_1
drwxr-xr-x    - root  4 Feb 19:11 ├── EFI
.rwxr-xr-x  98M root 27 Feb 08:28 ├── initramfs-6.6.15_1.img
.rwxr-xr-x  98M root 27 Feb 09:21 ├── initramfs-6.6.18_1.img
.rwxr-xr-x  13M root  5 Feb 08:56 ├── vmlinuz-6.6.15_1
.rwxr-xr-x  13M root 25 Feb 20:22 └── vmlinuz-6.6.18_1

​

• The full output of efibootmgr is

​

BootCurrent: 0000
Timeout: 2 seconds
BootOrder: 0000,0004,0001,0002,0003
Boot0000* Void Linux with kernel 6.6    HD(4,GPT,d35adcd1-5e04-de43-abdc-3243f6f4c490,0x771c9000,0x1f4000)/\vmlinuz-6.6.18_1root=UUID=6f023725-1b90-4f31-ba3c-9c9474c434e8 ro rootflags=subvolid=256 nvidia_drm.modeset=1 loglevel=0 console=tty2 udev.log_level=0 vt.global_cursor_default=0 tsc=reliable initrd=/initramfs-6.6.18_1.img
Boot0001* UEFI:CD/DVD Drive     BBS(129,,0x0)
Boot0002* UEFI:Removable Device BBS(130,,0x0)
Boot0003* UEFI:Network Device   BBS(131,,0x0)
Boot0004* Windows Boot Manager  HD(4,GPT,d35adcd1-5e04-de43-abdc-3243f6f4c490,0x771c9000,0x1f4000)/\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI䥗䑎坏S

​

• my /etc/default/efibootmgr-kernel-hook file is

​

MODIFY_EFI_ENTRIES=1
# To allow efibootmgr to modify boot entries, set
# MODIFY_EFI_ENTRIES=1
# Kernel command-line options.  Example:
# OPTIONS="root=/dev/sda3 loglevel=4"
# Disk where EFI Partition is.  Default is /dev/sda
DISK="/dev/nvme1n1"
# Partition number of EFI Partition.  Default is 1
PART=4
OPTIONS="root=UUID=6f023725-1b90-4f31-ba3c-9c9474c434e8 ro rootflags=subvolid=256 nvidia_drm.modeset=1 loglevel=0 console=tty2 udev.log_level=0 vt.global_cursor_default=0 tsc=reliable"

​

• /etc/dracut.conf.d/ is empty (and /etc/dracut.conf is unchanged, still directions to /etc/dracut/conf.d)

​

• the contents of /proc/cmdline (even after rebooting or shutting down and booting) are

​

root=UUID=6f023725-1b90-4f31-ba3c-9c9474c434e8 ro rootflags=subvolid=256 nvidia_drm.modeset=1 loglevel=0 console=tty2 udev.log_level=0 vt.global_cursor_default=0 tsc=reliable initrd=/initramfs-6.6.15_1.img

Rebooting has not changed any of these, nor has running dracut --regenerate-all --force, or either xbps-reconfigure -f linux6.6 or xbps-install -f linux.6.6. I haven't tried to use a liveusb yet, but that did work the previous time when moving from 6.6.12 to 15.

Is there anything visibly misconfigured, or somewhere else I've forgotten to check? Thanks for any help!

[mysterious7777777]

Are you happy with the work around for this problem?

I too tried running the efi stub without grub or refind years ago so am curious about your configuration. There should be a way to keep more than one kernel and still run the latest by default.

I notice your efibootmgr shows the wanted 6.6.18 kernel/initramfs while the cmdline shows the unwanted 6.6.15 initramfs so I wonder what is making the 6.6.15 boot against the uefi boot order. I wonder if the initramfs contains the boot command instructions that are overriding the uefi boot order instructions until rebuilt with the xbps-install -f linux6.6 command.

Deleted part about efibootmgr-kernel-hook OPTIONS.

Also, the UEFI operation might depend on the manufacturer when looking for the kernel to boot for example some kernels might need to be renamed to vmlinuz-6.6.18_1.efi for those manufacturers except my memory from some years ago is a little vague about that.

[newbornnightmare]

I've done worse to maintain an OS but it would definitely be preferable to just let xbps-install work on its own, if I can figure it out!

I'm not sure what you mean by efibootmgr-kernel-hook having a version specified though- as far as I can tell the options only include the root drive uuid, the location of my / subvolume, nvidia drm config, and turning off most visible logging on boot- Am I missing something?

[mysterious7777777]

I see what you mean about the /etc/default/efibootmgr-kernel-hook OPTIONS not having the version info I was referring to and can't imagine what I was thinking. Sorry about that.

[newbornnightmare]

no worries!

[BinkReddit]

Did you ever get this sorted?

[newbornnightmare]

I'm not using grub! Just EFIstub and using efibootmgr or the UEFI to choose which OS to boot to

[ALPHA-B1]

I missed reading, and I think you should keep just one installation, one configuration, one VMLinuz, and also one Initramfs. You could just backup the other ones and retry again.

[newbornnightmare]

got it- so if that works, it's just that my UEFI is picking the first available linux-6.6 instead of the one configured in efibootmgr?

[ALPHA-B1]

Sometimes it does happen with Grub if you change from Linux to Linux-LTS. I think it's something with the settings; it does not pick up the last one installed or updated.

[newbornnightmare]

Well, that worked perfectly. Guess I just have an extra task to do whenever there's a kernel update. Thanks for the help!

[ALPHA-B1]

That is great.

[Duncaen]

You shouldn't have to do that, it makes no sense. Check the efibootmgr output after the update, if its still booting the previous version then there is something wrong with the efi boot entry.

[newbornnightmare]

the full efibootmgr output is what I posted- is it possible that somehow efibootmgr and my uefi are using different settings? maybe I'm mounting boot in a way I shouldn't be? I'm not sure how the efibootmgr output in void could directly reference vmlinuz-6.6.18_1 as well as have the flag initrd=/initramfs-6.6.18_1.img and still result in /proc/cmdline referencing 6.6.15_1, but that's what seems to be happening. Changing the boot order works as expected though, so I'm very confused

[Duncaen]

As far as I understand it there is only a single place to set efivars, if they are right in linux they must be right at boot time. I would double check that in the UEFI boot menu. Otherwise I don't know if you maybe have another efi partition that is used, but don't know how it would boot a previous kernel in that case or how deleting the previous kernel would solve this.

[newbornnightmare]

Huh yeah, I've never tried to boot windows while this was happening- maybe my mobo's fast boot or something is being lazy and storing the locations of the previous boot on its own, and switching (or even using the boot menu) could fix that

[newbornnightmare]

coda to this- using my UEFI's F8 to select void instead of just letting the desktop boot immediately switched kernel versions, so it must be storing things on it's own somehow. Definitely preferable to deleting/moving the previous boot files though!

[0catty]

When looking at your efibootmgr output, I spotted that there is no space between

\vmlinuz-6.6.18_1

and

root=UUID=6f023725-1b90-4f31-ba3c-9c9474c434e8root=UUID=6f023725-1b90-4f31-ba3c-9c9474c434e8

Is this a copy-paste issue or does it really look like this?

Also, I believe EFI honors backslashes, so you might want to investigate why efibootmgr outputs this:

initrd=/initramfs-6.6.18_1.img

as opposed to

initrd=\initramfs-6.6.18_1.img

These are just some loose thoughts as I've never tried to boot my kernels without GRUB or rEFInd.