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 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.
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.
Previously the Octavia certfs-ramfs element relied on the
`ecryptfs` kernel facility which on Ubuntu was compiled into the
generic kernel but omitted on the virtual machine optimized
kernel.
Attempting to install the generic kernel on non-x86 virtual
machines does often not work, so this also fixes issues with
using the tool for non-x86 architectures.
