New snapshot created but not set as the default boot option in systemd-boot

chris_j · March 19, 2026, 5:09am

Hello!

Hoping I can get some help getting to the bottom of a problem I’ve been having with transactional updates and the default snapshot selection in systemd-boot. The long story short is that transactional-update will successfully create a snapshot and activate it, but the default boot selection is not being switched to the new snapshot.

homeserver:~ # sdbootutil list-entries
opensuse-microos-6.19.7-1-default-306.conf
**opensuse-microos-6.19.7-1-default-305.conf**
opensuse-microos-6.19.7-1-default-304.conf
opensuse-microos-6.19.7-1-default-303.conf
opensuse-microos-6.19.7-1-default-302.conf
homeserver:~ # sdbootutil list-snapshots
302 Snapshot Update of #298
303 Snapshot Update of #302
304 Snapshot Update of #303
305 Snapshot Update of #304
**306** Snapshot Update of #305
homeserver:~ # bootctl list
         type: Boot Loader Specification Type #1 (.conf)
        title: openSUSE MicroOS 20260315 (306@6.19.7-1-default)
           id: opensuse-microos-6.19.7-1-default-306.conf
       source: /boot/efi//loader/entries/opensuse-microos-6.19.7-1-default-306+3.conf (on the EFI System Partition)
        tries: 3 left
     sort-key: opensuse-microos
      version: 306@6.19.7-1-default
        linux: /boot/efi//opensuse-microos/6.19.7-1-default/linux-2508a0261559570ccd3719c662339710288c296b
       initrd: /boot/efi//opensuse-microos/6.19.7-1-default/initrd-426322798fd77e6e68ad3cd62c362c97f4388ab0
      options: root=/dev/mapper/cr_root splash=silent swapaccount=1 quiet security=selinux selinux=1 enforcing=1 mitigations=auto measure-pcr-validator.ignore=yes rootflags=subvol=@/.snapshots/306/snapshot s>

         type: Boot Loader Specification Type #1 (.conf)
        title: openSUSE MicroOS 20260315 (305@6.19.7-1-default) (default) (selected)
           id: opensuse-microos-6.19.7-1-default-305.conf
       source: /boot/efi//loader/entries/opensuse-microos-6.19.7-1-default-305.conf (on the EFI System Partition)
     sort-key: opensuse-microos
      version: 305@6.19.7-1-default
        linux: /boot/efi//opensuse-microos/6.19.7-1-default/linux-2508a0261559570ccd3719c662339710288c296b
       initrd: /boot/efi//opensuse-microos/6.19.7-1-default/initrd-426322798fd77e6e68ad3cd62c362c97f4388ab0
      options: root=/dev/mapper/cr_root splash=silent swapaccount=1 quiet security=selinux selinux=1 enforcing=1 mitigations=auto measure-pcr-validator.ignore=yes rootflags=subvol=@/.snapshots/305/snapshot s>

For some extra context, I am running a MicroOS server with transactional-update.timer enabled to automate updates daily, I’ve configured the drives with full disk encryption, TPM2.0 unlock, and systemd-boot.

I have done some debugging and haven’t managed to find a command through sdbootutil that will successfully set the default entry, yet if I use bootctl directly it is updated correctly, for example:

homeserver:~ # sdbootutil get-default
opensuse-microos-6.19.7-1-default-305.conf
homeserver:~ # sdbootutil set-default opensuse-microos-6.19.7-1-default-306.conf
homeserver:~ # sdbootutil get-default
opensuse-microos-6.19.7-1-default-305.conf
homeserver:~ # bootctl set-default opensuse-microos-6.19.7-1-default-306.conf
homeserver:~ # sdbootutil get-default
opensuse-microos-6.19.7-1-default-306.conf

Generally this hasn’t been a major issue, but I recently had a kernel update result in TPM recalculation without updating the snapshot selection - meaning the automatic unlock of the LUKS drives failed and the server required manual intervention.

keys · March 28, 2026, 9:02pm

Just echoing that I am having the same issue, thanks for posting!

However, I am not able to apply the same fix you described by manually setting the default with bootctl, and sdbootutil is generating a warning message:

WARNING: The system have EFI variables but UPDATE_NVRAM is set to “no”

~> sudo bootctl set-default opensuse-microos-6.19.9-1-default-50.conf
~> sudo sdbootutil get-default
WARNING: The system have EFI variables but UPDATE_NVRAM is set to "no"
opensuse-microos-6.19.9-1-default-45.conf
~> sudo sdbootutil set-default opensuse-microos-6.19.9-1-default-50.conf
WARNING: The system have EFI variables but UPDATE_NVRAM is set to "no"

