[Lava-users] Fitting the LAVA overlay into an Android rootfs
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
> 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
>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.
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...
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