boot from 4th disk with GPT

[PMc]

It was repeatedly mentioned here that the old-style partitioning scheme with MBR and "freebsd" partitions (containg disklabels) should not be used anymore.
Furthermore I found that neither MBR nor disklabels can handle disks > 2TB, so GPT must be used. Then, the manpage gpart(8) says, "freebsd" disklabel partitions are legacy and "should not be used" with GPT.

I have nine disks installed and need to boot from the 4th. This works with boot0cfg(8); the BIOS does always boot the first disk, and I cannot influence the sequence in which it detects the disk controllers.

I'm now trying to figure out how this is correctly to be done with GPT. it seems, with GPT one should install the /boot/pmbr bootcode, which then occupies the place that boot0cfg(8) would use. From the manpages I cannot see how that /boot/pmbr would be able to step thru my disks.

Then, when reading this message, the bottomline seems to be: that whole GPT thing doesn't work at all - GPT does not support multiple bootable disks.

My conclusion for now is: boot from SSD (which is usually < 2TB) with MBR, and put boot0cfg onto the GPT disks, so while not booted they can at least be stepped over.

Are there better solutions?

 

[k.jacker]

If all your drives are connected native to the motherboard with no add-on controller involved, I'd double check your BIOS's boot options. They are often split up in two parts, like first choice between, SATA, USB, network, then another one for the order of the connected drives for SATA or USB. That's not always quite obvious as I've then many BIOS where the first setting was on top of the "Boot" page, the latter somewhere in the middle or at the bottom of the page.

If UEFI is supported and CSM (legacy booting) can be disabled in the BIOS, then disableing CSM and putting UEFI bootcode on your 4th drive would leave you with drive 4 as your only boot device in the BIOS (though on many consumer board that may not work as they silently prefer booting in legacy mode even if this is against the UEFI specification).

So the main questions are:

• could you double check the possibilities for the boot order in the BIOS?
• is a add-on controller involved and is the 4th drive connected to it?
• is UEFI booting supported?
  
  

 

[PMc]

If all your drives are connected native to the motherboard with no add-on controller involved, I'd double check your BIOS's boot options.

Haha, no way. It's all extra controllers.

What I have found interim: in the loader there is a "chain" option. So it seems, one would have to go thru the boot process until the loader runs, and only then one could somehow switch to another drive. That's certainly helpful for manual maintenance, but not really suitable for regular boot.

If UEFI is supported and CSM (legacy booting) can be disabled in the BIOS, then disableing CSM and putting UEFI bootcode on your 4th drive would leave you with drive 4 as your only boot device in the BIOS

No UEFI on that machine. And that would not help anyway, because 1st and 2nd drive are supposed to be identical to the 4th - they are for emergencies, when something is broken.

 

[PMc]

There is a lot more fun to have with that GPT stuff.

Instead of the 8kB boot1 loader it uses some 65kB gptboot loader. I don't know what is in these 65 kB (but I do know the size of the Apollo guidance computer - that was 24 kB first and later expanded to 64kB, and that thing did something useful), there is no dialog, no options, no nothing.

And it gets even better. Lets say, something accidentally (or intentionally) overwrites the sector 0 MBR. (It's not used anymore, so it shouldn't be critical anyway.) But it happens to be the case that gpart writes some pseudo slice into that MBR when initially creating the GPT scheme, and there is no means provided to get that back. Yes, you can reinstall that /boot/pmbr. But that doesn't help - it's not possible to boot from the disk anymore. In order to boot from the GPT, you need that MBR slice - and you cannot create it, because gpart considers the disk as GPT and will only offer to add GPT partitions.

You can as a workaround create that slice with fdisk. It must have exactly the type "EFI GPT" (238). Otherwise it doesn't boot. Afterwards you need to reinstall /boot/pmbr, as fdisk tends to overwrite that with it's own conceptions (even if not asked to).

So that works for GPT boot. If you happen to have an UEFI boot on the disk, things are a lot worse. That disk will no longer be detected as UEFI bootable by the BIOS. Because, in order for that to work, that bogus slice in the bogus MBR must have exactly the bogus data which gpart wrote into it initially - bytewise. For no technical reason whatosever. And fdisk cannot create that.
So, dump the GPT partition data, destroy it, create it again and re-enter the data.

I don't know who designed that stuff and what they had in mind (if anything), but it appears to me that this is an attempt to design things without any option to configure, to make them useable for the complete morons who are too stupid to configure anything, anyway. Such an attempt can only go evil. And, furthermore, in order to work with things that are designed for complete morons, one has to become a complete moron. Is that what we aim for?

 

[k.jacker]

I don't see GPT as the probleml.

Honestly, if there where any morons involved anywhere, then it where the creators of your controllers, leaving out the possibility to chose which drive to boot from.

What usually helps me in such situations, is to accept for myself, that I spend money on crappy hardware and then I simple replace it with something else .
Accepting the loss of some money is better then getting (even more) grey hair over a thing.

 

[PMc]

I don't see GPT as the probleml.

Honestly, if there where any morons involved anywhere, then it where the creators of your controllers, leaving out the possibility to chose which drive to boot from.

It is not the responsibility of a controller to decide on booting. It is also not the responsibility of the BIOS.

The responsibility of these parts is only to know what is attached to them, and to hand data through untampered (given some security reports, it is doubtfull if they even achieve on these tasks).

What usually helps me in such situations, is to accept for myself, that I spend money on crappy hardware and then I simple replace it with something else .

I didn't spend money. Most of my controllers come from written off industry workstations (e.g SunOS and such).

Simple rule is: if the unix core can talk to the controller chip, the thing works. BIOS intelligence and all that stuff is just superfluous. What will be next? Probably we get a digital rights management in the BIOS that makes certain that we only insert parts which the manufacturer has decided we are allowed to attach? (I checked about this UEFI stuff, and that devil's workshop where this stuff comes from makes it indeed probable to think in such directions.)

 

[Phishfry]

Did you miss efibootmgr(8) in your reading?
It should do exactly what you want.

 

[tingo]

I wish that efibootmgr(8) could allow us to choose which disk or partition to boot from. Unfortunately (unless I have missed something), that is not the case. It only allows to you to select a "Boot Manager". If you read UEFI(8), it is written quite clearly

boot1.efi searches partitions of type freebsd-ufs and freebsd-zfs for loader.efi. The search begins with partitions
on the device from which boot1.efi was loaded, and continues with other available partitions.
...
boot1.efi then loads and executes loader.efi.

then

loader.efi loads and boots the kernel, as described in loader(8).

Implied; boot1.efi and loader.efi takes the first possible partition to boot from, and there is no way to configure a different partition.
If you check the man page of loader, you will find out that there isn't a way to configure a different disk to boot from either.

When we used gptboot(8), it had the capability (via bootme / bootonce attributes) to select which partition to boot. Combined with the firmware (BIOS / UEFI) boot menu (often F12 key) which allowed selecting which disk to boot from it was easy to manage different drives and partitions to boot from. Alas, with (u)efi boot loader the freebsd-boot partition (and thus gptboot) has become obsolete.

Note: it is possible to manually select a different drive to boot from, if you escape to the boot loader when the boot menu shows and do

unload
set currdev=disk1p5 (or whatever partition you want)
boot-conf

but this is cumbersome as it must be done on every boot; I haven't found a way to configure this from within FreeBSD.