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

Neil Williams neil.williams at linaro.org
Wed Nov 15 16:43:25 UTC 2017

On 15 November 2017 at 16:29, Steve McIntyre <steve.mcintyre at linaro.org>

> [ Related-ish to the discussion in the "Fastboot - Android boot image
>   apply-overlay" thread, but also slightly different so I'm starting a
>   new discussion here... ]
> Hi folks,
> 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.

> 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.

>  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.

> Does this sound sensible?
> Cheers,
> --
> Steve McIntyre                                steve.mcintyre at linaro.org
> <http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
> _______________________________________________
> Lava-users mailing list
> Lava-users at lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lava-users


Neil Williams
neil.williams at linaro.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linaro.org/pipermail/lava-users/attachments/20171115/043b2d5a/attachment.html>

More information about the Lava-users mailing list