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 b54d24ff33.
3.5G is not enough for riscv64 preinstalled as the creation of the initrd fails
with the following error:
Creating config file /etc/default/grub with new version
Processing triggers for initramfs-tools (0.140ubuntu13) ...
update-initramfs: Generating /boot/initrd.img-5.15.0-1011-generic
zstd: error 25 : Write error : No space left on device (cannot write compressed block)
E: mkinitramfs failure zstd -q -1 -T0 25
update-initramfs: failed for /boot/initrd.img-5.15.0-1011-generic with 1.
dpkg: error processing package initramfs-tools (--configure):
installed initramfs-tools package post-installation script subprocess returned error exit status 1
Signed-off-by: Alexandre Ghiti <alexandre.ghiti@canonical.com>
The image created uses a UEFI bootflow, so we install grub for this board
only. We also need flash-kernel to install the dtb where grub can find
it.
This image is specifically architectured so that it can be installed on
a "factory" board, meaning using the u-boot firmware which was
originally implemented for Fedora, so we need the p3 partition that
embeds a uEnv.txt file to tell u-boot what/where to load next stage.
Signed-off-by: Alexandre Ghiti <alexandre.ghiti@canonical.com>
Define the image layout for the Nezha board.
The U-Boot SPL based boot0 may be installed starting in sector 16 or 256.
As sector 16 is incompatible with GPT partitioning use sector 256.
The primary U-Boot image is expected to start at sector 32800 and its
backup in sector 24576.
Cf. https://linux-sunxi.org/index.php?title=Allwinner_Nezha&oldid=24469
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
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.
This reverts part of a change causing regression with vmware import due to the
cdrom getting moved to SCSI while shifting controller IDs. (LP: #1970795)
Germinate doesn't take very long at all to run but downloading the
indices it operates on can take a while and nothing else in auto/config
does so not doing it every time you run "lb config" can be a real time
saver.
The code that invokes germinate already checked if the output was
already there but it was unconditionally deleted by the time control got
to that point.
LP: 1969664 tracks an issue related to the deprecation of rsa+ssh on
Jammy+ openssh server, coupled with upstream vagrant bugs, that cause
Jammy vagrant images fail to bootstrap due to ssh negotiation issues.
Moving to a different key algo from the upstream insecure key matches
Jammy's expectations, and works with older vagrant versions.
vagrant >= 2.2.16 hosts are unaffected by the issue, as an upstream
change was made. This change keep compatibility with newer vagrant
versions as well.
Readding this file per reviewer's request until CPC splits the
pipelines. Removing this file would make CPC image builds fail.
Co-authored-by: Didier Roche <didrocks@ubuntu.com>
Commit 245f7772bd 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: a808b28d47 ("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.
As wsl is an image target of ubuntu-cpc, the base seed is hardcoded to
ubuntu-server instead of wsl one. For now, add it, as for the other
cpc images, in hooks.
LP: 1944004 described an issue where a libc transition caused snapd
seccomp profiles to reference a path that no longer existed, leading to
permission denied errors. The committed fix for snapd then raised an
issue where running `snapd debug seeding` would present a
preseed-system-key and seed-restart-system-key due to a mismatch
between the running kernel capabilities and the profiles being loaded by
snapd. By mounting a cgroup2 type to /sys/fs/cgroup, the capabilities
match for snapd as mounted in the chroot. This is done similarly to
live-build/functions:138-140 where apparmour and seccomp actions are
mounted after updating the buildd.
Debian changelog.Debian.* files are already keept for minimized
builds. But those changelogs are from non-native .deb packages (see
man dh_installchangelogs). Native .deb packages name their changelog
just changelog.* . So keep them in a minimized build, too.
LP: #1943114
otherwise each and every layer above a layer with a kernel gets its own
initramfs, which is silly.
Copy/paste the cruft cleaning bit of lb_chroot_hacks to be run on
non-live layers.
for the live server build, i want to make a layer to install the kernel
into but do not want the layer itself to be published.
the implementation is a bit clunky but it works.
At this point all of the custom final_message is now obsolete.
Remove it, letting us instead use the default final_message.
Leave a note about the above.
groovy hangs during boot on ESXi when the version is greater than
10. Adding a serial port by default fixes this specific bug - increasing
the HW version will be for another branch.
This is because more investigation is needed into whether it is possible to
increment ddb.virtualHWVersion without disrupting Oracle VirtualBox images.
Initialize passwords from sources.list.
Use urllib everywhere.
This way authentication is added to all the required requests.
And incoming headers, are passed to the outgoing requests.
And all the response headers, are passed to the original client.
And all the TCP & HTTP errors are passed back to the client.
Thus should avoiding hanging requests upon failure.
Also rewrite the URI when requesting things.
This allows to use private-ppa.buildd outside of launchpad.
Signed-off-by: Dimitri John Ledkov <xnox@ubuntu.com>
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
With that, the Dockerfile modifications[0] currently done externally
are done now here. That means that the created rootfs tarball can be
directly used within a Dockerfile to create a container from scratch:
FROM scratch
ADD livecd.ubuntu-oci.rootfs.tar.gz /
CMD ["/bin/bash"]
[0]
https://github.com/tianon/docker-brew-ubuntu-core/blob/master/update.sh
This is a copy of the ubuntu-base project.
Currently ubuntu-base is used as a base for the docker/OCI container
images. The rootfs tarball that is created with ubuntu-base is
published under [0]. That tarball is used in the FROM statement of the
Dockerfile as base and then a couple of modifications are done inside
of the Dockerfile[1].
The ubuntu-oci project will include the changes that are currently
done in the Dockerfile. With that:
1) a Dockerfile using that tarball will be just a 2 line thing:
FROM scratch
ADD ubuntu-hirsute-core-cloudimg-amd64-root.tar.gz /
CMD ["/bin/bash"]
2) Ubuntu has the full control about the build process of the
docker/OCI container. No external sources (like [1]) need to be
modified anymore.
3) Ubuntu can publish containers without depending on the official
dockerhub containers[2]. Currently the containers for the AWS ECR
registry[3] use as a base[4] the official dockerhub containers. That's
no longer needed because a container just needs a Dockerfile described
in 1)
When the ubuntu-oci project has the modifications from [1] included,
we'll also update [1] to use the ubuntu-oci rootfs tarball as a base
and drop the modifications done at [1].
Note: Creating a new ubuntu-oci project instead of using ubuntu-base
will make sure that we don't break users who are currently using
ubuntu-base rootfs tarballs for doing their own thing.
[0] https://partner-images.canonical.com/core/
[1]
https://github.com/tianon/docker-brew-ubuntu-core/blob/master/update.sh
[2] https://hub.docker.com/_/ubuntu
[3] https://gallery.ecr.aws/ubuntu/ubuntu
[4]
https://launchpad.net/~ubuntu-docker-images/ubuntu-docker-images/+oci/ubuntu/+recipe/ubuntu-20.04
One can call divert_grub; replace_kernel; undivert_grub. And
replace_kernel will call into force_boot_without_initramfs, which
under certain conditions can call divert_grub &
undivert_grub. Resulting in undivert_grub called twice in a row.
When undivert_grub is called twice in a row it wipes
systemd-detect-virt binary from disk, as the rm call is unguarded to
check that there is something to divert if systemd package is
installed. And if the systemd package is not installed, it does not
check that systemd-detect-virt file is in-fact what divert_grub has
created.
Add a guard to check that systemd-detect-virt is the placeholder one,
before removing it.
LP: #1902260
Thomas Bechtold
Alexandre Ghiti
Heinrich Schuchardt
Michael Hudson-Doyle
Utkarsh Gupta
Simon Poirier
John Chittum
Michał Sawicz
Dimitri John Ledkov
Jean-Baptiste Lallement
Ivan Kapelyukhin
Łukasz 'sil2100' Zemczak
Dave Jones
Brian Murray
Steve Langasek
William Wilson
Jess Jang
Erich Eickmeyer
Didier Roche
Sebastien Bacher
Dan Bungert
Jason C. McDonald
Ethan Hsieh
Chloé Smith
Dimitri John Ledkov
Gauthier Jolly
Cody Shepherd