This change enables `enable-patchelf` which is a opt-in feature for
core22 and available in snapcraft>=7.3, without this change virt-dib
escapes the sandbox and tries to consume libicuuc.so from the host
instead of the one within the snap.
$ sudo octavia-diskimage-retrofit \ jammy-server-cloudimg-amd64.img \ ubuntu-amphora-haproxy-amd64.qcow2
Image resized.
virt-dib: /snap/core22/current/usr/lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.38' not found (required by /lib/x86_64-linux-gnu/libicuuc.so.72)
virt-dib: /snap/core22/current/usr/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found (required by /lib/x86_64-linux-gnu/libicuuc.so.72)
With this change the snap runs successfully:
sudo octavia-diskimage-retrofit /var/snap/octavia-diskimage-retrofit/common/jammy-server-cloudimg-amd64.img /var/snap/octa
via-diskimage-retrofit/common/ubuntu-amphora-haproxy-amd64.qcow2
Image resized.
virt-dib: Elements: base growrootfs retrofit-dynamic-envvar dpkg
[...]
[ 2.5] Trimming /dev/sda1
[ 3.0] Sparsify in-place operation completed with no errors
Follow-up of c39bef13eda60b605873a951a50ce0c48aa1c1a7.
If we don't disable it, the system uses both the default set of servers
and the mirror specified. It's not so harmful in fully online scenarios,
but it causes issues in air-gapped or restricted environments. By
leaving the default servers, the retrofitting process has to wait for
timeout for each component like DNS timeout for archive.ubuntu.com and
it makes the process longer than usual like from a few minutes to hours
unnecessarily.
Also, the step to disable those servers must be 02- or earlier since
03-baseline-tools already uses APT so the original 42- position was too
late. Furthermore, putting multi-line content into DIB_UBUNTU_MIRROR is
not ideal but it's necessary to keep the backward compatibility. It was
nicer if we leveraged DIB_DISTRIBUTION_MIRROR in
diskimage_builder/elements/ubuntu/pre-install.d/01-set-ubuntu-mirror and
DIB_DEBIAN_COMPONENTS in the first place.
Add workaround for grub-efi-amd64-signed install failure on Jammy+
The grub-efi-amd64-signed install failure that was identified on
focal *1 now appears to be affecting Jammy. The workaround is
very slightly different as the shim-signed package relies on
grub-efi-amd64-signed so needs to be removed as well.
Follow-up to de967f6faa8ce86109ee09fb00fd7f7a2fb2e5d9.
There is no assurance of reachability to NTP servers on the internet
(chrony has the default list of servers). When the retrofitting
environment doesn't allow outbound NTP port access like being behind HTTP
proxy. The image building process gets stuck at the phase of waiting for
the time sync. As the original issue description suggests, on non ARM
architectures, using time from the host is more than sufficient so let's
not force NTP synchronization.
An ideal solution would be to accept a customized list of NTP servers
for the future.
