-
Notifications
You must be signed in to change notification settings - Fork 70
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
Run bootc install failed in AWS EC2 ARM instance with error "Failed to invoke efibootmgr" #291
Comments
@bcrochet looks like the same thing you're hitting on c9s+x86+efi ? |
@jeckersb Correct. I've seen this on baremetal and VMs on amd64. The key is that the systems are booting in UEFI mode and not in Legacy/BIOS mode. |
So far I've tracked it down to bootupctl calling efibootmgr, and efibootmgr is failing. While manually in a container with /target/boot/{,efi} mounted, as well as /boot/{,efi}, efibootmgr outputs this:
|
We can't do anything if the EFI state is immutable. xref containers/bootc#291 Signed-off-by: Colin Walters <walters@verbum.org>
This will be fixed over in coreos/bootupd#610 - will test this e2e when I get a minute. |
I just did
|
Hmm wait you did that without the above bootupd PR and it worked? That seems...weird. Wait, I think the reason that works actually is because you're effectively bind mounting in an empty directory you're making bootupd think efi isn't enabled at all. |
I have an EFI stream9 VM and that directory has a whole bunch of stuff:
(no clue what any of that actually does, but it's there!) |
It represents firmware level variables. On AWS there apparently are no persistent EFI variables, so in theory it should work to simply not set the Anyways I believe the bootupd change will fix this, but needs testing. |
Yes.
I think it's actually the opposite. The directory is populated on the host via an Basically, if that dir is not populated, bootupd assumes that EFI isn't enabled. Really it's efibootmgr, which I did verify gives a non-zero errorcode and the 'EFI variables are not supported' message, thus causing bootupd to fail. From an AWS page: UEFI variable persistence
FWIW, I've seen this situation on both baremetal and a VM. However, I'm having trouble replicating that situation. When I do, I'll update here.
In the meantime, I will give a whirl to the bootupd fix. |
Ahh OK sorry you may be right indeed! And the bootupd PR is probably unnecessary. (I think what confused me just now is that I happened to be testing this out by launching a C9S machine, but our C9S images are only configured for legacy boot...) So indeed, let's try changing things as you suggest to ensure that mount is present in the container. |
I can help testing if you have a PR or scratch build. |
Hmm so in the GCP instance I'm testing, |
Ahhh now I understand, it's apparently just aarch64 systems that use But anyways we can clearly work around this by doing the mount internally. |
@bcrochet I see two ways to go about this. First, we can simply document doing However, our So one approach here is something like this:
The 3rd option is to dynamically mutate our own mounts, but this requires the new kernel mount APIs that I don't think are in C9S for example yet. |
Definitely a clean path, with just a doc change.
And I would lean here, as you said, because of the podman invocation getting longer and longer. And it becomes unclear as to why certain params are there and just become cargo-culted. And if any of those are no longer necessary, they are not likely to be removed from the hive conciousness.
I'm not even going there. :) |
Especially on ARM, which utilizes UEFI for booting in most cases, it is important that the /sys/firmware/efi/efivars be mounted and populated, otherwise bootc will fail to complete a to-filesystem installation. This patch attempts a mount as long as the hosts efivars directory has an entry, signifying the system is at least capable of UEFI. Note that it is sufficient to just attempt to mount efivars. If it's already mounted elsewhere, it triggers the mount to be made at the /sys location. Fixes containers#291 Signed-off-by: Brad P. Crochet <brad@redhat.com>
Especially on ARM, which utilizes UEFI for booting in most cases, it is important that the /sys/firmware/efi/efivars be mounted and populated, otherwise bootc will fail to complete a to-filesystem installation. This patch attempts a mount as long as the hosts efivars directory has an entry, signifying the system is at least capable of UEFI. Note that it is sufficient to just attempt to mount efivars. If it's already mounted elsewhere, it triggers the mount to be made at the /sys location. Fixes containers#291 Signed-off-by: Brad P. Crochet <brad@redhat.com>
Especially on ARM, which utilizes UEFI for booting in most cases, it is important that the /sys/firmware/efi/efivars be mounted and populated, otherwise bootc will fail to complete a to-filesystem installation. This patch attempts a mount as long as the hosts efivars directory has an entry, signifying the system is at least capable of UEFI. Note that it is sufficient to just attempt to mount efivars. If it's already mounted elsewhere, it triggers the mount to be made at the /sys location. Fixes containers#291 Signed-off-by: Brad P. Crochet <brad@redhat.com>
Especially on ARM, which utilizes UEFI for booting in most cases, it is important that the /sys/firmware/efi/efivars be mounted and populated, otherwise bootc will fail to complete a to-filesystem installation. This patch attempts a mount as long as the hosts efivars directory has an entry, signifying the system is at least capable of UEFI. Note that it is sufficient to just attempt to mount efivars. If it's already mounted elsewhere, it triggers the mount to be made at the /sys location. Fixes containers#291 Signed-off-by: Brad P. Crochet <brad@redhat.com>
Verified on |
I got the following error when I run
bootc install to-filesystem --replace=alongside
. I'm replace CS9 with CS9 container image.btw: ARM machine supports UEFI only.
How to reproduce:
quay.io/centos-bootc/centos-bootc:stream9
withcloud-init
installed.podman run --rm --privileged --pid=host -v /:/target --security-opt label=type:unconfined_t quay.io/xiaofwan/centos-bootc-os_replace:c96p bootc install to-filesystem --replace=alongside /target
The text was updated successfully, but these errors were encountered: