sysroot: Support boot counting for boot entries #3310

igoropaniuk · 2024-09-19T14:28:18Z

Add support for boot counting for bootloader entries [1]. The boot counting data is stored in the name of the boot loader entry. A boot loader entry file name may contain a plus (+) followed by a number. This may optionally be followed by a minus (-) followed by a second number. The dot (.) and file name suffix (conf or efi) must immediately follow.

All "pending" entries (in the middle of boot counting) are automatically removed during creation of new boot entries for new deployments.

Testing:
$ ostree admin deploy 91fc19319be9e79d07159303dff125f40f10e5c25614630dcbed23d95e36f907 Copying /etc changes: 2 modified, 3 removed, 4 added bootfs is sufficient for calculated new size: 0 bytes Transaction complete; bootconfig swap: yes; bootversion: boot.0.1, deployment count change: 1

$ ls /boot/loader/entries
ostree-1+3.conf ostree-2+3.conf

[1] https://uapi-group.org/specifications/specs/boot_loader_specification/#boot-counting

openshift-ci · 2024-09-19T14:28:28Z

Hi @igoropaniuk. Thanks for your PR.

I'm waiting for a ostreedev member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

igoropaniuk · 2024-09-19T14:30:26Z

This PR was created for initial feedback, I'll address the naming in the tests if needed and re-push

cgwalters · 2024-09-19T20:40:16Z

I love the idea of integrating here, thanks for starting this! This came up before in at least #3032

Hmm don't we need to consider how we make this configurable? Currently systemd kernel-install parses /etc/kernel/tries. (I think we should also support a /usr/lib variant of this, but that's mostly an aside). I guess we could in theory just start honoring that file too?

igoropaniuk · 2024-09-23T12:33:13Z

@cgwalters thanks for the feedback, my concern regarding parsing /etc/kernel/tries is that it's systemd-specific config, which is not described in https://uapi-group.org/specifications/specs/boot_loader_specification/

A can add an optional autoconf flag for that

igoropaniuk · 2024-10-16T14:14:24Z

@cgwalters added support for /etc/kernel/tries as suggested
I also wrapped the functionality with an autoconf flag (--enable-boot-count), which is disabled by default.

cgwalters

Thanks so much for working on this!

configure.ac

src/libostree/ostree-sysroot-deploy.c

cgwalters · 2024-10-18T13:35:27Z

BTW, which bootloader are you looking at using this with?

igoropaniuk · 2024-10-18T15:04:08Z

@cgwalters EDK2 + systemd-boot

igoropaniuk · 2024-10-30T15:53:44Z

@cgwalters I've addressed all comments, thanks!

Add support for boot counting for bootloader entries [1]. The boot counting data is stored in the name of the boot loader entry. A boot loader entry file name may contain a plus (+) followed by a number. This may optionally be followed by a minus (-) followed by a second number. The dot (.) and file name suffix (conf or efi) must immediately follow. All "pending" entries (in the middle of boot counting) are automatically removed during creation of new boot entries for new deployments. The feature is enabled via sysroot configuration: [sysroot] boot_counting=3 Testing: $ ostree admin deploy 91fc19319be9e79d07159303dff125f40f10e5c25614630dcbed23d95e36f907 Copying /etc changes: 2 modified, 3 removed, 4 added bootfs is sufficient for calculated new size: 0 bytes Transaction complete; bootconfig swap: yes; bootversion: boot.0.1, deployment count change: 1 $ ls /boot/loader/entries ostree-1+3.conf ostree-2+3.conf [1] https://uapi-group.org/specifications/specs/boot_loader_specification/#boot-counting Signed-off-by: Igor Opaniuk <[email protected]>

igoropaniuk · 2024-10-30T17:18:00Z

@cgwalters looks like some CI tests are still failing, but all of them are unrelated to this change, for example:

2024-10-30T16:06:09.9538403Z ERROR: tests/test-commit-sign.sh - too few tests run (expected 7, got 2)
2024-10-30T16:06:09.9539247Z ERROR: tests/test-commit-sign.sh - exited with status 1

cgwalters · 2024-10-31T13:56:14Z

Yes CI failures are unrelated, will look at this soon

jlebon · 2024-10-31T16:19:55Z

man/ostree.repo-config.xml

@@ -416,6 +416,14 @@ License along with this library. If not, see <https://www.gnu.org/licenses/>.
        </listitem>
      </varlistentry>

+      <varlistentry>
+        <term><varname>boot_counting</varname></term>


Bikeshed: for consistency with other knobs in this file, boot-counting?

Also, should this be e.g. boot-counting-tries to make it clearer?

jlebon · 2024-10-31T16:20:55Z

man/ostree.repo-config.xml

+        <term><varname>boot_counting</varname></term>
+        <listitem><para>Integer value controlling the number of maximum boot attempts. The boot counting data is stored in the name of the
+        boot loader entry. A boot loader entry file name may contain a plus (+) followed by a number. This may optionally be followed by
+        a minus (-) followed by a second number. The dot (.) and file name suffix (conf or efi) must immediately follow.


Feel like a link to the spec here would be helpful.

jlebon · 2024-10-31T16:22:29Z

src/libostree/ostree-repo.c

+                                                            &boot_counting_str, NULL);
+
+    if (boot_counting_str)
+      /* Ensure boot count value is in [0,5] */


Hmm, doesn't seem required by the spec. Is that a systemd-boot requirement?

well, I took the initiative here :) . I personally don't see any reasons why we should have support for more then 5 boot attempts.

I can drop this limitation if there are objections.

jlebon · 2024-10-31T16:23:53Z

src/libostree/ostree-sysroot-deploy.c

+  if (!ostree_sysroot_get_repo (self, &repo, cancellable, error))
+    return FALSE;
+
+  return (repo->boot_counting != 0 ? TRUE : FALSE);


Suggested change

return (repo->boot_counting != 0 ? TRUE : FALSE);

return repo->boot_counting != 0;

jlebon · 2024-10-31T16:35:08Z

src/libostree/ostree-sysroot-deploy.c

+  g_autofree char *bootconf_filename;
+  if (bootloader_is_boot_count_enabled(sysroot, cancellable, error))
+    {
+      guint max_tries = bootloader_get_max_boot_tries (sysroot, cancellable, error);
+      bootconf_filename = g_strdup_printf ("%s+%u.conf", bootconf_name, max_tries);
+
+      if (!bootloader_remove_tmp_entries(bootconf_dfd, bootconf_name, max_tries, cancellable, error))
+        return FALSE;
+    }
+  else
+    {
+      bootconf_filename = g_strdup_printf ("%s.conf", bootconf_name);
+    }
+
  if (!ostree_bootconfig_parser_write_at (ostree_deployment_get_bootconfig (deployment),
-                                          bootconf_dfd, bootconf_name, cancellable, error))
+                                          bootconf_dfd, bootconf_filename, cancellable, error))


Hmm, but note that this function is called for every deployment on every update (that results in a BLS write). So this would effectively "unbless" a boot that was previously blessed (or reset to the max boots that did have some failures).

ISTM like the boot count needs to be part of e.g. the OstreeDeployment object so that we can leave it untouched when rewriting BLS entries.

Technically we can have just a boolean flag (bootable field for example) for that, and check if a filename of an old BLS entry (stored in /boot/loader.%d/entries) still has a boot counter suffix. And if it doesn't -> set OstreeDeployment->bootable, so then we can create all new BLS entries for this particular deployment without any boot counters.

The problem is that deployment index for OstreeDeployment is not static and there is no deterministic way to match existing boot entry with a specific OstreeDeployment, maybe only parsing BLS entry contents could help

The problem is that deployment index for OstreeDeployment is not static and there is no deterministic way to match existing boot entry with a specific OstreeDeployment, maybe only parsing BLS entry contents could help

There is, but that state is currently not kept around. If you look at e.g. sysroot_load_from_bootloader_configs() is where we go through the BLS entries and convert those to an ordered list of OstreeDeployments. So we could parse the counter information from the filename there and keep that state in the deployment objects.

openshift-ci bot added the needs-ok-to-test label Sep 19, 2024

igoropaniuk force-pushed the boot_count branch from 6b33424 to 8ea23c7 Compare October 16, 2024 14:13

igoropaniuk changed the title ~~[RFC] sysroot: Support boot counting for boot entries~~ sysroot: Support boot counting for boot entries Oct 16, 2024

cgwalters reviewed Oct 18, 2024

View reviewed changes

configure.ac Outdated Show resolved Hide resolved

src/libostree/ostree-sysroot-deploy.c Outdated Show resolved Hide resolved

igoropaniuk force-pushed the boot_count branch from 8ea23c7 to 4bce924 Compare October 30, 2024 15:52

igoropaniuk force-pushed the boot_count branch from 4bce924 to 57e988e Compare October 30, 2024 15:58

igoropaniuk requested a review from cgwalters October 31, 2024 13:50

jlebon reviewed Oct 31, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

sysroot: Support boot counting for boot entries #3310

sysroot: Support boot counting for boot entries #3310

igoropaniuk commented Sep 19, 2024 •

edited

Loading

openshift-ci bot commented Sep 19, 2024

igoropaniuk commented Sep 19, 2024

cgwalters commented Sep 19, 2024

igoropaniuk commented Sep 23, 2024 •

edited

Loading

igoropaniuk commented Oct 16, 2024 •

edited

Loading

cgwalters left a comment

cgwalters commented Oct 18, 2024

igoropaniuk commented Oct 18, 2024

igoropaniuk commented Oct 30, 2024

igoropaniuk commented Oct 30, 2024

cgwalters commented Oct 31, 2024

jlebon Oct 31, 2024

jlebon Oct 31, 2024

jlebon Oct 31, 2024

igoropaniuk Oct 31, 2024

jlebon Oct 31, 2024

jlebon Oct 31, 2024

igoropaniuk Oct 31, 2024

jlebon Oct 31, 2024

	return (repo->boot_counting != 0 ? TRUE : FALSE);
	return repo->boot_counting != 0;

sysroot: Support boot counting for boot entries #3310

Are you sure you want to change the base?

sysroot: Support boot counting for boot entries #3310

Conversation

igoropaniuk commented Sep 19, 2024 • edited Loading

openshift-ci bot commented Sep 19, 2024

igoropaniuk commented Sep 19, 2024

cgwalters commented Sep 19, 2024

igoropaniuk commented Sep 23, 2024 • edited Loading

igoropaniuk commented Oct 16, 2024 • edited Loading

cgwalters left a comment

Choose a reason for hiding this comment

cgwalters commented Oct 18, 2024

igoropaniuk commented Oct 18, 2024

igoropaniuk commented Oct 30, 2024

igoropaniuk commented Oct 30, 2024

cgwalters commented Oct 31, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

igoropaniuk commented Sep 19, 2024 •

edited

Loading

igoropaniuk commented Sep 23, 2024 •

edited

Loading

igoropaniuk commented Oct 16, 2024 •

edited

Loading