[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>
wrote:

> [ 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
http://www.linux.codehelp.co.uk/
-------------- 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