LP: 2034253 and LP: 2027686 both deal with buildd vm images failing to
boot when removing `--removable` and the stanzas copying EFI around. We
need to remove those stanzas for launchpad builder compatibility. even
though focal and jammy weren't failing, keeping everything aligned is
important. LP: 2034253 further showed that GRUB_DISTRIBUTOR being set by
default in grub requires lsb_release, which isn't in buildd images.
That's the root of why removing the stanzas failed. Since the only image
we know of where this bug is hit with grub is buildd (because everything
else has lsb_release), rather than adding a new dependency into buildd,
or backporting grub if we don't need to, setting GRUB_DISTRIBUTOR in the
buildd hook solves the immediate issue
This now matches the cloud images (7c760864fd)
fixing bootloader updates in the buildd images, but also fixing
compatibility with using devtmpfs for losetup.
Add a file build.info on etc/cloud
with the serial information
Signed-off-by: Samir Akarioh <samir.akarioh@canonical.com>
(cherry picked from commit 105acdebc7)
Commit 245f7772bd added code to abort the build if a snap wants to
install "core" (the 16.04 runtime). That's great but there are still
some CPC maintained image builds that use snaps based on "core". So
make it possible to continue the build if the "ALLOW_CORE_SNAP" env
variable is set.
(cherry picked from commit 34735684d5)
Due to how `disk-image` file is structured, it builds BIOS and UEFI
images at the same time. However, certain images (e.g., GCE images)
require only UEFI image to be built, BIOS image is being simply
discarded. This results in longer build times.
Splitting out `disk-image-uefi` would allow images to use it instead of
`disk-image` and thus avoid building unused BIOS images.
`disk-image` now depends on `disk-image-uefi` for backward
compatibility.
(cherry picked from commit b40ce74fd6)
This fixes GCE shielded VM instances integrity monitoring failures on
focal and later. Our images are built with an empty /boot/grub/grubenv
file, however after the first boot `initrdless_boot_fallback_triggered`
is set to 0. This change in `grubenv` results in integrity monitoring
`lateBootReportEvent` error.
It seems that the only thing that's checking for this `grubenv` variable
is `grub-common.service`, and it is looking specifically for a `1`
value:
if grub-editenv /boot/grub/grubenv list | grep -q
initrdless_boot_fallback_triggered=1; then echo "grub:
GRUB_FORCE_PARTUUID set, initrdless boot paniced, fallback triggered.";
fi
Unsetting this variable instead of setting it to 0 would prevent issues
with integrity monitoring.
LP: 1960537 illustrates an issue where the calls to e2fsck in the
umount_partition call are failing due to an open file handle. At this
time, we are unable to find a root cause, and it's causing many builds
to fail for CPC. Adding a sleep 30 as a workaround as the file handle
releases within that timeframe. This does not address root cause.
John Chittum
Steve Langasek
Simon Poirier
Łukasz 'sil2100' Zemczak
Utkarsh Gupta
Samir Akarioh
Michael Hudson-Doyle
Michał Sawicz
Ivan Kapelyukhin
Dimitri John Ledkov
Thomas Bechtold
Brian Murray