Also see https://bugs.launchpad.net/cloud-images/+bug/2106729.
Since Oracular[1]:
Ubuntu’s systemd-networkd no longer sets UseDomains=true for managed
network interfaces. In effect, this means that search domains
configured in DHCP leases will not be reflected in /etc/resolv.conf
by default. This change aligns Ubuntu’s default behavior with that
of upstream. System administrators may choose to override this
default on a global, or per-interface basis. See systemd.network 4
for details.
The default in systemd is UseDomains=false. From systemd.network(5)[2]:
DHCP=
Furthermore, note that by default the domain name specified
through DHCP is not used for name resolution. See option
UseDomains= below.
UseDomains=
It is recommended to enable this option only on trusted
networks, as setting this affects resolution of all hostnames,
in particular of single-label names. It is generally safer to
use the supplied domain only as routing domain, rather than as
search domain, in order to not have it affect local resolution
of single-label names.
It has been reported to us by few clouds that this breaks local name
resolution. For instance, in Google Cloud Compute, users can no longer
reach instances in the same zone[3] nor Google Cloud services[4] by
their names.
Arguably, the security concerns for having this option disabled are not
valid in cloud environments. As one of our partners said:
IIUC, the motivation to disable UseDomains by default is that a
laptop might be used on an untrusted network where the domains
provided by DHCP can be a security issue, directing users to places
they don't intend.
But it's not possible for a cloud instance to be connected to an
untrusted network (barring a breached account).
The way I'm looking at this is that DHCP option 119 exists for the
express purpose of allowing a network administrator to configure the
DNS search path for computers on that network. I understand there's
a security concern if that network isn't a datacenter. But in the
cloud there's no concern (in some clouds, it's not even possible for
DHCP response packets to come from anywhere but the cloud's own
DHCP).
We should restore this setting in cloud images.
[1] https://discourse.ubuntu.com/t/oracular-oriole-release-notes/44878
[2] https://manpages.ubuntu.com/manpages/plucky/en/man5/systemd.network.5.html
[3] https://cloud.google.com/compute/docs/internal-dns
[4] https://cloud.google.com/compute/docs/metadata/overview
patch create_manifest to produce an sbom when called by an ubuntu-cpc
project. Patch all the ubuntu-cpc hooks and series files to include the
newly generated manifests, filelists, and sboms. Generates a number of
new artifacts in the builds. the snap utilized, cpc-sbom, is an open
source repo and a provided via a hidden snap. there is no intention of
publisizing the snap or how we generate sboms, however partners require
the ability to audit if required.
defensively checks if the snap is already installed, in the case of
multiple hooks being called in a single build (thus sharing a build
host), and only if called in an ubuntu-cpc project.
(cherry picked from commit 7c7b7df89dc96169db1f255d6bba901ebb63a43c)
U-Boot with distroboot has:
efi_dtb_prefixes=/ /dtb/ /dtb/current/
So we should install the device-trees into dtb/ and not dtbs/ on the EFI
system partition.
Fixes: 365435ad2dbe ("riscv: copy device trees to the ESP")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Commit f9c5020200ce ("riscv: directly copy device trees to /boot/dtbs")
incorrectly copied devicetrees into /boot/dtbs/$kvers instead of /boot/efi/dtbs,
inside the ESP and where U-boot expects them. This commit fixes this path.
Fixes: f9c5020200ce ("riscv: directly copy device trees to /boot/dtbs")
Signed-off-by: Adriano Cordova <adriano.cordova@canonical.com>
Support some systems which don't handle partition numbers
higher than 15. (LP: #2072929)
Partition 16 was added for /boot to enable cloud FDE (commit a8b2a9b01)
With current kernel we need to specify the SBI driver
for the early console to work.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
We have not built Hyperv desktop images since Jammy and with the re-introduction of HyperV for Noble we have encountered build issues caused by refactoring and removals of code assumed to be redundant but the HyperV desktop images were actually using these code paths.
In bbedffe6 we split the building of cloud images and non cloud to using an ddisk-image-uefi.binary and disk-image-uefi-non-cloud.binary respectively. In e38264ca there was a change which meant that any attempt to build hyperv images would result in incorrect disk size and incorrect disk label.
This has been fixed by ensuring that the ubuntu:desktop-preinstalled $PROJECT:$SUBPROJECT matches and sets the correct disk size and correct disk label.
A change in 76d79466 changed the logic of how the image size for amd64 images were being set. This overrode the sizes set for the desktop images incorrectly.
This commit ensures that any desktop image being created uses the correct image size.
As part of addressing LP: #2054103 [1] an update to grub-pc added a feature to be able to ensure that grub-pc
installation can happen noninteractively on cloud images.
This change is equivalent to running
```
debconf-set-selections grub-pc grub-efi/cloud_style_installation boolean true
debconf-set-selections grub-pc grub-pc/cloud_style_installation boolean true
```
These were introduced optionally to determine the install device using
`grub-probe` dynamically instead of having to fill the `grub-pc/install-devices`
debconf entry.
[1] https://bugs.launchpad.net/cloud-images/+bug/2054103
The StarFive VisionFive 2 board can boot from SPI flash or SD-card.
Install U-Boot to the SD card.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
On armhf and arm64 the QEMU virt machine provides the serial console as an
emulated AMBA PrimeCell UART which the kernel refers to as /dev/ttyAMA0.
Consider this when constructing GRUB_CMDLINE_LINUX_DEFAULT in file
/etc/default/grub.d/50-cloudimg-settings.cfg (LP: #2036730).
Reviewed-by: Gauthier Jolly <gauthier.jolly@canonical.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
minimized cloud image policy, introduced in version 23.10.16, is to not install recommends for any package
installs during build. This is to keep the image as small as possible. This also extends to
the grub related packages.
This solves the problems detailed in LP: #2037075 and aligns other arches more with amd64 install of
grub/shim packages for both minimized and non minimized ubuntu-cpc cloud image builds.
With the introduction of the 6.5 kernel for mantic on 13th September ago we are seeing image build failures
on the armhf builds. The build failure was `No kernel output for generic-lpae!`.
Introduced in the 6.4 kernel and therefore now also in 6.5 there is no generic-lpae flavor anymore. it's just generic now.
As such this commit updates the expected flavour for armhf to generic.
This is needed following the addition of the new boot partition. This
also gives us the opportunity to refactor the logic and use a case
statement instead of ifs
In order to support better support Full Disk Encryption on the clouds,
the boot assets have to sit on an un-encrypted partition. We've tried
mounting the ESP on /boot before but it didn't work as /boot has to
support linking for DPKG to work and the ESP has to be FAT.
ubuntu-cpc project binary hooks were not all producing .filelist files as they were not using
the create_manifest shared function.
This commit ensures the disk-image-uefi, disk-image-ppc64el and disk-image-uefi-non-cloud hooks create
a filelist during build.
As a result of not installing recommended packages the packages required to run `grub-install`
are no longer installed by default.
To ensure we can successfully run `grub-install` we install both `grub-pc` and `grub2-common`
packages.
As a result of not installing recommended packages we have dangling symlink `/boot/initrd.img.old`
As per the preceding `/boot/initrd.img` cleanup. Cleanup of `/boot/initrd.img.old`
only happens if it is a dangling symlink.
These `rm` commands also have `--verbose` flags now to make it easier when debugging logs
While attempting to run autopkgtest locally, the test stops at the
following command:
ssh-keygen -t ed25519 -C ubuntu_vagrant_insecure_key -b 4096 -f
/tmp/tmp.VuAfnsBv1G/vagrant_insecure_key
This is found in live-build/ubuntu-cpc/hooks.d/base/vagrant.binary
It appears to be waiting for a passphrase, as running that outside of
adt gives a more helpful "Enter passphrase" prompt.
Explicitly set the passphrase to empty with the `-N` argument.
EDK II is available for the StarFive VisionFive 2 board. As it is larger
than U-Boot we need to increase the size of the loader 2 partition to
accommodate it.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Now that we have the cloud-minimal seed for minimized cloud
image builds, we should drop all the workarounds and hacks
we once needed when we were using the server seed. We can
directly use the new metapackage and get rid of the tasks and
other autoremoves, et al.
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.
Remove kvm-image altogether.
Previously for minimal image replace_kernel function replaced virtual
images with kvm, and called force_boot_without_initramfs. Now simply
call force_boot_without_initramfs for minimal image without replacing
kernel flavour.
This also means minimal images can now be built for arm64 and armhf.
Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
