On Mon, 1 Feb 2016 17:49:39 +0100 Alexander Couzens lynxis@fe80.eu wrote:
Hi Neil,
thanks for your help.
I got now to the state of basic testing. But there are some hacks, which needs to be solved ;).
A test run includes now the external flashing of the BIOS chip. Afterwards the system will boots from hard-drive and lava can connect via ssh.
deploy: to: flashrom is ignoring the os:, but lava requires an os: field.
The 'os' field will be important for testing - you need to hook into the Overlay classes. The flashrom deploy (or a second deploy) will need to put the overlay onto that hard-drive and unpack it. It is the 'os' of the rootfs on the hard-drive that matters.
Therefore, you should be using a second deploy that creates the rootfs to avoid problems of persistence. These are the same problems as having a persistent NFS.
http://localhost/static/docs/dispatcher-design.html#persistence
How is it possible to capture the serial output while it's booting?
Compare with the UBoot Boot classes. There will be a Connection and the actions use that to wait for the prompt. The Connection is a pexpect.spawn, so whilst waiting, the output is captured.
Or does it require another boot method.
Yes - or more likely a reuse or inheritance from the existing classes. Compare with the iPXE support.
At the moment the flashrom deployment "boots" the DUT, because "boot: ssh" expects a fully booted device.
Yes - you'd need something like the secondary media support or a second deploy to actually get a rootfs into which can be installed openssh-server (and doing the installation will require the 'os' field).
You may simply need the ExpectShellSession and AutoLogin support.