This has become moot now that the code block has been
moved out from live-build/functions to live-build/auto/build
so passing the argument is not needed anymore.
Presence of this field helps in determining if the image is an
unminimized image, which then can be leveraged in the unminimize
script to easily determine the image type.
Template is based on the specification with some rewording for
Ubuntu Pro as agreed.
v2:
- Enabled backports by default (I did not see that!)
- Enabled restricted, multiverse security updates
- Replaced tweaked with adjusted
v3:
- Insert an explanatory sources.list
LP: #2048129
mount_disk_image function expects root partition to be at number 1. But
some images require the root partition to be at other some other number.
For example, EKS Anywhere images for bare metal are used with Tinkerbell
deployment with a default configuration that expects the root device to
be found at /dev/sda2. The knowledge of the root device path is needed
to modify certain files in the root filesystem (e.g. cloud-init configs)
for the machine to join Kubernetes cluster control plane.
The partition number can be changed in the hook by "sgidsk --transpose".
Allow the hook to use mount_disk_image with custom root partition number
by making it an optional third parameter that defaults to 1.
ppc64el still uses /boot/vmlinux so we need to determine the boot file name as non ppc64el use /boot/vmlinuz. This
is then used to determine the kernel major minor version installed so that the correct apparmor features can be used
during snap preseeding. This preseeding was failing for ppc64el for the mantic 6.5 kernel as the /boot/vmlinuz
being checked did not exist.
Fix use of variable declared in conditional branch and used in parent
scope in snap_validate_seed. This would affect binary for images without
kernel and using "set -u". (LP: #2037338)
The image filelists created during ubuntu-cpc project image builds were not sorted.
Soring the filelists makes it easier to compare the filelists without needing to sort first.
fuse3 was previously installed through recommends but with minimized images we no longer install recommends packages.
It is only required when preseeding snaps so does not need to be present in all minimized images so does not
need to be in the cloud-minimal seed.
During Realtime kernel image build, there was an error during
validating snap seed which derivative images copied 5.19
apparmor feature and can't validate when Realtime kernel (5.15)
installed [0].
To prevent this, bind correct apparmor feature with kernel
version.
[0] https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/2024639
(cherry picked from commit 6b54faa6be6286017eb2dc701534cf780ae462ce)
Revert this change for now as /boot then becomes a FAT partition which
breaks DPKG requirements[1]. This change is going to be re-evaluated and
maybe introduced in a different way.
This is not a clean revert because of 3282efb ("ubuntu-cpc: cleanup
disk-images-uefi.binary") which we want to keep.
[1] https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_What_are_the_filesystem_requirements_by_dpkg.3F
This reverts commit 6a66666e0a5ab1ad96cb0e388f278aafbd012ffe.
Canonical Public Cloud's project seems a bad place to build images for
hardware devices however this is how things were done a we now need to
maintain this.
The recent change to mount the ESP on /boot breaks those images, instead
of adding more hacky things in the hook, create a dedicated target for
those images and use a different hook to build UEFI images.
This is driven by online encryption scenarios. In order to efficiently
encrypt the root filesystem without modifying the partition layout, the
kernel should sit in an un-encrypted /boot partition. Instead of
creating a new partition that would change the default partition layout,
we mount the ESP on /boot. We also need to then bind mount /boot on
/boot/efi because that's where Grub expects the ESP to be located.
kpartx on riscv64 appears to be racy. Rather than trying to debug these
fraught races somewhere between udev and libdevmapper, we can use losetup
which should be simpler and less error-prone.
Cloud-init cannot write directly to
/etc/NetworkManager/system-connections because subiquity may
need to emit config to /etc/netplan/00-installer.yaml and call
netplan apply for autoinstall.network use-cases.
When cloud-init's config is written directly to
/etc/NetworkManager, neither netplan nor subiquity has knowledge of
this config and this results in namespace collisions in NetworkManager
due to `netplan-` named connections and `cloud-init` connection ids
fighting over which config own a given interface name.
Deleting this config overlay allows subiquity to manage all network
setup when it needs to with netplan directly.
Subiquity already has logic to rename any unwanted netplan
configuration when it intends to write cfg and run netplan apply[1].
This should allow subiquity full control of network config when needed.
[1] https://github.com/canonical/subiquity/blob/
92ac6544cdfedfd332d8cd94dbcfad0aab994575/subiquitycore/
controllers/network.py#L267
LP: #2015605
Autoinstall directives can be provided on the grub cmdline to
cloud-init via kernel parameters like the following:
autoinstall 'ds=nocloud-net;s=http://somedomain/'
In order to support DNS resolution for NoCloud datasource at
datasource discovery time, cloud-init.service needs to be
orderered after NetworkManager.service and
NetworkManager-wait-online.service
which will have brought up applicable NICs.
Since NetworkManager is After=dbus.service, the cloud-init.service
avoids systemd ordering cycles by also dropping
Before=sysinit.target when it adds, After=NetworkManager.service and
After=NetworkManager-wait-online.service
Add this file overlay for /lib/systemd/system/cloud-init.service
because systemd drop-in files can only add constraints and not
drop prexisting service constraints.
Also add an AUTOMATION_HEADER comment to any generated files to
add discoverability in the event of future bugs/concerns.
LP: #2008952
When building locally using the auto/build script unmounting fails.
Avoid mounting via bind. Mount mountpoint/dev as devtmpfs file system and
mountpoint/dev/pts as devpts file system.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
We add a ubuntu user inside the image because we
want to have a operational nonroot user and also
be aligned with the other Ubuntu images.
Signed-off-by: Samir Akarioh <samir.akarioh@canonical.com>
This reverts commit 31d42bfd2ff86d175f389ee5bbed6f275597c185.
Disable the snap-preseed calls in the interest of
getting images built for the 22.10 beta. (LP: #1990884)"
