[Lava-users] Customizing the deployment and booting actions

Neil Williams neil.williams at linaro.org
Thu Nov 9 17:10:01 UTC 2017

On 9 November 2017 at 16:05, Ros Dos Santos, Alfonso (CT RDA DS EVO OPS DIA
SE 1) <alfonso.ros-dos-santos at evosoft.com> wrote:

> Hi Steve,
> thanks for the reply. The documentation says that it is possible to
> deploy the image to a media external to the device, but it is still not
> clear to me how exactly that works.

Not so much external as just not the primary boot media. (Primary as in
"where the bootloader is installed")

> Is that referring to a shared device between the lava-slave host and the
> test device?

Secondary media relates to things like a SATA drive on a board which has
the bootloader (U-Boot or UEFI) on flash storage elsewhere. The second
media is still physically local to the device, it just isn't the top of the
boot order. What matters is that the bootloader is able to read files from
that media and boot the device using those files.

> Thanks again.
> Best,
> Alfonso
>   In such case, I imagine that the bootloader is the one responsible to
> receive and store the image. Is that right?

Most bootloaders aren't capable of writing large images to media like SATA
or even USB sticks. Instead, the idea of secondary media is to use the
bootloader to boot Linux with a ramdisk or NFS or similar. That environment
provides enough tools to mount and write to the secondary media. Then, the
device is rebooted and the bootloader reads the new kernel and supporting
files from the secondary media instead of the default boot.

> Is it possible to use linux as the bootloader? does lava consider that
> case?

It is possible but we don't have explicit support for interacting with
Linux directly. Using Linux to drop to an initramfs prompt is certainly

> In that case i would only need one device with some external media
> attached to it running linux.
> On 08.11.2017 17:38, Steve McIntyre wrote:
> > Hi Alfonso,
> >
> > On Wed, Nov 08, 2017 at 04:24:41PM +0000, Ros Dos Santos, Alfonso (CT
> RDA DS EVO OPS DIA SE 1) wrote:
> >> in our current project we have some devices that are not "directly"
> >> supported by lava. I would like to ask for you opinion on which would be
> >> the correct way to proceed.
> >>
> >> The main problem is that our devices have a EFI implementation in the
> >> firmware that is making the task of installing uboot very hard.

LAVA has UEFI support - this can be downloading Grub using PXE or it can be
executing something like Grub or fastboot as an EFI application. Then that
bootloader does the work of deploying and booting the test files - this way
you might not need to think about secondary media. You can simply netboot
the device and chain into a different bootloader which doesn't have the
restrictions living inside the firmware.

> To avoid
> >> this, we thought about serving the image through an "emulated" usb
> >> stick. On that regard, we made some progress by setting up a secondary
> >> device that would use the linux g_mass_storage module to serve the image
> >> through the USB otg port.

> >>
> >> Our setup is then:
> >>
> >> 1) The actual testing device
> >> 2) The secondary device which only serves the image with g_mass_storage
> >> 3) The host machine running the lava-slave application.
> >>
> >> We thought that we could add a new device-type template to the lava
> >> server that would somehow override the deployment and boot actions to
> >> address our setup.

Please read some of the developer documentation. This isn't about
overriding deployment or boot actions, this is about arranging a new list
of actions in a dedicated pipeline for this board. The list would including
a few new action classes written for this method.

> We tried to look into the base.jinja2 file for some
> >> sort of entry point that would allow us to, for example, run a script
> >> that would first send the image to the secondary device and secondly run
> >> the g_mass_storage module with the image file.

base.jinja2 isn't going to be enough for this. The jinja2 templates are
already handled as code and this kind of work is going to need other code
changes inside lava-dispatcher as well.

> > It sounds like you're trying to do something like what's supported via
> > LAVA's "secondary media" support?
> >
> >    https://validation.linaro.org/static/docs/v2/secondary-media.html
> >
> > although you might be adding more complexity to your tests that
> > way. If your devices already boot via UEFI, could you configure them
> > to net-boot from UEFI instead, and run your tests that way?

Netbooting from UEFI is a much simpler way of doing things. Secondary media
is complex. It requires two boot operations and two deployment operations
per test job - sometimes writing a rootfs to secondary media can be a
lengthy process. A USB stick is not generally known for fast writes.

> >
> > Cheers,
> _______________________________________________
> 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/20171109/27f05788/attachment.html>

More information about the Lava-users mailing list