Armhf images install the `generic-lpae` kernel, while other ARCHes use the
standard `generic` kernel when building the "virtual" image flavour.
Code was looking for a kernel binary ending with -generic in armhf
builds, and failed. Add a special condition to handle armhf builds'
kernel ending with `generic-lpae`
References:
[1] https://bugs.launchpad.net/cloud-images/+bug/2029527
With the switch to the ubuntu-cloud-minimal seed, we
don't really need to purge anything now. On the contrary,
the purging of packages if not installed, fails with the
exit code of 100.
Package linux-allwinner has a kernel with the generic flavour as
dependency. Add this translation to our code checking the correct
installation.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
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
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>
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
Builds in LP with the Xenial kernel were happy with the recursive mount of
/sys inside the chroot while performing snap-preseeding but autopkgtests
with the groovy kernel failed. With the groovy kernel the build was
unable to unmount sys/kernel/slab/*/cgroup/* (Operation not permitted).
This patch mounts /sys and /sys/kernel/security in the chroot in the
same way we've added for binary hooks. This provides the paths under
/sys needed for snap-preseed while avoiding issues unmounting other
paths.
The snap-preseed command can do a number of things during the build
that are currently performed at first boot (apparmor profiles, systemd
unit generation, etc). This patch adds a call to reset the seeding and
apply these optimizations when adding a seeded snap. As a prerequisite
to calling snap-preseed we need to make /dev/mem available as well as
mounts from the host to perform this work, so those are also added here.
When we encounter a failure in 'lb binary' the launchpad builders can
only surface the build output from stdout. If the binary hook failure
implicates the archive we can not determine fault without the apt
proxy log. This patch will dump the proxy log to stdout to aid in
debugging these failures.
When getting the list of snaps to include on an image via germinate, we
process the snaps in alphabetical order. Currently we seed several
packages `gnome-foo` and also `gtk-common-themes`, the default provider
of `gtk-3-themes`. Since `gtk-common-themes` is alphabetically after
`gnome-foo`, the `seed.yaml` we generate is invalid when we are part way
through generating.
What we really care about, though, is not that the `seed.yaml` is always
valid at every step, but it is that it is valid at the *end* of seeding.
So for the germinate case, let's defer validation to happen once at the
end. Other callsites of `snap_preseed`, where callers are careful to
seed snaps in the right order, are unaffected by this.
Stefan Hammer
Utkarsh Gupta
Heinrich Schuchardt
Loïc Minier
Łukasz 'sil2100' Zemczak
Steve Langasek
Dimitri John Ledkov
Sebastien Bacher
Samir Akarioh
Jean-Baptiste Lallement
Brian Murray
Thomas Bechtold
Michael Hudson-Doyle
Dimitri John Ledkov
Robert C Jennings
Colin Watson
Iain Lane