Commit 245f7772bdb74 added code to abort the build if a snap wants to
install "core" (the 16.04 runtime). That's great but there are still
some CPC maintained image builds that use snaps based on "core". So
make it possible to continue the build if the "ALLOW_CORE_SNAP" env
variable is set.
Due to how `disk-image` file is structured, it builds BIOS and UEFI
images at the same time. However, certain images (e.g., GCE images)
require only UEFI image to be built, BIOS image is being simply
discarded. This results in longer build times.
Splitting out `disk-image-uefi` would allow images to use it instead of
`disk-image` and thus avoid building unused BIOS images.
`disk-image` now depends on `disk-image-uefi` for backward
compatibility.
The UNCONFIGURED FSTAB warning was being left in the result, the discard
option wasn't included, and the fsck flag was 0 (all in marked contrast
to the preinstalled server images).
Changes in either livecd-rootfs or ubuntu-image seem to periodically
break the transfer of the pre-allocated swapfile (copying it in such a
fashion that it winds up "with holes" and thus unable to be used as a
swapfile). Rather than fight this, just use a simple systemd service to
generate the swapfile if it doesn't exist (using fallocate to keep
things snappy).
This fixes GCE shielded VM instances integrity monitoring failures on
focal and later. Our images are built with an empty /boot/grub/grubenv
file, however after the first boot `initrdless_boot_fallback_triggered`
is set to 0. This change in `grubenv` results in integrity monitoring
`lateBootReportEvent` error.
It seems that the only thing that's checking for this `grubenv` variable
is `grub-common.service`, and it is looking specifically for a `1`
value:
if grub-editenv /boot/grub/grubenv list | grep -q
initrdless_boot_fallback_triggered=1; then echo "grub:
GRUB_FORCE_PARTUUID set, initrdless boot paniced, fallback triggered.";
fi
Unsetting this variable instead of setting it to 0 would prevent issues
with integrity monitoring.
LP: 1960537 illustrates an issue where the calls to e2fsck in the
umount_partition call are failing due to an open file handle. At this
time, we are unable to find a root cause, and it's causing many builds
to fail for CPC. Adding a sleep 30 as a workaround as the file handle
releases within that timeframe. This does not address root cause.
Currently the RISC-V preinstalled server images come with partitions that
are only 1 KiB aligned. Ext4 may use 4 KiB block size. The existing
misalignment leads to decreased performance.
Decrease the size of the loader2 partition by 34 512-byte blocks. This
results in 1 MiB alignment of the EFI and root partitions.
The remaining loader2 partition size of close to 4 MiB is still large
enough for U-Boot or a future EDK II.
Fixes: a808b28d47ec ("riscv64: build preinstalled riscv64 image with uboot SPL and CIDATA.")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
livecd-rootfs creates non-private mounts. When building locally using
the auto/build script unmounting fails.
To unmount dev/pts it is insufficient to make the mount private. Its
parents must be private too. Change teardown_mountpoint() accordingly.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Current jammy builds fail with:
dpkg: error processing archive /var/cache/\
apt/archives/grub-common_2.04-1ubuntu48_armhf.deb (--unpack):
cannot copy extracted data for './usr/share/grub/unicode.pf2' \
to '/usr/share/grub/unicode.pf2.dpkg-new': \
failed to write (No space left on device)
It hangs during booting when upgrading hardware
version ESXi after deploying image in groovy.
(Current default version is 10)
It could be resolved by adding serial port in VM
when vm version is larger than 10.
Seriaol port1 has been configured as default so
we need to change setting serial0 as false.
