]> git.ipfire.org Git - thirdparty/systemd.git/commit
bless-boot: in "status" output report bad state from prev boot as "dirty"
authorLennart Poettering <lennart@poettering.net>
Wed, 7 May 2025 13:24:06 +0000 (15:24 +0200)
committerLennart Poettering <lennart@poettering.net>
Mon, 12 May 2025 11:04:16 +0000 (13:04 +0200)
commit9420a0e6cb832d6035c8cf634f11c4b2da0097bd
tree138c2cd14393df9c9678a05f066f3b87eb77011e
parent7a8372a9f1380d5e178accc3d5379dd2857da33a
bless-boot: in "status" output report bad state from prev boot as "dirty"

The bless-boot logic currently assumes that if the name of the boot
entry reported via the EFI var matches the name on disk that the state
is "indeterminate", as we haven't counted down the counter (to mark it
bad) or drop the counter (to mark it good) yet. But there's one corner
case we so far didn't care about: what if the entry already reached 0
left tries in a previous boot, i.e. if the user invoked an entry already
known to be completely bad. In that case we'd still return
"indeterminate", but that's kinda misleading, because we *know* the
currently booted entry is bad, however we inherited that fact from a
previous boot, we didn't determine it on the current.

hence, let's introduce a new status we report in this case, that is both
distinct from "bad" (which indicates whether the *current* boot is bad)
and "indirect" (which indicates the current boot has not been decided on
yet): "dirty".

Why "dirty"? To mirror "clean" which we already have, which indicates a
boot already marked good in a previous boot, which is a relatively
symmetric state.

This is a really weak api break of sorts, because it introduces a new
state we never reported before, but I think it's fine, because the old
reporting was just wrong, and in a way this is bugfix, that we now
report correctly something where previously returned kind of rubbish
(though systematic rubbish).

Replaces:  #37350
man/systemd-bless-boot.service.xml
src/bless-boot/bless-boot.c