Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] base: ostree: add support systemd-boot automatic boot assesment #1513

Open
wants to merge 1 commit into
base: scarthgap-next
Choose a base branch
from

Conversation

igoropaniuk
Copy link
Contributor

Add support for Automatic Boot Assessment [1].
Boot entries are now created with an additional suffix, which represents the amount of maximum tries for boot counting.

[1] https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT/
Signed-off-by: Igor Opaniuk [email protected]

@igoropaniuk igoropaniuk changed the title base: ostree: add support systemd-boot automatic boot assesment [RFC] base: ostree: add support systemd-boot automatic boot assesment Sep 11, 2024
From a9e35b76fd5e47b9bc29a7113d97a4d98a973e75 Mon Sep 17 00:00:00 2001
From: Igor Opaniuk <[email protected]>
Date: Wed, 11 Sep 2024 18:03:10 +0200
Subject: [PATCH] Add support systemd-boot automatic boot assesment
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/assesment/assessment/

@ricardosalveti
Copy link
Member

Change itself looks ok, is bless boot enabled by default? Just trying to understand if once we land this patch everything will keep working the same way, until we move the confirmation to aktualizr-lite or similar.

@igoropaniuk
Copy link
Contributor Author

is bless boot enabled by default

yes, I've tested in on intel-corei7-64, systemd service configurations (systemd-bless-boot.service, boot-complete.target) and tools are installed to rootfs by default (systemd-bless-boot)

Systemd-boot EFI app handles all +n suffixes in boot entries automatically (no need to enable anything explicitly )

represents the amount of maximum tries for boot counting.

[1] https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT/
Upstream-Status: Inappropriate [lmp specific]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably set as pending here, as this is something we want to try to upstream once there is support for systemd.

@quic-roshs
Copy link

Shouldn't we be checking if the bootloader used is systemd-boot before appending the counter to the conf file?
This might be needed if we are planning to upstream the patch.

Add support for Automatic Boot Assessment [1].
Boot entries are now created with an additional suffix, which
represents the amount of maximum tries for boot counting.

[1] https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT/
Signed-off-by: Igor Opaniuk <[email protected]>
@igoropaniuk
Copy link
Contributor Author

@quic-roshs this behavior is described in Bootloader Specification (https://uapi-group.org/specifications/specs/boot_loader_specification/#boot-counting; as well as OSTree also follows it https://ostreedev.github.io/ostree/deployment/#the-system-boot), so this is not systemd-boot specific adjustments

@ricardosalveti
Copy link
Member

@quic-roshs this behavior is described in Bootloader Specification (https://uapi-group.org/specifications/specs/boot_loader_specification/#boot-counting; as well as OSTree also follows it https://ostreedev.github.io/ostree/deployment/#the-system-boot), so this is not systemd-boot specific adjustments

Is u-boot (uEnv) based boot flows reusing the same code path?

@igoropaniuk
Copy link
Contributor Author

igoropaniuk commented Sep 17, 2024

@ricardosalveti

Is u-boot (uEnv) based boot flows reusing the same code path?

yes, to create the final uEnv.txt it parses boot entries that were created before (by the function I adjusted in this PR) with create_config_from_boot_loader_entries() function (https://github.com/ostreedev/ostree/blob/main/src/libostree/ostree-bootloader-uboot.c#L102) .
The change of boot entries naming doesn't somehow affect the contents of the final uEnv.txt

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants