Booting non-bootable SATA ports on the HP Microserver Gen8

It’s a shim to the left and a boot to the right


I have an HP Microserver Gen8 as a NAS - it’s great because:

  • It’s very quiet at idle load
  • It has 4x 3.5" forwards-firing drive bays
  • It has an internal SATA port originally for the optical drive bay perfect for a boot SSD
  • It has ILO (remote management) upgradable with a, uh, easily “purchasable” product key
  • It has upgradable CPU and RAM (Gen9 had a non-replaceable CPU)

However, it has an annoying limitation: when not using the onboard hardware RAID, with the SATA controller in AHCI mode1, you can’t boot from that 5th SATA port. It just can’t.

There’s workarounds, you can supposely pick between:

  • Switching the SATA controller to “legacy” mode, which potentially has a throughput penalty
  • Enabling the “smartarray” hardware RAID controller and make a single array with just the desired boot device in it. I have a healthy mistrust of hardware raid, and even if this left the other devices untouched it would still make replacing the boot device more annoying.
  • Or you can install your OS to a flash drive and put that in the internal USB port - but USB flash drives are terrible for speed and longevity so that’s best avoided.

What we can do though is install only a bootloader to the flash drive, and then use that to boot from the OS SSD.

Setting up the flash drive

The first part of this solution comes largely from this great post on yolops.net.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
# nuke the disk, format for MBR/bios and make a single 1 GB partition (it doesn't need to be big)
parted /dev/<disk> -- mklabel msdos
parted /dev/<disk> -- mkpart primary 1MB 1024MB
parted /dev/<disk> -- set 1 boot on

# now format the partition and install grub. N.B. that we're selecting the partition here, not the disk - e.g. sdb1 not sdb
mkfs.vfat -n grub /dev/<disk>1
mount /dev/<disk>1 /mnt
mkdir /mnt/boot
grub-install --force --no-floppy --boot-directory=/mnt/boot /dev/<disk>

grub.cfg

The blog linked above uses grub’s chainloader command with a root set to the disk we want to boot to. chainloader +1 just means “boot starting from the first sector of the disk” - i.e. the MBR.

1
2
3
4
5
6
7
8
9
set timeout=5
set default=0

menuentry "chainload"  {
  insmod part_msdos
  insmod chain
  set root=(hd5)
  chainloader +1
}

This has one major drawback - if the numbering of the disks changes for any reason, our shim bootloader won’t work any more. With 4 disks in the bays of the microserver, a disk attached to the internal SATA port appears as hd5 - however if one of the front disks was to be removed I’d bet money it would be hd4 instead.2 This is a similar issue to block device naming on linux. A more robust solution is to address disks by ID (something inherent to the disk) rather than the OS’s device node.

Sadly GRUB doesn’t support this, but it does support searching across connected disks for a filesystem UUID and booting from that:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
set timeout=5
set default=0

menuentry "chainload"  {
  play 500 334 1 334 1 0 1 334 1 0 1 261 1 334 1 0 1 392 2 0 2 196 2
  insmod part_msdos
  insmod ext2
  search --no-floppy --fs-uuid --set=root a07ca860-1d9a-4d9f-a1f9-43c64ba9844e
  chainloader /boot/grub/i386-pc/boot.img
}

Here we tell grub to look for a filesystem with uuid a07ca860-1d9a-4d9f-a1f9-43c64ba9844e and set the root variable with the disk/partition found. This will look something like (hd5,1). Then, with root set, we chainloader into the grub install on that partition.3

Oh, and we also play a little tune while we’re there to annoy anyone in the vicinity of the server.

chainloader vs configfile

An alternate way of achieving this that I saw around the web while getting this working was using configfile instead of chainloader - which would re-run the GRUB installed on the flash drive with the target OS’s grub.cfg. This works too, but I liked it less given it relies on the grub we installed on the flash drive and the grub.cfg generated by the OS being compatible. chainloadering boots with the OS’s grub, which is closer to as it would work if we were able to boot the disk directly.


  1. Which is what you want to just allow the OS to see the disks for use with software RAID such as ZFS ↩︎

  2. Didn’t try it tho ↩︎

  3. As far as I can tell, boot.img is copied into the MBR at install time so is exactly the same as booting the MBR directly. ↩︎