launchpad-users team mailing list archive
-
launchpad-users team
-
Mailing list archive
-
Message #07112
Re: Launchpad builder VMs upgraded to bionic
-
To:
Guilherme Piccoli <gpiccoli@xxxxxxxxxxxxx>
-
From:
Colin Watson <cjwatson@xxxxxxxxxxxxx>
-
Date:
Tue, 8 Sep 2020 17:48:43 +0100
-
Cc:
Eric Desrochers <eric.desrochers@xxxxxxxxxxxxx>, ubuntu-devel@xxxxxxxxxxxxxxxx, Dan Streetman <ddstreet@xxxxxxxxxxxxx>, Mauricio Faria de Oliveira <mfo@xxxxxxxxxxxxx>, launchpad-users@xxxxxxxxxxxxxxxxxxx
-
In-reply-to:
<CAHD1Q_y+TPacpC-rRUsoe_Z0efcUvTE-b_+V1MbaLDMkvq+9=g@mail.gmail.com>
-
Mail-followup-to:
Guilherme Piccoli <gpiccoli@xxxxxxxxxxxxx>, ubuntu-devel@xxxxxxxxxxxxxxxx, launchpad-users@xxxxxxxxxxxxxxxxxxx, doko@xxxxxxxxxx, Mauricio Faria de Oliveira <mfo@xxxxxxxxxxxxx>, Dan Streetman <ddstreet@xxxxxxxxxxxxx>, Eric Desrochers <eric.desrochers@xxxxxxxxxxxxx>
-
User-agent:
Mutt/1.10.1 (2018-07-13)
On Tue, Sep 08, 2020 at 12:57:28PM -0300, Guilherme Piccoli wrote:
> Hi Colin et.al., first of all thanks for the builder update and
> heads-up! We've noticed a failure in building cryptsetup from source,
> reported in LP #1891473 [0]. The reason for such failure is detailed
> in the LP, but a summary is:
> - cryptsetup might make use of mlock() syscall and so, restrict its
> memory usage by the memlock limit (ulimit -l), if it succeeds the
> mlock() call;
> - in Xenial, the memlock limit was extremely low, so mlock() failed
> and the cryptsetup test hereby failing (luks2-metadata validation)
> succeeded, since cryptsetup continues with no locked memory;
> -in Bionic, such limit was bumped to 16M [1], and cryptsetup succeeds
> in the memory locking procedure, but...the limit is low enough in
> order the luks2-metadata-validation-4M exceeds that and fails - worth
> to notice that chroot/containers inherit those limits from host;
> - in Focal such a limit was quite increased (to 64M), so the tests do
> not fail anymore.
>
> In my understanding, we have 2 ways of resolving that:
>
> (a) We could bump the memlock limit in PPA builders to 64M (to match
> real-life cases of Focal, specially useful for Focal packages being
> built);
The simplest and IMO best way to do this would be to SRU the systemd
change that bumped it to 64M [1] to bionic; we'd then pick that up in
the natural course of events by way of new cloud image builds. Has that
been considered? It feels as though what's happened here is simply that
the Launchpad build farm upgrade has surfaced a bug in bionic, so the
most appropriate thing to do would be to fix it in bionic.
Failing that, can somebody advise on whether there's an appropriate way
to configure this in an image without having to maintain a fork of
systemd? The workflow here is that we consume Ubuntu cloud images and
make a few small changes to them, mostly things like installing
launchpad-buildd, before publishing them to Glance for use when starting
new builder VMs.
[1] https://github.com/systemd/systemd/commit/91cfdd8d29
--
Colin Watson (he/him) [cjwatson@xxxxxxxxxxxxx]
Follow ups
References