Partition Boot Record bootstrap code
Partition Boot Record bootstrap code
I've read in many sources that Partition Boot Record/Record is written upon formatting a disk partition and contains machine code for bootstrapping specific OS. My question is how a formatting tool like DOS format command can write specific OS bootstrap while it only formats not installs specific OS?
Re: Partition Boot Record bootstrap code
MBR only contains code to locate a bootable partition and load a bootsector from it. Your specific OS bootloader is located in that partition and does the rest of the job.
Learn to read.
Re: Partition Boot Record bootstrap code
So what happens when grub is installed in the MBR? It has no problem loading an OS kernel located in one of the partitions.
To answer the OP - the DOS format command has the ability to copy the boot code and files for DOS as well as just formatting the disk. But it can't make another OS bootable.
To answer the OP - the DOS format command has the ability to copy the boot code and files for DOS as well as just formatting the disk. But it can't make another OS bootable.
Re: Partition Boot Record bootstrap code
The "FORMAT /S" MS-DOS command you're talking about doesn't write to the MBR. It writes to the partition's boot record and installs the absolute minimal files that MS-DOS needs to run (IO.SYS, MSDOS.SYS and COMMAND.COM). It does install a minimal version of "the specific OS".
To write the MBR for booting DOS, you'd use "FDISK /MBR" (or just create the partition table in FDISK on a completely blank disk). You can also install the minimal files without formatting using the "SYS" command.
When MS-DOS boots (from a hard drive), the MBR code checks the partition table for a bootable partition. It then transfers control to that partition's boot record, which then loads the aforementioned files. Both of these are about as primitive as it's possible to be; it's even required that IO.SYS be the first file on the partition and not be fragmented. MS-DOS's MBR can (and fairly commonly was, back when DOS was still relevant) be used to boot OSs other than MS-DOS; it's too primitive to care what it's actually loading, as long as it comes from the boot record of a "bootable" partition.
GRUB is a much more advanced bootloader. It's able to read the partition table, understand the filesystem within, load configuration, display a menu and load multiple different kinds of kernel (all this depends on the modules it's been configured with). As a result, it's much larger than the DOS MBR, but thankfully on modern(ish) systems there's (usually) a nearly 1MB "gap" between the MBR/partition table and the first actual partition and this is where GRUB puts most of its code. GRUB's MBR just transfers control to the code in the "gap".
To write the MBR for booting DOS, you'd use "FDISK /MBR" (or just create the partition table in FDISK on a completely blank disk). You can also install the minimal files without formatting using the "SYS" command.
When MS-DOS boots (from a hard drive), the MBR code checks the partition table for a bootable partition. It then transfers control to that partition's boot record, which then loads the aforementioned files. Both of these are about as primitive as it's possible to be; it's even required that IO.SYS be the first file on the partition and not be fragmented. MS-DOS's MBR can (and fairly commonly was, back when DOS was still relevant) be used to boot OSs other than MS-DOS; it's too primitive to care what it's actually loading, as long as it comes from the boot record of a "bootable" partition.
GRUB is a much more advanced bootloader. It's able to read the partition table, understand the filesystem within, load configuration, display a menu and load multiple different kinds of kernel (all this depends on the modules it's been configured with). As a result, it's much larger than the DOS MBR, but thankfully on modern(ish) systems there's (usually) a nearly 1MB "gap" between the MBR/partition table and the first actual partition and this is where GRUB puts most of its code. GRUB's MBR just transfers control to the code in the "gap".