malcolmlewis · March 29, 2026, 2:38am

@chris_j Hi, see this bug report https://bugzilla.suse.com/show_bug.cgi?id=1242144

This should work, but not needed in some time… But read the bug report first.

sdbootutil -v add-all-kernels
bootctl --no-pager list | grep "6.19.<YOUR_VERSION>" # find value of "id"
sdbootutil set-default <ID>.conf

Pieter_v · April 6, 2026, 2:09am

Just confirming I should submit a bug report?
I’m also getting the error: WARNING: The system have EFI variables but UPDATE_NVRAM is set to “no”
Noting that the above refers to transactional updates, and also the referenced bug report refers to openSUSE Aeon, I tried the referenced fix with my Tumbleweed system, which uses systemd-boot, without success.
My system:
Operating System: openSUSE Tumbleweed 20260404
KDE Plasma Version: 6.6.3
KDE Frameworks Version: 6.24.0
Qt Version: 6.11.0
Kernel Version: 6.19.5-1-default (64-bit)

Output of sudo sdbootutil list-entries
WARNING: The system have EFI variables but UPDATE_NVRAM is set to “no”
opensuse-tumbleweed-6.19.10-1-default-211.conf
opensuse-tumbleweed-6.19.9-1-default-211.conf
opensuse-tumbleweed-6.19.5-1-default-211.conf
opensuse-tumbleweed-6.19.10-1-default-866.conf
opensuse-tumbleweed-6.19.9-1-default-866.conf
opensuse-tumbleweed-6.19.5-1-default-866.conf
opensuse-tumbleweed-6.19.10-1-default-865.conf

Tried:
sdbootutil -v add-all-kernels
bootctl --no-pager list | grep “6.19.10-1” # find value of “id”
sdbootutil set-default opensuse-tumbleweed-6.19.10-1-default-211.conf
However this does not work for me.
Output of sudo sdbootutil set-default opensuse-tumbleweed-6.19.10-1-default-211.conf
WARNING: The system have EFI variables but UPDATE_NVRAM is set to “no”

So nothing changed after reboot.
Should I submit a bug report or is there something else I should try first?

ramdomPTM · April 6, 2026, 5:08am

I encountered the same problem on two of my older systems, but fixed it by

running bootctl set-default '' to clear the UEFI variables
changing UPDATE_NVRAM to "yes" in /etc/sysconfig/bootloader
re-adding the kernels

Honestly I don’t know which one of them actually matters. The newest system I installed earlier this year was fine. Hope it helps.

chris_j · April 6, 2026, 6:40am

malcolmlewis:

This should work, but not needed in some time… But read the bug report first.
sdbootutil -v add-all-kernels
bootctl --no-pager list | grep "6.19.<YOUR_VERSION>" # find value of "id"
sdbootutil set-default <ID>.conf

I read the bug report, if I’m being honest I’m not sure I fully grok it all but I can’t seem to find any relevant log entries that would indicate that the predictions failed to update even with /var/log/sdbootutil.log added and trying to dig up something in there. I found that suggested code snippet also had no effect, sdbootutil set-default <ID>.conf still failed to update the default entry.

WARNING: The system have EFI variables but UPDATE_NVRAM is set to "no"

I also had this warning in my logs. Not sure if that’s relevant to the issue.

I figured I would try and pinpoint which of these would help, so I planned to run each and then test
sdbootutil set-default <ID>.conf after each step to see if any had an effect. All it took for me was this:

bootctl set-default ''
sdbootutil set-default <ID>.conf

Now, the latest entry is shown as default in sdbootutil and bootctl and I didn’t have to run the bootctl command manually.

I also tested creating a blank snapshot with transactional-update shell and exit, and its also correctly set the default entry through transactional-update as well.

So, seems like clearing the UEFI variables has helped. I’ll keep an eye on the automatic updates to see if the fix sticks. Thanks @ramdomPTM!

Pieter_v · April 6, 2026, 10:21am

Worked for me too, thanks both.
I’m still getting the warning though.
So, is it safe to change the /etc/sysconfig/bootloader file?

ramdomPTM · April 6, 2026, 2:17pm

I believe it to be safe, for in a test VM during installation after I clicked into the bootloader config page, “Update NVRAM Entry” was automatically selected, no matter the bootloader choice. The file /etc/sysconfig/bootloader seems to be managed and read by the YaST Bootloader config, thus UPDATE_NVRAM should be default to "yes" in this case, at least in a recent snapshot. sdbootutil gained support for this variable in a recent update.

Pieter_v · April 6, 2026, 8:16pm

Okay, thanks very much

system · April 13, 2026, 8:16pm

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.