dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
701

Rexter
Libertas, Aequitas, Veritas
join:2002-11-17
cloud 9

Rexter

Member

MBR vs /boot

I don't understand the relationship between Grub the MBR, and /boot partition. Why would you create /boot, when grub can just be installed in the MBR? If I do have a boot partition, during the ubuntu install "Device for boot loader installation:" should I choose the device, or the boot 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

Grub is too big to fit into MBR, only small portion goes there. The rest is in /boot (can me separate partition or directory under /)

More »en.wikipedia.org/wiki/GNU_GRUB

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

1 recommendation

koitsu to Rexter

MVM

to Rexter
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?

Snakeoil
Ignore Button. The coward's feature.
Premium Member
join:2000-08-05
united state

Snakeoil

Premium Member

Interesting.
Assembly language... I remember having to use that for a final project in college.

Rexter
Libertas, Aequitas, Veritas
join:2002-11-17
cloud 9

Rexter to koitsu

Member

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?

DeHackEd
Bill Ate Tux's Rocket
join:2000-12-07

DeHackEd

Member

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.

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

EUS to Rexter

Premium Member

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.
dave
Premium Member
join:2000-05-04
not in ohio

1 edit

dave to koitsu

Premium Member

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
MVM
join:2002-06-25
Burlington, ON
(Software) OPNsense
Ubiquiti UniFi UAP-AC-PRO
Ubiquiti NanoBeam M5 16

Brano to EUS

MVM

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.

nwrickert
Mod
join:2004-09-04
Geneva, IL

nwrickert to Rexter

Mod

to Rexter
said by Rexter:

Why would you create /boot, when grub can just be installed in the MBR?

One reason for me, is that I install linux in an encrypted LVM. So "/boot" is not encrypted, but everything else is. The code to manage the crypto goes in the unencrypted "/boot" (as part of the INITRD).

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

koitsu to Brano

MVM

to Brano
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.