WIP: install: Add --no-bootloader to skip bootloader setup

[martinezjavier]

Currently, the bootc install workflow assumes that the bootloader must be
managed by bootupd. This works well for server and edge environments, but
it is too inflexible for embedded or custom platforms where the bootloader
is managed externally (e.g., aboot for automotive use cases).

In these scenarios, users want to install the filesystem content (OSTree
commit, kernel, initramfs, etc) without bootc assuming that a boot or ESP
partition exists and that bootupd must be invoked to update these.

By adding a --no-bootloader option, users can have explicit control over
how the boot loading is handled, without bootc or bootupd intervention.

Note: This PR depends on @alexlarsson's #1996. If the approach is found to be
acceptable, a follow-up would be for bootc install to-filesystem to infer if the
option has to be set implicitly. For example if neither boot nor EFI partition exist.

[gemini-code-assist]

Code Review

This pull request introduces a --no-bootloader flag to skip bootloader management during installation, which is a valuable feature for custom environments. However, the current implementation has significant security implications and logic errors. In the ostree installation path, using this flag unintentionally skips all post-deployment operations, including the installation of logically bound images which may contain critical security components, potentially leaving the system in an insecure or incomplete state. Furthermore, in the composefs installation path, the --no-bootloader flag is completely ignored, leading to unexpected bootloader installation. These issues need to be addressed to ensure the flag behaves as expected and doesn't leave the system in an insecure or inconsistent state. My review includes detailed comments on how to resolve these problems.

[gemini-code-assist]

