MBR

[Synon]

Hi. I was just thinking about the MBR. The MBR is the first 512 bytes of the active hard/floppy disk or USB, right? And a boot sector program has to be 512 bytes long, yes? Then where does the partition table go? I thought it was organised like this
+---------+---------------+
| 000-440 | Bootloader |
+---------+---------------+
| 440-444 | Disk signature |
+---------+---------------+
| 444-446 | NULLs |
+---------+---------------+
+ 446-510 | Partition table |
+---------+---------------+
| 510-511 | 0x55 |
+---------+---------------+
| 511-512 | 0xaa |
+---------+---------------+

If so, then why is GRUB stage1 a 512-byte file and not 440 bytes instead? This question isn't address in the article about the MBR so I was thinking the answer could be added to it.

[Love4Boobies]

It's the installer's job to write the MBR to LBA 0 without replacing the partition table. You can do it any way you like. There are a couple of reasons why you might want to write a 512-byte file. It makes testing easier since you can just use the assembled MBR. Then, you get all the offsets in the right place. I'm not sure we should write stuff about GRUB in an article that's not related to GRUB.

[Synon]

It's the installer's job to write the MBR to LBA 0 without replacing the partition table. You can do it any way you like.

Huh. So I need to figure out how to get the partition table inside the file? I could capture the sector into a file, take the 446+64 byte chunk out, and put it into the bootloader binary file...

There are a couple of reasons why you might want to write a 512-byte file. It makes testing easier since you can just use the assembled MBR. Then, you get all the offsets in the right place.

OK.

I'm not sure we should write stuff about GRUB in an article that's not related to GRUB.

I wasn't proposing we should; what I was saying is that the GRUB stage1 file is 512-bytes, but the code part of the bootsector is 440 bytes.

[Love4Boobies]

It's the installer's job to write the MBR to LBA 0 without replacing the partition table. You can do it any way you like.

Huh. So I need to figure out how to get the partition table inside the file? I could capture the sector into a file, take the 446+64 byte chunk out, and put it into the bootloader binary file...

Heh, no. You (meaning the installer) just don't write over that part (or read it and write the same thing over it if you're writing a whole sector).

[Synon]

Heh, no. You (meaning the installer) just don't write over that part (or read it and write the same thing over it if you're writing a whole sector).

Good point, that's easier.

[bewing]

And just for the sake of clarity -- MBRs are only installed on partitioned disks. This does NOT include floppies, etc.

[Synon]

And just for the sake of clarity -- MBRs are only installed on partitioned disks. This does NOT include floppies, etc.

On other disks and on partitions themselves it's called a VBR right? And the difference would be the lack of a partition table... so I don't have to give a damn about the part table on a VBR. So I should try to detect if the disk is an mbr or vbr, then.

[bewing]

The program that formats the media knows whether the media is partitioned or not. It writes an MBR if an MBR is appropriate. You do not have to detect anything. You simply need to have an MBR available for media that need one. The MBR chainloads the first sector (or if you are being smart about it, up to the first 36 sectors) of the partition marked as "bootable" (or if you are being really nice, of the partition that the user selects -- called "dual booting"). You can call that bootsector a VBR if you like. Most of us just call them bootsectors, or bootloaders.

[Synon]

The program that formats the media knows whether the media is partitioned or not. It writes an MBR if an MBR is appropriate. You do not have to detect anything. You simply need to have an MBR available for media that need one. The MBR chainloads the first sector (or if you are being smart about it, up to the first 36 sectors) of the partition marked as "bootable" (or if you are being really nice, of the partition that the user selects -- called "dual booting"). You can call that bootsector a VBR if you like. Most of us just call them bootsectors, or bootloaders.

Well my plan is just to write a bootloader for now, mostly to play with code without having to deal with memory management, sheduling, etc. and the other harder things that come with writing an operating system. Eventually I'll want to write an installer, though; so the installer will have to check if the disk is partitioned or not, and then write an MBR or VBR.

Anyway I plan to have a stage1 file in the first sector of the volume, and a stage2 in the next 30k of the disk (that's where GRUB search for their stage2, they probably have their reasons for only looking there... do you know why?). The stage1 just finds, loads and executes the stage2, which shows a boot menu, gathers multiboot information and then runs the kernel specified on the boot menu... I won't go as far as GRUB, and have support for any filesystems; I'll just use something like "(hdn,n):sectorn+n," e.g. "(hd0,1):0+64" to keep things simple.

Why would you check up to the first 36 sectors of each partition?

[Love4Boobies]

You can call that bootsector a VBR if you like. Most of us just call them bootsectors, or bootloaders.

A VBR is just a sector, a boot loader can have several sectors and the MBR can be one of them so I wouldn't call it that. The VBR is a boot sector, however.

Eventually I'll want to write an installer, though; so the installer will have to check if the disk is partitioned or not, and then write an MBR or VBR.

There's no check to be performed. For instance, hard disks will always have a MBR (even if they have one partition defined) and one VBR for each bootable partition (the definition here is quite vague; Microsoft says there can only be one bootable primary partition but if you use something like dual booting, that bewing has mentioned, you might have others as well), whereas floppy disks will only have a VBR. I would argue against dual booting since that would just be bugging the user with another thing. Instead, a hard disk should have only 1 bootable partition which should load a boot loader that offers whatever functionality one needs.

[Synon]

There's no check to be performed. For instance, hard disks will always have a MBR (even if they have one partition defined) and one VBR for each bootable partition (the definition here is quite vague; Microsoft says there can only be one bootable primary partition but if you use something like dual booting, that bewing has mentioned, you might have others as well), whereas floppy disks will only have a VBR.

But how does the installer know whether or not to write bytes 446-510? I don't want to destroy the partition table by accident...

I would argue against dual booting since that would just be bugging the user with another thing. Instead, a hard disk should have only 1 bootable partition which should load a boot loader that offers whatever functionality one needs.

You mean, you don't think there should be more than one active partition; or you don't think you should do what virtually all common bootloaders do, and allow booting from any of four partitions?

[Love4Boobies]

When using the MBR partitioning scheme, there should only be a maximum of one active (primary) partitions. The should load the VBR which would then load the boot loader that enables booting from any partition. Zero active partitions in a MBR indicates that the hard disk is not bootable.

[bewing]

> (It) should load the VBR which would then load the boot loader that (would then load the kernel)

I do not like Love4Boobies' technique, because it takes 3 steps to do what you should be able to do in one, theoretically. So it is unnecessarily complex.

> Why would you check up to the first 36 sectors of each partition?

Not "check" -- load. In the BIOS is there any reason to ever load just one sector? No there is not. From a hard disk, with one command, you can always load at least 63 sectors. It adds no complexity to the code at all. From a 1.44 or 1.2M floppy drive, you can always load 36 sectors with one command. So, anyone with any sense who writes a BIOS or MBR should always load 36 sectors of each partition. It simplifies the design of the bootloader if the bootloader can always be up to 18k in size. If an entire kernel is less than 18k (not hard to do), then you don't even need a bootloader -- just put the kernel on the first 36 sectors of its partition, and the BIOS or MBR will load and run it.

So the point is that loading just one sector is stupid, and loading 36 sectors can simplify the design of the code that follows.

[Brendan]

Hi,

When using the MBR partitioning scheme, there should only be a maximum of one active (primary) partitions. The should load the VBR which would then load the boot loader that enables booting from any partition. Zero active partitions in a MBR indicates that the hard disk is not bootable.

Don't forget the "extended partition" scheme, where there's "primary partitions" (listed in the partition table on the first sector of the disk) and "secondary partitions" (listed in a partition table in the first sector/VBR of a primary partition). Also, in theory an OS could support booting from secondary partitions...

> (It) should load the VBR which would then load the boot loader that (would then load the kernel)

I do not like Love4Boobies' technique, because it takes 3 steps to do what you should be able to do in one, theoretically. So it is unnecessarily complex.

That's technique may have been Microsoft's technique before it became a "de facto" standard for PCs. I don't think it's fair to blame Love4Boobies...

> Why would you check up to the first 36 sectors of each partition?

Not "check" -- load. In the BIOS is there any reason to ever load just one sector? No there is not. From a hard disk, with one command, you can always load at least 63 sectors.

For very old hard drives, and for "USB emulating hard disk" (with some new USB flash devices); you can't assume that there's 63 sectors per track.

If an entire kernel is less than 18k (not hard to do), then you don't even need a bootloader -- just put the kernel on the first 36 sectors of its partition, and the BIOS or MBR will load and run it.

You also can't assume that the MBR is your MBR. Even if your code installs your MBR when it installs the rest of the OS, it's easy for the end-user to replace it (with Microsoft's MBR, or GRUB, or any other third-party MBR) at any time after your OS is installed. You can't assume that the MBR loaded more than one sector of your partition.

Note: For older boot managers, it was common to have a different virtual partition table for each OS, so that the boot manager could pretend that the OS's partition is the only one marked as "active", and could hide partitions that belong to other OS's (and support more than 4 primary partitions), etc.


Cheers,

Brendan

[Owen]

I wish Grub would learn to install itself in the partition boot sector, rather than the MBR. Why? Because then it would take me 1/10th the time to fix people's computers when they install Windows (or insert_other_os_here) after it and and overwrite it's MBR. If everything standardized on "load the boot sector of the active partition", I could just mark their /boot partition as active again (and then edit their menu.lst to add whatever new OS they've installed to the list), rather than everything's boot sector trashing everything else's