TIP: booting from USB RAID1 using UEFI boot manager

kbs1

Hello,

I've spent a good amount of time trying to figure this one out. I have a setup where I don't use the builtin emmc drive, but boot from usb raid1 (linux, mdadm). This is my root partition. Now when I freshly installed Ubuntu 16.04 LTS, it booted fine, every reboot, all fine, perfect.

But then I removed my usb thumb drive used to install it. Suddenly, no boot. All boot options were lost. I thought the battery was dead. It wasn't. The board simply forgot all my boot options, or at least it seemed like that.

Then I booted from usb stick again, recovery mode, ran efibootmgr a coupe of times, added both disks (each of raid1 disk contains the same ESP), every reboot cool, works, removed the drive, works, fine. Power off, then on - no go.

I then found out a trick, that sometimes (maybe 1/10) the system simply booted. I fiddled with countless admin uefi bios settings, nothing. Then I figured out it probably has to do with usb <-> sata adapters initialising slowly, and maybe the board just doesn't display boot options that are currently not present (makes sense).

Then I found out the board ALWAYS booted using the following shortcuts:
- press F7 rapidly during bootup, for ~30 seconds. Then press down arrow ~5 times. Then press ESC.
This will only display the boot select menu, which would have only one item most of the time (enter setup), down arrow does nothing, and in any case, pressing esc will "resume default boot process". I had to do it this way because I'm running headless. And this required the keyboard to be attached, and me physically present each reboot.

The "ESC" on this prompt always caused the board to re-enumerate USB drives, and it would then immediately boot off them.

Now I couldn't find any "delay" settings in the uefi bios. Luckily I found that efibootmgr -v printed out "Timeout: 1 second." What was that?:) Reading the manual it's "boot loader timeout". What is that exactly, again? But sounds promising. I tried it. IT WORKS! )

SO, to boot off ANY slowly initializing USB devices, execute the following in linux:
efibootmgr -t 15

That does the trick and now the board boots 100% of the time from cold power off with no user intervention, exactly as it should be! ;-)

Now I did some final tweaks so that the efi boot menu could be COMPLETELY empty.
root@unison-up:~# efibootmgr -v
Timeout: 15 seconds
No BootOrder is set; firmware will attempt recovery
root@unison-up:~#

- perfect. To acieve this, I created the following file structure on ESP:
root@unison-up:~# find /boot/efi
/boot/efi
/boot/efi/EFI
/boot/efi/EFI/ubuntu
/boot/efi/EFI/ubuntu/shimx64.efi
/boot/efi/EFI/ubuntu/grubx64.efi
/boot/efi/EFI/ubuntu/MokManager.efi
/boot/efi/EFI/ubuntu/grub.cfg
/boot/efi/EFI/BOOT
/boot/efi/EFI/BOOT/MokManager.efi
/boot/efi/EFI/BOOT/grub.cfg
/boot/efi/EFI/BOOT/grubx64.efi
/boot/efi/EFI/BOOT/BOOTx64.EFI
/boot/efi/EFI/Shell.efi
root@unison-up:~#
root@unison-up:~# find /boot/efi2
/boot/efi2
/boot/efi2/EFI
/boot/efi2/EFI/ubuntu
/boot/efi2/EFI/ubuntu/shimx64.efi
/boot/efi2/EFI/ubuntu/grubx64.efi
/boot/efi2/EFI/ubuntu/MokManager.efi
/boot/efi2/EFI/ubuntu/grub.cfg
/boot/efi2/EFI/Shell.efi
/boot/efi2/EFI/BOOT
/boot/efi2/EFI/BOOT/MokManager.efi
/boot/efi2/EFI/BOOT/grub.cfg
/boot/efi2/EFI/BOOT/grubx64.efi
/boot/efi2/EFI/BOOT/BOOTx64.EFI
root@unison-up:~#

As you can see I just copied "ubuntu" folder to "BOOT" folder, and renamed "shimx64.efi" to "BOOTx64.EFI, which is the default filename and path the x64 firmware looks for, when no boot options are defined.

So, it's clear now ;-) "efi2" is just a copy of ESP on the second drive. Nothing more should be done even after a kernel upgrade, as shim loads grub and grub only reads the /boot/grub/grub.cfg file, which is not on ESP anymore, then loads the kernel etc. It's /boot/grub/grub.cfg that is updated during kernel update, and not the ESP.

It also does not matter if os type in uefi bios is set to android or windows, I have it on android atm, seems to make no difference for ubuntu. Secure boot should be off in uefi admin settings, just to be safe, althrough shimx64.efi should be signed by microsoft.

I hope someone will find this useful. Cheers

Ken

Hmmm, not sure what you mean by USB RAID1, what are you using for this? I am curious because I am adding a USB SSD to mine using an Ableconn USB -> M.2 carrier board intended for the Raspberry Pi. My intention is to move all the write heavy partitions over to a 120GB Samsung EVO SSD I have there, like /var and /home. The Ableconn board is only USB2.0, but also has a pin header on it, so I am just wiring it up to the "extra" USB2.0x2-UART header and the carrier board is Pi shaped (with a cutout around the 4 pin header) so it can just be squeezed into a HAT stack between boards and makes a pretty compact little package. Reality is that I could probably even squeeze a 2nd one into the stack without changing anything but standoffs and a slightly taller GPIO extender (and another "internal cable" ) to get a mirror, just not sure it's really worth it though and I have plans already for the 2nd USB port off the "internal" connector (5Ghz WiFi N). The Ableconn board only takes about 4 or 5mm of height to squeeze in if you lay the USB and jumper headers down. I am using ZFS on the SSD and would love to just have the whole system ZFS, we'll see converting root to ZFS seems like it might be a fair amount of effort although your post here seems like it might give me some insight into how to accomplish that. In my case I'd still put root on the EMMC, since it'd basically be essentially read-only and I am not sure an SSD, even a decent SSD, would offer much performance or fault tolerance advantage on root and boot only when the SSD is connected through USB2.0 which is the limit of the Ableconn conversion, but this is just an assumption since I have no idea what the performance characteristics of the EMMC really are, as there is no specs on what is being used at all.

Also I am using the UbiLinux distro, so I've not seen any real way so far to better control the installation to install anywhere other than the EMMC, even if an alternative is available. I suppose using Ubuntu, which is just a straight x64 distro would allow me to do that, but then drifts into the issue of not having a lot of the drivers there, specific to the UP Board, working out of the box. In my setup I am using SPI (for a 3.5 TFT display HAT) and will be using the I/O header for a PiFace relay board HAT, though I haven't gotten that far into that yet.

So, back to what you are doing, what is your USB RAID? SSD? or are you using spinning drives? I see mention of SATA in your post, are you using some kind of in-stack SATA conversion or are you just using external USB drives?

kbs1

Hi there,

USB 2.0 will be very slow, tops out at around 30MB/s theoretical, in practice around 25MB/s, so your ssd won't be used much. EMMC is faster than USB 2.0 in most cases but I haven't done any measurements on the Up.

I'm using 2 hdds to provide redundancy (raid1). This is a file storage system at my company, plus backups on another machine. The machine works to this day. The whole FS is on raid1 and I would recommend that, internal emmc is not used at all.

Ubi does not allow you to install to raid easily, I used ubuntu server 16.04 lts. Drivers might be an issue, but for me, I don't need any, but I understand your issue here.

> SSD? or are you using spinning drives? I see mention of SATA in your post, are you using some kind of in-stack SATA conversion or are you just using external USB drives?
- just simple ebay usb to sata coverters, external usb dribe would be the same thing. I just modded a miniITX case so it sits together nicely as one small file server package, supply is dc-dc 120W external brick.

Have you gotten yours to work?
Viliam ;-)