HawaiianPi wrote: ↑
Fri May 22, 2020 4:01 am
It will boot from the drive with the bootable OS on it. Not sure why you think this is a problem (it isn't).
I almost always have more that one drive on my computers, including the USB booted Pi 4B2 I'm replying from now. The Pi won't try to boot from a drive that is not bootable (a data drive). You can have multiple drives on the system and it will find the one with bootable OS.
Give me a technical
definition of bootable
For a traditional PC BIOS the definition is simple, the last two bytes of the first sector ends are 0xAA then 0x55. This is the same for floppy disks and hard disks. Early motherboards would only boot from the first floppy or first hard disk. Post-1995 machines started adding the ability to boot from second hard disk or CD-ROM, but the original was strictly the first floppy or hard disk.
For the Raspberry PI 4, until timg236
mentioned it above I had thought
the definition was the first sector was a MBR and the first entry had a type byte indicating FAT16. Yet now apparently some
GPTs are valid.
Will the RP4 only boot from the very first
GPT entry? Does it look at the type UUID? Does it look at the id UUID? Is the presence/absence of "start.elf" what determines whether something is bootable?
Is the presence of the file "start.elf" the key definition? If multiple things which appear valid FAT filesystems are found, does it only
examine the first one?
would like it to prefer GPTs over MBRs. Ideally I
would prefer it to search all devices for GPTs and prefer: An entry whose Id UUID matches the ethernet MAC address of the Pi, then an entry whose type-UUID is one allocated for the RPF.
What I mean by Id UUID matches the ethernet MAC address is this: Try installing the "uuid-runtime" package. Now run `uuidgen -t`, given the UUID generated try `uuid -d <UUID>`. Notice that it gives you back the MAC address, if this matches the device this is a strong hint you've got the right entry (could also use 802.11 MAC, but I think ethernet MACs are preferred).
Potentially this allows you to have a USB keyfob which boots differently for several PIs. This is also a failsafe to ensure it chooses the right
device to boot from.
W. H. Heydt wrote: ↑
Fri May 22, 2020 4:03 am
The boot code has to find a FAT partition that contains the file(s) it's looking for. It will keep looking until it finds one. Note that the search order among device types is (a) documented, and (b) settable. Right now there is a choice among SD card, network, and USB devices.
If you are planning to use USB booting, the simplest thing to do is make sure that you have only one bootable USB device attached when the system boots.
As for anything else you think should be documented and is...this *is* a beta
test of the feature.
That only allows effecting the device type
to prefer, not the exact device if multiple are present. Only one bootable USB device is good, but may not be possible. If there are multiple, what are the rules for which one is preferred? USB3 ports over USB2 ports? Upper USB ports? Lower USB ports?
(guess I'm playing the role of figuring out ways I could
I cause things to fail)