Transactional update does not switch to new snapshot

English Install/Boot/Login
1

Hi, I am experiencing similar issues as in this thread https://forums.opensuse.org/t/new-snapshot-created-but-not-set-as-the-default-boot-option-in-systemd-boot/192639 (closed).

I have been running Microos on my server for quite some time, but I have experienced this on multiple installations after a while now.

After a transactional-update on my system, the snapshot is not correctly set in the boot order.

As an example I performed an empty transactional-update shell.

nkay@localhost:~> sudo transactional-update shell
Checking for newer version.
transactional-update 6.1.1 started
Options: shell
Separate /var detected.
tukit 6.1.1 started
Options: --log=console -c43 open 
Using 'snapper' as snapshot manager.
Found plugin "/usr/lib/tukit/plugins/10-sdbootutil.tukit"
Using snapshot 43 as base for new snapshot 44.
Found plugin "/usr/lib/tukit/plugins/10-sdbootutil.tukit"
ID: 44
Found plugin "/usr/lib/tukit/plugins/10-sdbootutil.tukit"
Found plugin "/usr/lib/tukit/plugins/10-sdbootutil.tukit"
Transaction completed.
Opening chroot in snapshot 44, continue with 'exit'
tukit 6.1.1 started
Options: --log=console call 44 bash 
Using 'snapper' as snapshot manager.
Found plugin "/usr/lib/tukit/plugins/10-sdbootutil.tukit"
Found plugin "/usr/lib/tukit/plugins/10-sdbootutil.tukit"
Found plugin "/usr/lib/tukit/plugins/10-sdbootutil.tukit"
Executing `bash`:
transactional update /# exit
exit
Application returned with exit status 0.
Found plugin "/usr/lib/tukit/plugins/10-sdbootutil.tukit"
Found plugin "/usr/lib/tukit/plugins/10-sdbootutil.tukit"
Transaction completed.
tukit 6.1.1 started
Options: --log=console close 44 
Using 'snapper' as snapshot manager.
Found plugin "/usr/lib/tukit/plugins/10-sdbootutil.tukit"
Found plugin "/usr/lib/tukit/plugins/10-sdbootutil.tukit"
Found plugin "/usr/lib/tukit/plugins/10-sdbootutil.tukit"
New default snapshot is #44 (/.snapshots/44/snapshot).
Found plugin "/usr/lib/tukit/plugins/10-sdbootutil.tukit"
Transaction completed.

Please reboot your machine to activate the changes and avoid data loss.
New default snapshot is #44 (/.snapshots/44/snapshot).
transactional-update finished

And snapper shows this:

nkay@localhost:~> sudo snapper list
  # │ Type   │ Pre # │ Date                            │ User │ Used Space │ Cleanup │ Description            │ Userdata
────┼────────┼───────┼─────────────────────────────────┼──────┼────────────┼─────────┼────────────────────────┼──────────────
 0  │ single │       │                                 │ root │            │         │ current                │
23  │ single │       │ Mon 23 Feb 2026 12:51:17 AM UTC │ root │ 629.38 MiB │ number  │ Snapshot Update of #22 │ important=yes
24  │ single │       │ Mon 02 Mar 2026 12:14:27 AM UTC │ root │ 280.80 MiB │ number  │ Snapshot Update of #23 │ important=yes
25  │ single │       │ Mon 09 Mar 2026 01:25:38 AM UTC │ root │ 291.57 MiB │ number  │ Snapshot Update of #24 │ important=yes
27  │ single │       │ Mon 23 Mar 2026 01:20:34 AM UTC │ root │ 689.47 MiB │ number  │ Snapshot Update of #25 │ important=yes
33  │ single │       │ Mon 04 May 2026 12:49:33 AM UTC │ root │   1.93 GiB │ number  │ Snapshot Update of #27 │
34  │ single │       │ Mon 11 May 2026 12:10:03 AM UTC │ root │ 702.51 MiB │ number  │ Snapshot Update of #27 │
35  │ single │       │ Mon 18 May 2026 12:32:09 AM UTC │ root │ 695.13 MiB │ number  │ Snapshot Update of #34 │
36  │ single │       │ Mon 25 May 2026 12:11:45 AM UTC │ root │ 788.36 MiB │ number  │ Snapshot Update of #34 │
37  │ single │       │ Mon 01 Jun 2026 01:31:52 AM UTC │ root │  25.85 MiB │         │ Snapshot Update of #34 │
40  │ single │       │ Tue 02 Jun 2026 06:37:04 PM UTC │ root │   1.96 MiB │ number  │ Snapshot Update of #37 │
41  │ single │       │ Tue 02 Jun 2026 07:04:35 PM UTC │ root │ 144.00 KiB │ number  │ Snapshot Update of #40 │
42  │ single │       │ Tue 02 Jun 2026 07:15:13 PM UTC │ root │ 288.00 KiB │ number  │ Snapshot Update of #41 │
43- │ single │       │ Sat 06 Jun 2026 10:40:13 AM UTC │ root │ 352.00 KiB │ number  │ Snapshot Update of #42 │
44+ │ single │       │ Sat 06 Jun 2026 12:25:21 PM UTC │ root │ 464.00 KiB │ number  │ Snapshot Update of #43 │

