[3.0][bug] Missing a 'grub-install' settings for classic image

Bug #2032586 reported by Laider Lai
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Ubuntu Image
New
Undecided
Unassigned

Bug Description

Hi,

We found if the classic image, which is generated by ubuntu-image 3.0, uses grub-efi as its boot assets, the classic environment can't update its shim.efi and grub.efi files correctly by "sudo apt upgrade".

Because its grub Debian package manifest settings are not correct.
Please reference the description from livecd-rootfs: https://git.launchpad.net/ubuntu/+source/livecd-rootfs/tree/live-build/buildd/hooks/02-disk-image-uefi.binary?h=applied/ubuntu/jammy-devel#n101

Could ubuntu-image 3.0 support to setup correct grub Debian package manifest?

[Reproduce steps]
1. Build an amd64 classic image that uses grub-efi boot assets
2. Bootup image and make sure there is a newer shim-signed and grub-efi-amd64-signed
3. "sudo apt update" and "sudo apt upgrade" to update newer shim-signed and grub-efi-amd64-signed
4. Check the checksum result for /boot/efi/EFI/ubuntu/shimx64.efi and grubx64.efi
5. The checksum result still the old version, not newer version

Tags: oem-priority
Revision history for this message
Laider Lai (laiderlai) wrote :

A possible solution for ubuntu-image 3.0 after grub is installed:
sudo grub-install --dir=/usr/lib/grub/<ARCH>-efi/ --boot-directory=/boot --efi-directory=<EFI path>/EFI --target=<ARCH>-efi --uefi-secure-boot --no-nvram

Revision history for this message
Paul Mars (upils) wrote :

Hey Laider,

I am not sure yet, but it looks like a similar issue was encountered when the ubuntu-server-arm64 image definition was set up a couple months ago. The workaround was to add grub-efi-arm64-signed and shim-signed (and grub2-common) in extra-packages.

See https://git.launchpad.net/ubuntu-images/tree/ubuntu-server-pc-arm64.yaml#n46

So in your case you may try adding grub-efi-amd64-signed and shim-signed.

Revision history for this message
Laider Lai (laiderlai) wrote (last edit ):

Hey Paul,

Unfortunately, it should be a different issue.

The root cause is there is no /boot/grub/arm64-efi/core.efi after ubuntu-image install the grub-efi-amd64-signed, shim-signed (and grub2-common) in extra-packages.

When users are upgrading the grub, postinst check core.efi should exist. Otherwise, the update process is skipped.
https://git.launchpad.net/ubuntu/+source/grub2-signed/tree/debian/grub-efi-amd64-signed.postinst?h=ubuntu/jammy-devel#n12

I confirmed the generated image by ubuntu-server-pc-arm64.yaml didn't have the /boot/grub/x86_64-efi/core.efi.

Tks.

Revision history for this message
Laider Lai (laiderlai) wrote :

Hi,

A following update for this case, the latest v3.3+snap5(rev#831) still can reproduce this issue.
Does the development team have any progress on this? Tks.

Revision history for this message
Paul Mars (upils) wrote :

Hey Laider,

We did not implement anything yet. We are currently trying to rework/improve the bootloader handling during the image build but for now we are at the design stage. This issue is part of the problem we are trying to solve.

Revision history for this message
Mate Kukri (mkukri) wrote (last edit ):

1. Do we know when this issue was introduced?
2. Do we know if any released Ubuntu images are affected by this? (This should have been a release critical bug for such images).

It seems to me that all images on https://cdimage.ubuntu.com/ are built using livecd-rootfs and are unaffected (albeit still relying on the possible deprecated grub_dpkg cloud_init module).

My main concern currently is OEM images.

Oh and I found another issue: it seems like shim-signed isn't installed at all in the resulting image itself.

Revision history for this message
Paul Mars (upils) wrote :

1. Considering the code, I suspect it was introduced during the golang rewrite (and it may also have been an issue with previous python version, but I do not really know much about them).
2. I do not think we moved the build of some images from ubuntu-image back to "full" livecd-rootfs. So I do not think any released images are affected. But I agree that would be problematic.

Be careful when checking "what" is building the image, because livecd-rootfs calls ubuntu-image, so both can be used in some cases.

Regarding missing packages, this may not be bug in ubuntu-images but something missing in the image definition (a package not explicitly listed?) or something wrong in the seed.

Revision history for this message
Laider Lai (laiderlai) wrote :

The issue is found in OEM IoT images in mid-2023.
(The OEM PC images are fine due to they use livecd-rootfs to build the image and the issue is covered by https://git.launchpad.net/ubuntu/+source/livecd-rootfs/tree/live-build/buildd/hooks/02-disk-image-uefi.binary?h=applied/ubuntu/jammy-devel#n101)

The impacted OEM IoT projects are all fixed by an OTA update (apt update meta-pkg) and we do grub-install after ubuntu-image build out the image to handle this issue for any new release images until now.
(https://git.launchpad.net/~lyoncore-team/lyoncore/+git/iot-image-builds/tree/build-classic.sh?h=classic#n416)

But we hope the "grub-install" operations can be supported into ubuntu-image by default would be better.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.