The early return when --no-bootloader is enabled causes the installer to skip all subsequent post-deployment operations, including the installation of logically bound images. This is a critical security concern as bound images often contain critical system components or security agents, and skipping their installation can leave the system in an insecure or incomplete state. Pulling bound images should be independent of bootloader installation. The check should be refactored to only wrap the bootloader installation logic, ensuring post-deployment operations are always executed. Consider wrapping only the bootloader installation logic in a conditional block, similar to:if !state.config_opts.no_bootloader { let postfetch = PostFetchState::new(state, &deployment_dir)?; if cfg!(target_arch = "s390x") { // ... bootloader logic ... } else { // ... bootloader logic ... } tracing::debug!("Installed bootloader");} else { tracing::info!("Skipping bootloader installation (--no-bootloader requested)");}// This will now run in both casestracing::debug!("Performing post-deployment operations");match bound_images { // ...}

[alexlarsson]

I agree here, we should ensure not make this return, but just skip the bootloater::install_xxx calls.

[martinezjavier]

Indeed, I've missed that. I changed now to not return early and just avoid calling to the crate::bootloader::install_via_*

[gemini-code-assist]

The no_bootloader flag is not respected in the composefs installation path. While it is used to skip bootloader setup in the ostree path, the setup_composefs_boot function (called when composefs_backend is enabled) does not check this flag and proceeds to install the bootloader via bootupd or systemd-boot. This can lead to unexpected modification of the system's bootloader, potentially overwriting a custom or secure bootloader that the user intended to preserve.

[martinezjavier]

Also skipping the crate::bootloader::install_* calls in setup_composefs_boot() if the --no-bootloader option is used.

[ckyrouac]

If the approach is found to be
acceptable, a follow-up would be for bootc install to-filesystem to infer if the
option has to be set implicitly. For example if neither boot nor EFI partition exist.

Implicitly assuming the installation target will manage its own bootloader is a bit risky. The lack of an EFI partition could be the result of a mistake which would result in an installation that is not bootable. So I think it'd be best to keep this as an explicit option.

[cgwalters]

We already detect if bootupd is missing and assume systemd-boot (except for s390x). Arguably, we could extend that and just allow bootupd to be missing, and assume that bootloader state is handled after installation.

But I dunno...

Currently, the bootc install workflow assumes that the bootloader must be
managed by bootupd. This works well for server and edge environments, but
it is too inflexible for embedded or custom platforms where the bootloader
is managed externally (e.g., aboot for automotive use cases).

Also coreos/bootupd#766 is related here in that I think there's an argument that bootupd should gain support for other things.

Anyways just for my understanding, we still relying on the ostree aboot backend (which isn't implemented for composefs), correct?

To combine these two things, how about instead of --no-bootloader we detect the presence of aboot, and set it as the backend if it's part of the tree?

[alexlarsson]

Currently, the bootc install workflow assumes that the bootloader must be
managed by bootupd. This works well for server and edge environments, but
it is too inflexible for embedded or custom platforms where the bootloader
is managed externally (e.g., aboot for automotive use cases).

Also coreos/bootupd#766 is related here in that I think there's an argument that bootupd should gain support for other things.

IMHO bootupd should be able to support more things, like rpi firmware, etc. And, it should be made to handle the aboot case "cleanly". I.e. not fall over itself if there is no EFI in the system at all. However, in the short term I think it makes sense to just drop bootupd in the "pure aboot" case, as it has no current value, and the full solution is more long term.

Anyways just for my understanding, we still relying on the ostree aboot backend (which isn't implemented for composefs), correct?

Yes. However, note that there are two ways we can use the ostree aboot backend. Either with a "pure" android boot firmware, in which case there will be no EFI partition at all, or with ukiboot, which is an EFI implementation of aboot. In the ukiboot case we do have an EFI partition, and we will need bootupd to properly install and update ukiboot.efi.

To combine these two things, how about instead of --no-bootloader we detect the presence of aboot, and set it as the backend if it's part of the tree?

So, this would be fine in the "pure aboot" case, but would not work with ukiboot. So the "detect the presence" case here need to be careful about this.

[martinezjavier]

If the approach is found to be
acceptable, a follow-up would be for bootc install to-filesystem to infer if the
option has to be set implicitly. For example if neither boot nor EFI partition exist.

Implicitly assuming the installation target will manage its own bootloader is a bit risky. The lack of an EFI partition could be the result of a mistake which would result in an installation that is not bootable. So I think it'd be best to keep this as an explicit option.

That is fair. And what about using whether bootupd is present or not as the heuristic to know if bootc has to handle the boot and EFI partitions or just ignore everything that is related to the boot loading?

Yes, it could be a mistake and bootupd should had been present but bootc could print an info message to be explicit that skipped doing the boot setup.

[ckyrouac]

Yes, it could be a mistake and bootupd should had been present but bootc could print an info message to be explicit that skipped doing the boot setup.

Not a huge deal but I prefer to limit the chances a user could end up with a non-bootable system that is difficult to troubleshoot, which could be the case if we just print a message that will likely be ignored. Ideally we would explicitly handle each bootloader we intend to support.

[cgwalters]

So, this would be fine in the "pure aboot" case, but would not work with ukiboot. So the "detect the presence" case here need to be careful about this.

Can't we detect ukiboot too?

BTW one big picture thing here is that we must support configuring things via files in the container image (also supporting CLI args is fine too), but I think the former should be generally preferred.

Previous relevant changes:

• Support stateroot and mount specs in install config file #1945
• b901498

etc.

[martinezjavier]

So, this would be fine in the "pure aboot" case, but would not work with ukiboot. So the "detect the presence" case here need to be careful about this.

Can't we detect ukiboot too?

We could but IMO explicit is better than trying to come up with heuristics and make assumptions about this.

BTW one big picture thing here is that we must support configuring things via files in the container image (also supporting CLI args is fine too), but I think the former should be generally preferred.

Previous relevant changes:

• Support stateroot and mount specs in install config file #1945
• b901498

etc.

I see. Thanks a lot for the references! Any suggestions on how the file config option should be named?

There's already a bootloader CLI arg for bootc install to-filesystem (https://bootc-dev.github.io/bootc//man/bootc-install-to-filesystem.8.html), although it seems to only be useful when used with --composefs-backend (systemd-boot is not supported for ostree-based installs).

[cgwalters]

We could but IMO explicit is better than trying to come up with heuristics and make assumptions about this.

I think we could reasonably make the detection not feel heuristic though...but it would need some bikeshedding.

I see. Thanks a lot for the references! Any suggestions on how the file config option should be named?

Well...at this point this has a very high overlap with the ostree "bootloader" backend right? I guess we could extend our enum Bootloader and make that an explicit option in the installation config.