After the kernel roll to linux-gcp-5.15-5.15.0-1051.59_20.04.1,
basic_ubuntu::test_snap_preseed_optimized began failuring due to
a preseed mismatch. This change adds a 5.15 apparmor configuration
to the focal branch.
(cherry picked from commit 76628691f5e584bde009f71d05c2057a624445d5)
Commit 3b2eeb0171 wrongly backported a change to not modify
/etc/ssh/sshd_config . The correct fix from ubuntu/master is
3b2eeb0171 where the file is named 60-cloudimg-settings.conf
instead of 10-cloudimg-settings.conf.
This fixes problems with cloud-init which does write
50-cloud-init.conf which should have higher priority than the provided
file from the image.
(cherry picked from commit 434b21e202)
Modifying directly /etc/ssh/sshd_config creates "problems" when
upgrading eg. from Focal to Jammy because the upgrade will ask the
user what to do with the modified config. To avoid that, put the
custom configuration into /etc/ssh/sshd_config.d/ so the upgrade of
openssh-server can just replace /etc/ssh/sshd_config without asking
the user.
(cherry picked from commit b54d24ff33)
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.