Arch Linux

justm3

Member

Registered: 2019-11-12

Posts: 55

UKI boot and new NVRAM entry

I've UKI-booting for the past couple of years with no issues whatsoever.

Lately, like for a month or so, whenever a kernel update is taking place (be it linux, linux-zen, linux-lts), a new "Linux..." is created in UEFI entries.
This is an extra entry alongside the uki created one in /boot/EFI/Linux directory.

In the beginning I manually deleted that "Linux..." entry using efibootmgr.

Got fed up and created a pacman hook to automate it's removal. That works as expected.

My question is what has changed lately causing this new UEFI entry to appear ?

If there is some tweaking needed to avoid the hook, I'd appreciate the response.
Otherwise I am just looking for some information on changes that I may have missed.

TIA

-thc

Member

Registered: 2017-03-15

Posts: 1,127

Re: UKI boot and new NVRAM entry

AFAIK there is no "automatism" for creating a valid efibootmgr entry for UKIs. Most probably you have (accidentally?) created one.

Is the "stable" efibootmgr entry static and only the UKI is renewed?
Do you use hooks/presets (pacman/mkinitcpio)?

Last edited by -thc (Yesterday 05:32:33)

Head_on_a_Stick

Member

From: The Wirral

Registered: 2014-02-20

Posts: 9,003

Website

Re: UKI boot and new NVRAM entry

There are many ways to boot with a UKI. Which method are you using?

---

Jin, Jîyan, Azadî

justm3

Member

Registered: 2019-11-12

Posts: 55

Re: UKI boot and new NVRAM entry

Thank you both for responding.

Here are the configs.
There are no entries in /etc/fstab

boot is EF00
root is 8304
home is 8302

In /etc/mkinitcpio.conf.d/my-mkinitcpio.conf

HOOKS=(systemd autodetect microcode modconf kms keyboard keymap sd-vconsole block filesystems fsck)

In /etc/cmdline.d/uki-boot.conf

rw quiet loglevel=3 zswap.enabled=0 nowatchdog ipv6.disable=1 rootfstype=ext4

and in /etc/mkinitcpio.d/linux.preset

#ALL_config="/etc/mkinitcpio.conf"
ALL_kver="/boot/vmlinuz-linux"

PRESETS=('default' 'fallback')

#default_config="/etc/mkinitcpio.conf"
#default_image="/boot/initramfs-linux.img"
default_uki="/boot/EFI/Linux/arch-linux.efi"
#default_options="--splash /usr/share/systemd/bootctl/splash-arch.bmp"

#fallback_config="/etc/mkinitcpio.conf"
#fallback_image="/boot/initramfs-linux-fallback.img"
fallback_uki="/boot/EFI/Linux/arch-linux-fallback.efi"
fallback_options="-S autodetect"

and in /etc/pacman.conf the intel-ucode is prevented from being created in /boot by means of

NoExtract = boot/*-ucode.img

As for pacman hooks.
Yes I have two.
One for clearing the pacman cache (-ruk0) on updates/upgrades and the one I recently created to remove this extra entry.

This "Linux..." entry started happening, as I said, about a month or so ago.
Is it likely that I changed or messed-up with something? To be honest, I don't think so.

I am aware that I can point to the fallback /boot/EFI/BOOT/BOOTx64.EFI and get rid of it (I have not tried it) but I would prefer to keep things as they are.

Last edited by justm3 (Yesterday 17:17:48)

-thc

Member

Registered: 2017-03-15

Posts: 1,127

Re: UKI boot and new NVRAM entry

Please use "code" tags to format your posts.

HOOKS=(systemd autodetect microcode modconf kms keyboard keymap sd-vconsole block filesystems fsck)

I hope you have a very good reason for removing the "base" hook.

There are no entries in /etc/fstab

That's unusual. Are you relying on GPT automounting? If yes, you have to set up an compatible boot loader - which one do you use?

justm3

Member

Registered: 2019-11-12

Posts: 55

Re: UKI boot and new NVRAM entry

@-thc

Thank you for your comments.
In your opinion are they in anyway related to my question?

For the sake of understanding I'd say once again.
For years I boot with the configs I presented. With no issues. I have not made any changes to configurations. They are the same for years.

Yet,
For the last couple of months (roughly), when an upgrade invokes mkinitcpio, a new "Linux..." entry is added next to the uki created.
And since I cannot figure it out, I am asking for someone to enlighten me why this happens.
Nothing other than that.

Last edited by justm3 (Yesterday 17:33:20)

-thc

Member

Registered: 2017-03-15

Posts: 1,127

Re: UKI boot and new NVRAM entry

For the sake of your understanding: I am trying to solve your riddle. I am well aware of your scenario - you made that clear in your first post. There is no need for you to restate all of this - I am neither ignorant nor a moron.

I first look for unusual settings. In a lot of cases users have "tried something" in the past, forgot all about it and later a change in the OS (updates/upgrades/changed behavior) stumbles across this forgotten setting.

Then I try to make sense of the chosen configuration. In your case I assume a static efibootmgr entry pointing to a UKI image that gets upgraded. O.K. - no hint there.

And finally your empty "fstab". Yes - this is related to your question - even if you don't see it.

If you use GPT automounting you have to choose a boot loader. If you chose systemd-boot there is the possibility that "systemd-boot-update.service" is active and those updates may either create that entry or hoodwink your EFI firmware into believing that a new entry is active.

justm3

Member

Registered: 2019-11-12

Posts: 55

Re: UKI boot and new NVRAM entry

Well, I disagree with you on the fstab.
Partition mounting works just fine. The uki boots directly from UEFI.

Good point on systemd-boot-update.service.
I checked it but it is disabled.

I will be travelling tomorrow for a few days.
But I will re-examine the situation on my return and report of any findings.
Meanwhile thank you.

-thc

Member

Registered: 2017-03-15

Posts: 1,127

Re: UKI boot and new NVRAM entry

Last possibility that I can think of: mkinitcpio post hooks (/etc/initcpio/post).
(That's what I meant earlier without realizing that the main "hooks" are in /etc/mkinicpio.conf.)