So it seems like the new snapshot 44 is successfully set as the new default in snapper.
However, when rebooting, the system still boot to the previous entry.
I initially thought that it was just falling back to a previous snapshot, because it couldn’t boot into the new one, but that doesn’t seem to be the case.

bootctl still shows the previous entry from snapshot 43 as default:

        type: Boot Loader Specification Type #1 (.conf)
        title: openSUSE MicroOS 20260601 (44@7.0.10-2-default) (not reported/new)
           id: opensuse-microos-7.0.10-2-default-44.conf
       source: /boot/efi//loader/entries/opensuse-microos-7.0.10-2-default-44+3.conf (on the EFI System Partition)
        tries: 3 left
     sort-key: opensuse-microos
      version: 44@7.0.10-2-default
        linux: /boot/efi//opensuse-microos/7.0.10-2-default/linux-45da41daeba5331de4cf5fa6f45a9d4c015f9436
       initrd: /boot/efi//opensuse-microos/7.0.10-2-default/initrd-43a1b0371864d2edf36fa85be4af9f694d20190f
      options: root=UUID=d192ce55-54ee-4021-8965-01cb704dc7b1 splash=silent resume=/dev/disk/by-uuid/6ecc2be7-ba1a-4a39-9c44-8e50191fc43d swapaccount=1 systemd.show_status=1 mitigations=auto quiet security=selin>

         type: Boot Loader Specification Type #1 (.conf)
        title: openSUSE MicroOS 20260601 (43@7.0.10-2-default) (default) (selected)
           id: opensuse-microos-7.0.10-2-default-43.conf
       source: /boot/efi//loader/entries/opensuse-microos-7.0.10-2-default-43.conf (on the EFI System Partition)
     sort-key: opensuse-microos
      version: 43@7.0.10-2-default
        linux: /boot/efi//opensuse-microos/7.0.10-2-default/linux-45da41daeba5331de4cf5fa6f45a9d4c015f9436
       initrd: /boot/efi//opensuse-microos/7.0.10-2-default/initrd-43a1b0371864d2edf36fa85be4af9f694d20190f
      options: root=UUID=d192ce55-54ee-4021-8965-01cb704dc7b1 splash=silent resume=/dev/disk/by-uuid/6ecc2be7-ba1a-4a39-9c44-8e50191fc43d swapaccount=1 systemd.show_status=1 mitigations=auto quiet security=selin>

sdbootutil shows 43 underlined and 44 as color coded:

nkay@localhost:~> sudo sdbootutil list-entries 
opensuse-microos-7.0.10-2-default-44.conf
opensuse-microos-7.0.10-2-default-43.conf
opensuse-microos-7.0.10-2-default-42.conf
opensuse-microos-7.0.10-2-default-41.conf
opensuse-microos-7.0.10-2-default-40.conf
opensuse-microos-7.0.10-2-default-37.conf
opensuse-microos-7.0.9-1-default-36.conf
opensuse-microos-7.0.7-1-default-35.conf
opensuse-microos-7.0.5-1-default-34.conf
opensuse-microos-7.0.2-1-default-33.conf
opensuse-microos-6.19.8-1-default-27.conf
opensuse-microos-6.19.5-2-default-25.conf
opensuse-microos-6.19.3-1-default-24.conf
opensuse-microos-6.19.2-1-default-23.conf

I can manually set the correct default entry with:

sudo sdbootutil set-default $(sudo sdbootutil list-entries | head -n1)

And it will successfully boot the new snapshot then.

Obviously, I don’t want to have to manually update the boot entries after transactional-update, especially if it is automatically executed on a timer.

Do you have any idea or starting point how to investigate or fix this?

Thanks in advance.

2

@nkay Hi and welcome to the Forum :smile:

Sounds like a regression that would need a bug report created.

I had something similar happen last year https://bugzilla.opensuse.org/show_bug.cgi?id=1242144

3

I could be very wrong, but I don’t believe transactional-update will set an empty snapshot as the new default, on it’s own.

(When I say empty snapshot, I mean a new snapshot with no changes)

aaaaaand, Looking into the transactional-update code, I’m wrong.

(I’m looking at my own Kalpa system, which uses the same configurations as microos for that part of the system)

So yeah, you probably need to file a bug.

4

Thanks for your response.

Well, if it behaved differently for an “empty” transactional-update I could understand that, although that would still be awkward, since it produces a new snapshot anyways.
But it was only an example, on my system it behaves the same for any new snapshot from transactional-update, so e.g. ... pkg in ... has the same issue.

Do you happen to know which information would be helpful for a bug report?
The log from transactional-update clearly says that it marked the new snapshot as default, but it does not seem to have an effect.

5

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