illumos gate

The fix for Issue 9099 introduced a regression that broke booting on a system of mine; gptzfsboot can no longer find /boot/zfsloader inside a slice of a MBR partition with a PTABLE_VTOC label inside it.

There are two varieties of Solaris VTOC disk labels; the boot code classifies them as "PTABLE_VTOC" (with 16 slices) and "PTABLE_VTOC8" (with 8). I'm uncertain of the history here but I believe the 8-slice version goes back to pre-solaris SunOS and the 16-slice version is from svr4 and was only used on solaris x86.

The system in question boots from either of a pair of ssds with an MBR in disk sector 0 which specifies a single primary partition starting at "cylinder 1"; the primary partition contains the VTOC. One slice in the VTOC contains one side of the root zfs pool; other slices contain cache and slog devices for a different pool.

31898fe72 added tests for PTABLE_VTOC8 (but not PTABLE_VTOC) in three places before recursing into the partitions identified by the label.

My system had "PTABLE_VTOC" labels and booted fine before this change.

I believe the fix is to allow PTABLE_VTOC as well as PTABLE_VTOC8 in all three places touched in 31898fe72; when I made that change and rebuilt & installed the resulting zfsloader and gptzfsboot I was able to boot again.

Workaround is to follows the model found here: "Workaround 2" here: https://wiki.openindiana.org/oi/MBR+reinstall+after+illumos+loader+update :
boot from a usb stick with bootblocks before 9099 (oi-hipster 2017.10 usb minimal image worked for me), escape out of the menu and use beadm activate to select the desired pool and root filesystem.
To make it stick, before re-running bootadm install-bootloader, copy the working gptzfsboot and zfsloader from /boot on the USB stick into /boot in the root filesystem of the BE

Marking "Urgent" because the change in 31898fe72 renders working systems unbootable.