dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
14
share rss forum feed


koitsu
Premium,MVM
join:2002-07-16
Mountain View, CA
kudos:23

1 recommendation

reply to Rexter

Re: MBR vs /boot

PC bootstraps are the biggest clusterf*** in the world. Bootstrapping has to happen in multiple stages because the MBR is only 512 bytes large -- no bigger. Note I said 512 bytes. Not kilobytes, not megabytes. BYTES.

So the way it works is that you have to write 512 bytes of code (it's always written in assembly due to size pressure) -- this is often called "stage 0" -- that does nothing other than read some additional sectors into memory and then run *that* code. Sometimes, if you're lucky, the stage 0 bootstrap can initialise a serial port (FreeBSD's stage 0 bootstrap can do this, but as has been recently discovered we're out of room. Someone tried to do recent changes and the code was 5 bytes too big...).

The code that gets run at this point (often called "stage 1"), if I remember right, is limited to 64KBytes (due to 16-bit x86 memory segmentation). This code sets up protected mode (32-bit x86) and some other very key/important pieces, can initialise a serial port, and possibly (depending on how tight the code is) do some other minor things. Sometimes if the code is small/tight enough it can read filesystems at a very basic level, but that's often left for the next stage -- stage 2.

Stage 2 is where most of the "heavy lifting" happens. Because protected mode is set up (or at least some form of memory management), you can now write code easier (most of it is often written in C for this stage), support for filesystems is there, menuing systems, and all sorts of other stuff. The limits here are much more relaxed.

After this point is where your kernel loads and the rest is as you know it.

I probably have some of the very specific technical details incorrect (e.g. I'm not sure if protected mode is really set up during stage 1; it might still keep the segmented 16-bit model at that point, unsure), but the overall method I'm describing is true. I know this isn't Linux, but you can read about the model in FreeBSD's man page for boot(8).

I believe GRUB is an entire package, as in it does stage 0, stage 1, and stage 2 -- but what you see (the menu, visuals, etc.) are all part of stage 2.

I believe that the /boot filesystem you're seeing might contain the stage 2 bootstraps (if stage 1 can actually read filesystems -- I don't know enough about GRUB), and probably contains some kernel bits too.

Make more sense?
--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer.


Snakeoil
Ignore Button. The coward's feature.
Premium
join:2000-08-05
Mentor, OH
kudos:1
Interesting.
Assembly language... I remember having to use that for a final project in college.


Rexter
YeeHaw

join:2002-11-17
cloud 9
reply to koitsu
Very nice explanation. It all makes a lot more sense to me now! So why would you have /boot as a separate partition? And if you did, you would still tell the install to put Gbrub in the MBR, because only stage 0 goes there, and the rest is in /boot anyway?
--
I'm with the Central Government. I'm here to help you. Now bend over, really, I'm helping you, just, just stay still. You'll feel better in a moment.


DeHackEd
Bill Ate Tux's Rocket

join:2000-12-07
Often times you have complicated filesystems (btrfs, ZFS, or ext4 on LVM, you can imagine more) holding your root filesystem. If you don't have a /boot, the root is certainly where you'd put your bootloader and kernel. To make life a hell of a lot easier for the bootloader, /boot is usually a simple primary partition formatted ext2/3/4.

Also, long ago there were BIOS limitations on accessible disk sectors, usually about the 512 MB or 8.4 GB lines. Use of a tiny /boot at the start of the disk would keep you safe.

Both of these restrictions are going away with grub2 and modern BIOS systems but a lot of installers will still default to making a /boot to be better safe than sorry.
--
That's odd...


EUS
Kill cancer
Premium
join:2002-09-10
canada
Reviews:
·voip.ms
reply to Rexter
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.
--
~ Project Hope ~

dave
Premium,MVM
join:2000-05-04
not in ohio
kudos:8
Reviews:
·Verizon FiOS

1 edit
reply to koitsu
Kids today, huh? That's how bootstraps always worked - it's why they're called 'bootstraps'. Each stage gets a little more capability, but it's quite a long way before you get to be able to support a filesystem.

You missed out the code that reads in the first 512 bytes of mass storage. Luxury computers have that in ROM of some kind, otherwise you have to enter it through console switches. Regardless, that's the first stage of bootstrap. I recall the PDP11/40 primary boot was round about a dozen 16-bit words.


Brano
I hate Vogons
Premium,MVM
join:2002-06-25
Burlington, ON
kudos:11
Reviews:
·TekSavvy DSL
·Bell Fibe
reply to EUS
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
Premium,MVM
join:2002-07-16
Mountain View, CA
kudos:23
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.
--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer.