dslreports logo
 
    All Forums Hot Topics Gallery
spc
uniqs
26

EUS
Kill cancer
Premium Member
join:2002-09-10
canada

EUS to Rexter

Premium Member

to Rexter

Re: MBR vs /boot

Another reason for /boot partition; RAID. I was taught long ago that /boot never, ever, ever, never goes into a RAID setup, always create a separate partition.

Brano
I hate Vogons
MVM
join:2002-06-25
Burlington, ON
(Software) OPNsense
Ubiquiti UniFi UAP-AC-PRO
Ubiquiti NanoBeam M5 16

Brano

MVM

said by EUS:

Another reason for /boot partition; RAID. I was taught long ago that /boot never, ever, ever, never goes into a RAID setup, always create a separate partition.

That was once true, not anymore today.

koitsu
MVM
join:2002-07-16
Mountain View, CA
Humax BGW320-500

koitsu

MVM

said by Brano:

said by EUS:

Another reason for /boot partition; RAID. I was taught long ago that /boot never, ever, ever, never goes into a RAID setup, always create a separate partition.

That was once true, not anymore today.

Mm... I'll bite on this one. It's still "sort of" true, but I'm referring to "a boot partition" in a general sense, not something that's Linux-specific. "What are you rambling about now old man koitsu?!"

With FreeBSD, there's still a lot of limitations on what the bootstraps can handle. There are people using ZFS for their root filesystem, and others with classic UFS. Then there's gmirror(8) and gstripe(8) and graid3(8) setups and their metadata. And gvinum(8) too (more like an LVM, but using GEOM like gmirror/gstripe). Then you've got to deal with GPT support, as well as MBR support. With ZFS the situation becomes even hairier because you have to be able to support a multitude of models: stripes, mirrors, raidzX, and ZFS configurations that involve multiple vdevs (in fact there are commits that came in a week or two ago to deal with the multiple vdev situation, and the fixes were slightly broken so even more analysis is being done).

And I'm also choosing not to involve or talk about things like geli(8) (GEOM encryption) -- I have no idea if the bootstraps can work with that.

You've also got to decide whether or not you want serial console support and at what bootstrap stage. Do you want it early on (i.e. stage 0 bootstrap), or do you want it later on (2nd stage)? The answer for everyone is "it depends", and there are also compatibility problems with this on some motherboards too.

Purely about the bootstraps themselves, if you wanna take a look at the mess sometime, here we have it:

-r--r--r--    1 root      wheel       8192 Oct 25 01:26 /boot/boot
-r--r--r--    1 root      wheel        512 Oct 25 01:26 /boot/boot0
-r--r--r--    1 root      wheel        512 Oct 25 01:26 /boot/boot0sio
-r--r--r--    1 root      wheel        512 Oct 25 01:26 /boot/boot1
-r--r--r--    1 root      wheel       7680 Oct 25 01:26 /boot/boot2
-r--r--r--    1 root      wheel       1185 Oct 25 01:26 /boot/cdboot
-r--r--r--    1 root      wheel      15443 Oct 25 01:26 /boot/gptboot
-r--r--r--    1 root      wheel      40467 Oct 25 01:26 /boot/gptzfsboot
-r-xr-xr-x    1 root      wheel     241664 Oct 25 01:26 /boot/loader
-r--r--r--    1 root      wheel     243712 Oct 25 01:26 /boot/pxeboot
-r--r--r--    1 root      wheel     253546 Oct 25 01:26 /boot/userboot.so
-r--r--r--    1 root      wheel      66048 Oct 25 01:26 /boot/zfsboot
-r-xr-xr-x    1 root      wheel     274432 Oct 25 01:26 /boot/zfsloader
 

And to fully understand this mess, you'll also need to read gpart(8), particularly the BOOTSTRAPPING and EXAMPLES sections.

With RAID it's only "easier" if you're using something like BIOS-level or hardware RAID, especially if it's RAID-1, because the card or option ROM takes care of some (not all) of the complexities. But it gets complex once the bootstraps (depending on what they do) take over from the option ROM (but still before the kernel loads, i.e. there's no controller driver installed yet). RAID-0 and RAID-5 make booting a pain in the butt since the data is split across multiple devices.

Anyway, my point here is, saying "that's not true any more" is not quite accurate depending on what you're using. GRUB might have better support for some of this stuff, but I'm more inclined to believe it can deal with things like Linux md/mdadm setups and maybe simple UFS, but definitely not the gigantic mess we've made in FreeBSD (see above -- I don't mean the bootstraps, I mean all the insane GEOM messes and similar bits).

Bottom line: it's still a nightmare, so if you keep your bootstraps on a single partition and keep that as bare-bones simple (i.e. non-RAID, whatever), you can guarantee things will boot. However, in the case of a disk failure, you're going to have to manually do some work. That's the one thing hardware or BIOS-level RAID has going for it with RAID-1 -- it sits in front of all the mess, so if you lose a disk you can still boot.