[Automated-testing] Looking for a Debian kernel provisioning solution

[William Mills]

On 01/26/2018 06:20 PM, Bird, Timothy wrote:
>> -----Original Message-----
>> From: Rees, Kevron 
>> On Fri, Jan 26, 2018 at 12:38 PM,  <Tim.Bird at sony.com> wrote:
>>> Does LAVA control grub over the serial console?
>>>
>>
>> Yes.  So either the board itself has to be able to output console
>> information over serial, or grub has to be configured to do so.  I
>> haven't personally done grub yet.  It's possible and it's on my list
>> of things to figure out since we have some boards that do not have a
>> bios that supports serial output.
> Indeed.  I was trying to work out how to control grub if there's
> no serial console.  I'm not sure if it's possible to try serial first,
> then fall back to screen/keyboard-based operation, but that would
> be nice.
> 

I quite like the pattern where the board net boots, DHCP gives each
board its own filename via mac address, and that per-board filename is a
symlink to one of:

* a "recovery" or flasher image
* a stub boot config that just directs the rest of the boot process to
SD or USB, etc
* a trial image for testing w/o updating SD/Flash/USB/HD etc
  This can be from initramfs or via NFS boot etc
  I quite like initramfs based testing for somethings but it is not good
  for everything
  (TI does a lot of testing via NFS root which I am not a fan of)

Back in 2014 I took a crack at making a "recovery/flasher" image for
Minnowboard.  It uses EFI net boot as described in this thread.  The
TFTP payload was Grub with a custom config file.  Also bundled into the
image was a kernel and an initramfs with the tools needed to update
SD/USB (openSSH and rsync).

Bundling a Grub config file into the initial payload allows you to
control what happens w/o serial port input.  The standalone grub image I
created required zero input and booted to a system that could be
controlled via ssh.   Host scripting could then update any storage it
wished.

You could create Grub images that had config files that booted from SD
or USB etc and use the symlinks to control what is booted.

Although this standalone image was nice and independent, it is not easy
to update.  I worked on another mode where Grub just goes back to the
TFTP server to get a config script that would get new kernel and
initramfs etc.  However minnowboard EFI was too buggy for that to work
at that time.  Perhaps it is better now.

The only problem with this system is if the target does something to
change the EFI boot order or trash the EFI firmware (I don't think it
was protected on the original minnow; I don't know about more modern
versions).  I did have an external SPI flasher connected to one board.
The idea was to apply power to the flasher or the board BUT NEVER BOTH.
In this way the host could recover a corrupted EFI, EFI vars, or even
try new untested EFI firmware.  However, I never completed this part of
the work.

A bundle of my work from 2014 is here:
http://arago-project.org/files/short-term/misc/make-netbootia32.tar.bz2

The readme file from that archive is here inline:
**********************************************************************
This directory creates Grub EFI images for minnowboard to support netbooting

The standalone.bootia32.efi image works for me.
    It contains a kernel and initramfs root file system
    The image is core-image-minimal + rsync + openssh
    It contains grub support files and a grub menu
    The default for the grub menu is to boot the recovery configuration
from the grub image itself
    It also has a menu entry to boot from the SD Card and a demo menu entry
    standalone.bootia32.efi should work from a drive, but it is intended
to be used for netboot
    Have your DHCP point to it and have your TFTP server it out

The net.bootia32.efi is as close as I got to real PXE style boot
    Grub will run and pull additional config files from the TFTP server
    However when it tries to tftp a kernel using the "linux" command, it
stalls out
    I have seen this a lot at block 51 but I have also seen other values
between 50 and 100
    To try, get a grub shell and then try the command "linux
(tftp)path/to/vmlinuz"

    There are other issues with this configuration not really being PXE
style config file processing
        Currently the grub config file used would be the same for all
minnowboards on the same TFTP server
        The desire is to have each minnow read its own config file
        In this way the server can control the each minnow's boot mode
by just adjusting files on the TFTP server

The script and components I used to create these images are included here.
To recreate the images just run ./my_deploy
You can play around with the deploy script and config files.
It is easy to change kernel, rootfs, and grub menus.

The yocto-modules, yocto-native, bzImage, and .cpio.gz were obtained by
doing a bitbake build
The layer stack was:
    poky git checkout of yp-1.6 tag
    meta-intel checkout of tip of the daisy branch on 2014/05/08 (there
was no yp-1.6 tag)
    meta-minnow checkout of tip of the master branch on 2014/05/08
(there was no daisy branch)
The included local.conf was used and the command was "bitbake
core-image-minimal"
The bzImage and cpio.gz files were from:
    <build>/tmp/deploy/images/minnow
The yocto-native file was from:
    <build>/tmp/sysroots/x86_64-linux/usr/bin
The yocto-modules files were from:

<build>/tmp/work/core2-32-poky-linux/grub-efi/2.00-r2/grub-2.00/grub-core

grub-mkimage should work on most 64 bit Linux machines
If it does not or you are on 32bit, you can probably use your machine's
native version
That worked fine for me on Ubuntu 12.04 x86 64 bit
I switched just for added cleanliness

It is TODO to fold all this hackery into real recipes.
That was not the part of the problem I wanted to concentrate on in the
short time I had.

This was tested on a minnowboard (not the new minnow max).
It was tested with firmware version 1.0
firmware < 1.0 will not work.

Ensure your MAC address is not all 0's using this UEFI Shell command:
    bcfg boot dump
The MAC(...) should not be all zeros.
You can use FirmwareUpdate -m to fix your MAC address.
Your board MAC addr is on a sticker on the board.

You will need to hit the "ESC" key (twice on serial port) to get the
shell prompt and then type "exit"
You will need to do this sequence two times to get the UEFI boot menu.
Choose "ETH0 - IPv4" from the UEFI boot menu.

I tried to make the IPv4 boot entry first but the "bcfg boot mv " UEFI
command locks up the board.
I was not brave enough to try add or rm.
I will try again after I have verified I have a working SPI programming
model.

The grub "reboot" command locks up the board.

The 2nd and 3rd partitions on the Angstrom SD card from my board have
the wrong partition type.
This prevents grub from accessing partition 2 (the root fs)
It also prevents busybox's swapon -a from seeing partition 3 (the swap
partition)