Booting non-bootable SATA ports on the HP Microserver Gen8
It’s a shim to the left and a boot to the right
- posted:
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.
|
|
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.
|
|
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:
|
|
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. chainloader
ing boots with the OS’s grub, which is closer to as it would work if we were able to boot the disk directly.