For jammy and later, snap validation verifies that the kernel
version matches the livecd-rootfs version, if available. This
change bring focal in line with that paradigm. This is necessary
due to the linux-$CLOUD-5.15 kernels requiring a different
apparmor feature set that generic.
(cherry picked from commit b2f25256707373537ce6c6f37fa5d456f1958edc)
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.
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.
Initialize passwords from sources.list.
Use urllib everywhere.
This way authentication is added to all the required requests.
And incoming headers, are passed to the outgoing requests.
And all the response headers, are passed to the original client.
And all the TCP & HTTP errors are passed back to the client.
Thus should avoiding hanging requests upon failure.
Also rewrite the URI when requesting things.
This allows to use private-ppa.buildd outside of launchpad.
Signed-off-by: Dimitri John Ledkov <xnox@ubuntu.com>
(cherry picked from commit dc2a472871)
* Simplify how the subiquity client is run on the serial console in the live
server environment, breaking a unit cycle that sometimes prevents
subiquity from starting up at all. (LP: #1888497)
* Do not set the password for the installer user via cloud-init as subiquity
can now do this itself. (LP: #1933523)
Catherine Redfield
Thomas Bechtold
Steve Langasek
John Chittum
Simon Poirier
Łukasz 'sil2100' Zemczak
Utkarsh Gupta
Samir Akarioh
Michał Sawicz
Dimitri John Ledkov
Ivan Kapelyukhin
Michael Hudson-Doyle
Brian Murray
Jason C. McDonald
Jean-Baptiste Lallement