[Lava-users] Fitting the LAVA overlay into an Android rootfs

Steve McIntyre steve.mcintyre at linaro.org
Wed Nov 15 16:49:33 UTC 2017


On Wed, Nov 15, 2017 at 04:43:25PM +0000, Neil Williams wrote:
>On 15 November 2017 at 16:29, Steve McIntyre <steve.mcintyre at linaro.org> wrote:
>
>    We were just discussing in IRC about potential problems with Android
>    images in LAVA, in terms of fitting the overlay.
>
>    Ideally, the Android builds would have a rootfs configured to be as
>    small as possible - it's automatically resized to fit the available
>    space at first boot, and leaving space otherwise is
>    inefficient. However, if we're going to add the LAVA test overlay into
>    the rootfs, space needs to be left for it to fit. That's not
>    *necessarily* a problem, except that at build time the Android builds
>    don't know how much space we're going to need! This leads to a bit of
>    a chicken-and-eff problem.
>
>    Anibal has already hacked around this a little bit as a workaround in
>    a job definition - see
>
>      https://validation.linaro.org/scheduler/job/1652299/definition#defline92
>
>    In the lxc, he's converting and expanding the rootfs image to make
>    more space, then converting back ready for flashing. This is still
>    quite hacky - there's still no information available there about the
>    size of the LAVA overlay. It might fit now, but what happens if
>    there's a new LAVA version next month with (hypothetically) a much
>    bigger overlay?
>
>Handling these conversions in the LXC is the best way to do this. V1 had a
>history of trying to be too flexible, helpful and things just get complicated
>and buggy precisely because of the assumptions.

Nod. Maybe add a parameter for the rootfs "overlay-resize" or similar. (handwave! :-))

>    So, I'm thinking about a better way to do things here, in 2 parts:
>
>     1 .At the point when we apply the overlay, we know roughly how big it
>        is and we could do the resizing of the image to fit directly
>        without needing this guesswork. It's a relatively easy thing to
>        do.
>
>Preferably inside the LXC.

Yes, definitely.

>     2. [Optionally] If we end up growing the rootfs image ourselves, it
>        *might* end up overflowing the size available when we come to
>        flash things, but "fastboot flash" will check this and abort. I
>        even suggested that (to fail more quickly) we could parse the GPT
>        partition table for size ourselves, but Nicolas pointed out that
>        not all jobs will necessarily have such a partition table.
>        Instead, *maybe* we could include a "maximum rootfs size"
>        parameter somewhere if we care. Otherwise, just rely on fastboot
>        doing the right thing.
>
>Depends on how that maximum size is determined. If it varies by testjob based
>on the ptable, then it will need to be provided by the test writer - probably
>as a parameter to the test shell running in the LXC. If it is actually a piece
>of device configuration, then it will need to come from LAVA via a test shell
>helper - that would be in the overlay added to the LXC not the overlay which is
>provided for addition to whichever files are to be transferred to the device.

Yup - we'll need to work out the exact details with the Android
guys. We can leave it as a future possibility, to be done only if
fastboot doesn't what we want/expect...

Cheers,
-- 
Steve McIntyre                                steve.mcintyre at linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs



More information about the Lava-users mailing list