We cannot use After=snapd.service as user services cannot synchronize
with system services. Using `snap system wait seed.loaded` should work,
except for the fact that it requires polkit authentication to perform
this operation.
Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>
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>
We want the firmware updater and security center pointing to edge too.
The model only allow to select it, but we need to invoke them by
default in snap prepare-image
We need edge on the live session too so that subiquity knows about
latest and greatest on TPM FDE support. We will revert that once snapd
is released to the stable channel.
layer construction involves rsync, and that process ignores times to
avoid some of the layers being larger than they would otherwise where
the only difference is times. This saves a small amount of space,
around 14MiB, but results in files in the layers having non-intended
time values. Ensure mtime and atime in the source chroot match what is
found in the destination chroot.
To get 25.10 Desktop ISOs with TPMFDE bits, we need matching pc-kernel
and snapd otherwise we get errors like so when running
`snap prepare-image`:
WARNING: the kernel for the specified UC20+ model does not carry
assertion max formats information, assuming possibly incorrectly the
kernel revision can use the same formats as snapd
error: snapd 2.68+ is not compatible with a kernel containing snapd
prior to 2.68
Use the "dangerous" model, which allows overriding the channel, and pick
up the matching pc-kernel which is not yet on 25.10/stable, where the
non-dangerous model would expect to find it.
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
