newboot versioning test matrix

newboot-tests.md

Intro

Tests we need to do due to version skew between gz-tools (things such as sdc-usbkey) and the PI / boot version.

Note: when we deploy a new CN, there are four elements

1. BIOS boot mode: either legacy or EFI

2. the USB key that's in the CN. Either grub or loader.

3. the PI that we're PXE booting the CN with.

4. joysetup and cn_tools.

   Both of these come from the assets0 HN zone, which has a loopback mount of /usbkey, which in turn is a copy of the HN USB key. Thus, the version of these are whatever's on the HN USB key.

In addition, post-install, the CN's gz tools come from zones/opt, and hence will stay at whatever the initially deployed version was.

In the list below, "gz-tools" includes the initial joysetup. An ellipsis means "doesn't matter".

new CN deployment

This is via PXE, so the PI itself doesn't care about the key version.

Legacy boot

1. key=grub,gz-tools=old

   Existing situation.

2. key=loader,gz-tools=old

   INVALID: need new gz-tools to understand key=loader. HN must `sdcadm experimental update-gz-tools" prior to deploying a new CN with key=loader

   sdc-usbkey will fail. update-gz-tools uses --ignore-missing, so it will silently fail to update the USB key.

3. key=grub,gz-tools=new,pi=old

   newboot sdc-usbkey and joysetup must handle key=grub. PXE-booted PI can be old.

4. key=grub,gz-tools=new,pi=new

   newboot sdc-usbkey and joysetup must handle key=grub. PI must handle key=grub

5. key=loader,gz-tools=new,pi=old

   newboot sdc-usbkey and joysetup must handle key=loader

   • can't rely on PI's usb-key.sh

6. key=loader,gz-tools=new,pi=new

   newboot sdc-usbkey and joysetup must handle key=loader

EFI boot

1. key=grub

   INVALID: will fail to load iPXE. FIXME: what about if somebody tries to chainload via snponly.efi from HN? When will it fail?

2. key=loader,gz=tools=old

   INVALID: need new gz-tools to understand key=loader. HN must `sdcadm experimental update-gz-tools" prior to deploying a new CN with key=loader

3. pi=old

   INVALID: an old PI cannot boot under EFI

4. key=loader,gz-tools=new

   newboot sdc-usbkey must handle key=loader

HN boot

In this case we are booting directly off the USB key. We therefore can presume that the PI is new enough to at least understand the USB key.

To get a key=loader, the only way for an existing PI is to reflash, which should mean that gz-tools on the HN are least old enough to understand the key.

However, the gz-tools might be newer: if the user does an update-gz-tools, then factory resets, we could be using a new joysetup.sh on an older PI. In such a case, it seems like we can presume grub?

1. sdcadm experimental update-gz-tools

   Need to test a transition from gz-tools=old->new

2. key=grub,gz-tools=new

   Need to test this with a factory reset (not full reflash)

3. key=loader

   Should test a reflash with this from a previous key=grub, gz-tools=old HN

4. key=loader,pi=old

   A user could explicitly install an oldboot PI with a loader key. Should this just be invalid? What happens?