[systemd-devel] systemd-boot, default entry and bootctl, oh my
Itxaka Serrano Garcia
itxaka.garcia at spectrocloud.com
Tue Dec 10 10:48:43 UTC 2024
Another weird behaviour.
I changed the loader.conf to use a glob so it picks whatever entry is, even
if boot assessment is in there:
default passive*.conf
timeout 5
console-mode max
editor no
secure-boot-enroll if-safe
This results in systemd-boot choosing the entry again and again, exhausting
the retries, but it still chooses it.
Notice that this entry has a service that its broken on purpose, so it
never reaches the boot-complete.target, and the service has an autoreboot
set. But sd-boot keeps on picking it?
type: Boot Loader Specification Type #1 (.conf)
title: Kairos (fallback) (default) (not reported/new)
id: passive.conf
source: /efi//loader/entries/passive+0-7.conf
tries: 0 left; 7 done
sort-key: 0002
efi: /efi//EFI/kairos/passive.efi
According to the automatic boot assessment docs:
If this boot also fails, on the next boot the boot loader will see the tag
+0-3, i.e. the counter reached zero.
At this point the entry will be considered “bad”, and ordered after all
non-bad entries.
The next newest boot entry is now tried, i.e. the system automatically
reverted to an earlier version.
But this seems to collide with the default value in the loader.conf being a
higher priority than the bad entry?
I would say this is a bug, or at least smells like one unless Im doing
something wrong (very probable) as even if the default entry is set to an
entry X if that entry has been marked as "bad" it should skip it unless
manually chosen from the systemd-boot menu.
Cheers,
Itxaka
On Tue, Dec 10, 2024 at 10:56 AM Itxaka Serrano Garcia <
itxaka.garcia at spectrocloud.com> wrote:
> Hey all, me again with stupid questions regarding systemd-boot, yay!
>
> seems like systemd-boot and bootctl do not agree on the default entries
> and IDs for the entries somehow?
>
> Scenario:
>
> We got 2 entries, with boot assessment enabled. One was already marked as
> good. We set the passive one as the default in the loader.conf
>
> /efi//EFI/kairos/active.efi with conf at /efi//loader/entries/active.conf
> /efi//EFI/kairos/passive.efi with conf at
> /efi//loader/entries/passive+2-1.conf
>
> bootctl shows the entry IDs as the conf name WITHOUT the assessment part:
>
> type: Boot Loader Specification Type #1 (.conf)
> title: Kairos (selected)
> id: active.conf
> source: /efi//loader/entries/active.conf
> sort-key: 0001
> efi: /efi//EFI/kairos/active.efi
>
> type: Boot Loader Specification Type #1 (.conf)
> title: Kairos (fallback) (default) (not reported/new)
> id: passive.conf
> source: /efi//loader/entries/passive+2-1.conf
> tries: 2 left; 1 done
> sort-key: 0002
> efi: /efi//EFI/kairos/passive.efi
>
>
> Also as you can see, it marks the passive.conf ID as the default entry,
> which is expected.
>
> We can also check in the loader.conf and we see that we marked the entry
> ID as the default entry:
>
> editor no
> secure-boot-enroll if-safe
> default passive.conf
> timeout 5
> console-mode max
>
> So I would expect that on reboot the passive entry is selected by default,
> as it seems like you can refer to it by ID and bootctl agrees that this is
> the default one, but as you can also see, it booted on the active entry
> instead.
>
> And in fact, if you do bootctl set-default {active.conf|passive.conf} it
> does select the proper one, at least by reported by bootctl, but then
> again, on reboot systemd-boot shows the active entry as the one selected by
> default.
>
> I'm baffled by this as I would expect this to work. Who is in the wrong
> here? loader.conf? bootctl? Me???
>
> Is this a side effect of using the efivars VS the loader.conf file?
>
> Is this the assessment in play making the good entry be higher in the
> selection? Or the sort key?
>
> Does the loader.conf default entry refer to a file name or an ID?
>
> Ideally if the entry ID is usable and without the assessment part, that
> would be nice, which is what I expected by the bootctl workflow of showsing
> and choosing an ID without the assessment part.
>
>
> Any light show on this would be helpful!
>
> Thanks!
> Itxaka
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20241210/d6866a9b/attachment-0001.htm>
More information about the systemd-devel
mailing list