LXD is going to support launching riscv64 virtual machines,
and for riscv64 virtual machines to be usable the console
needs to be properly set. This and other fixes are currently
done in the hook 999-cpc-fixes.chroot, which was disabled for
riscv64 and which this commit enables.
Signed-off-by: Adriano Cordova <adriano.cordova@canonical.com>
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
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>
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
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.
This is required by the new UEFI binary hook as we mount the ESP on
/boot and the ESP filesystem doesn't support symlinks.
We keep symlinks for s390x images which do not use UEFI anyway.
This allows to consolidate linux-kvm and linux-generic kernel
flavours. This brings the perfomance benefit of linux-kvm flavour to
all cloud and pre-installed images. It does trade data-safety.
LP: #2006511
Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
The cloud-init bug (see LP:1968873) got fixed now so using a sshd
config snippet should work now.
This partly reverts commit aa1be5eaaa1fdbb4c31104cc49e54b15f66c3343
but uses now 60-cloudimg-settings.conf instead of
10-cloudimg-settings.conf .
This change triggered a bug in cloud-init (see LP:1968873). cloud-init
does not recongnize sshd options set in /etc/ssh/sshd_config.d/ and
cloud-init modifies directly /etc/ssh/sshd_config which gets then
overwritten by settings from /etc/ssh/sshd_config.d/ .
This reverts commit b54d24ff3310f7ace00ab08e0dacfdc89e026f1c.
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.
armhf & arm64 images use grub. And despite disk-image &
disk-image-uefi installing all the grubs, some of the configuration is
done in the 999-cpc-fixes. Specifically removal of "quiet splash" is
done there, but not active on armhf & arm64. This results in arm
images to boot with "quiet splash".
Enable running the later portions of 999-cpc-fixes on armhf & arm64.
Drop duplicate call to update-grub, as update-grub2 is simply a
symlink to update-grub.
Add a guard around the call to reconfigure grub-pc, to only do that
when it is installed.
This makes armhf & arm64 uefi images consistent with amd64 uefi
images.
LP: #1925780
These introduced a regression for ppc64el and needs more time to bake.
This reverts commits 1deb0c68e8be6b06190402e32292c3c55134eee2 &
6dbb30f53bd3f2086021abdecaee04645c9ccda0.
* "ubuntu-cpc: Fix ppc64el grub console update"
* "ubuntu-cpc: Disable boot splash in all cloud images (LP: #1725358)"
When trying to debug an issue on ARM64 it was reported that it was
quite difficult to debug because of control codes on the console from
the splash.
For cloud image there is a chroot customization the drops 'quiet splash'
but this is only applied to amd64. It hasn't made it into other
architectures because they don't have grub by default in the chroot.
However, when we get into binary hook for the uefi disk image and it's
derivatives grub is installed and this includes architectures that were
skipped in the chroot hook.
This patch changes the cpc-fixes chroot hook to add a cloud-images
grub config with basic overrides, including dropping the boot splash,
for all architectures. For images that never get grub installed this
addition is harmless and small while ensuring that the grub experience
is consistent for images that have grub. The configuration of console
devices as hard-coded remains arch specific.
Configure cloud-init to look for its seed in the vFAT boot partition on
raspberry pi images; the corresponding gadget is configured to place the
user-data, meta-data, and network-config files there.
Source: ~waveform/ubuntu/+source/livecd-rootfs:cloud-init-boot
This patch currently only applies to the "ubuntu-cpc" project.
More and more logic has been going into the hook scripts to decide under which conditions they should run or not. As we are moving to parallelized builds of image sets, this will get even more complicated. Base hooks will have to know which image sets they belong to and modification of the dependency chain between scripts will become more complicated and prone to errors, as the number of image sets grows.
This patch introduces explicit ordering and dependency handling for scripts through the use of `series` files and an explicit syntax for dependency specification.
