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.