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
Łukasz 'sil2100' Zemczak
Michael Hudson-Doyle
Sebastien Bacher
Brian Murray
Jason C. McDonald
Ethan Hsieh
Dan Bungert
Chloé Smith
Steve Langasek
Dimitri John Ledkov
Thomas Bechtold
Gauthier Jolly
Cody Shepherd
Iain Lane