[ 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?

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.

 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.

Does this sound sensible?

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

_______________________________________________
Lava-users mailing list
Lava-users@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lava-users