Does a fresh MBR contain generic code?

If I low level formatted a drive, then created a partition table, and installed Linuxes with their bootloaders only on their root partitions, would the one with the bootable flag set boot?

To put it another way; does the process of creating a partition table using Linux tools put generic code in the MBR?

Sorry - no disk to test :slight_smile:

Master boot record - Wikipedia, the free encyclopedia

It states that amongst other things the MBR is holding the partition table…That should answer the question.

I had read that… Now I’ve read it again, and I’m sorry to say if it does contain the answer it’s lost on me… :frowning:

It seems to imply ‘yes’, but it’d help if someone can tell me outright. I’m sure I can get a disk up and running to test on - but I don’t have one to hand.

I’m not really interested in what is in the MBR per se, but rather whether a system partitioned from scratch will boot a system with a bootloader placed on a root/boot partition, with nothing explicitly installed to the MBR.

No, it would only contain a partition table. That’s the cause for the BOOT RECORD NOT FOUND error from the BIOS. You could verify this in a virtual machine.

Thanks.

No virtual machines either. I’ve only got my eee running at the moment, and I’m not sure it would handle that… :wink:

Next question: the SUSE bootloader installer can install generic code to the MBR, but my understanding is that this is SUSE specific. I’m reading about ms-sys as a linux tool to do it, but it doesn’t seem all that common (e.g. it’s not present on my Debian box)… Is there a more common way to do this, ideally from command line on a running system / liveCD? Or is the general reckoning to use a Win CD, or supergrubdisk or similar?

Thanks.

Well it’s not SuSE or even Linux specific, but rather, bootloader specific. GRUB has a MBR, LILO has a MBR, various boot managers have their MBR. So the details depend on what bootloader you have chosen.

Not sure that I agree but I may be totally wrong. I think that the MBR is not a result of which boot-loader one uses but it is simply a reserved address space on a fixed disk. For example, In the past I have had say a 20gig fixed disk with Linux on it and then upgraded it to a 40. Now the 20 is lying around and I need an XP box to do something. I install XP and the Installation is flawless but the XP install will not boot. (if i recall properly it simply repeats some octal code)

At this point the partition table is intact but the MBR is corrupt. If I the run ‘fdisk /mbr’ the MBR is rewritten and the system boots. The partition table is intact yet the MBR has been rewritten.

I feel like the MBR is designed to work with BIOS and not the OS or boot-loader. If it was not designed this way how could one even start any boot process, as the BIOS does not know what booting mechanism one is using. The MBR has a set pointer to another reserved address space which is the boot-loader. In this way the fixed disk can be recognized by every BIOS (BIOS that is compatible with the type of drive; SCSI, Winchester, SATA, PATA whatever era you are in) and still continue on to the OS boot no matter what loader or OS.

That said the boot-loader can modify the pointer to the actual boot device or partition. (thats why it can get broke) but you can get it back to the generic standard which points to the set booting address space and go from there.

Remember the days of DOS when you could not just copy boot.ini to a disk and have it boot-able! This is because it had to be in the reserved booting address space.

Jeremy

Hmm… I’m aware that there’s no such thing as ‘generic’ generic boot code (:)), but the term does seem to be commonly used to refer to code that simply locates whichever partition is set as bootable - I guess this is a specific version of the pointer that Jeremy refers to if I’m following (and I’m really not sure I am… :P). Grub stage1 seems to be a pointer to the rest of the bootloader at a specific point, which isn’t what I’m after.

So I’m wondering whether there’s a standard Linux tool to insert such code… I’ve just read ‘info grub’ (well, most of it… I skipped over ‘Chainloading obscure Unix variants that nobody has actually booted since 1987, section D’, and stopped at ‘hacking grub’), but I’m not getting anywhere.

OK this far in the thread. What is the real problem that u r having. What do u need help with? I don’t believe that it is knowledge of what is written to the MBR! How can we help?

“Jeremy has Spoken”

:slight_smile: I’m helping with the wiki transition. Or discovering the depths of my incompetence - really depends on how you choose to look at it.

Just trying to work out how to write generic (there’s that word again) instructions for multibooting Linuxes. Obviously, if you can write simple instructions which leave the MBR untouched, it is preferable to do so for various reasons (recovery partitions, diagnostic partitions, encrypted partitions, Windows service packs…).

It isn’t actually a problem as such, it just creates a few more ‘if - then’ clauses in the instructions, which is annoying, as that’s one of the things we’ve been (quite correctly in my opinion) directed to avoid as much as possible.

Thanks for helping anyway. I’m sure I’ll be back with more puzzles… :slight_smile:

The partition table is an area within the 512 byes that is the MBR. All bootstrap codes avoid this area. So the number of bytes available to the bootstrap is reduced to something like 400+. I forget, you can easily find it by a search.

I feel like the MBR is designed to work with BIOS and not the OS or boot-loader. If it was not designed this way how could one even start any boot process, as the BIOS does not know what booting mechanism one is using. The MBR has a set pointer to another reserved address space which is the boot-loader. In this way the fixed disk can be recognized by every BIOS (BIOS that is compatible with the type of drive; SCSI, Winchester, SATA, PATA whatever era you are in) and still continue on to the OS boot no matter what loader or OS.

The MBR bootstrap is the first code executed by the BIOS when it decides to boot that device. It’s where the BIOS gives up control to a bootstrap. So this bootstrap has to be very small and also run in real mode. But it has and needs access to BIOS calls to load further stages. Any number of different MBR bootstrap loaders can be written. GRUB provides one, LILO provides one, Windows has its own, DOS has its own.

Writing a MBR bootstrap is actually a nice assembly language exercise. There is a finite amount of space available and you know what it has to do.

You can find all this information by searching, no need to speculate.

WOW
I am out! good luck!

The Meek Jeremy

On startup the BIOS looks for a boot drive and finding the first one starts the code in the defined MBR sector. The MBR code simply points to the next step of the bootstrap process. Ok it may set a few things in prep.It is only about 256/512 bytes I think. Grub simply points to the boot process for Linux in a given partition and hands control over to it. Then menu.list controls it from then on. So in a multiboot situation you actually have one grub process located on one partitioning just handing control to the selected kernel startup code. Window is of course the exception. I don’t know how it works anymore. But Grub would just hands execution over to the Windows boot process, what ever that is. The key is that the MBR code points to the next stage of the boot. So maybe you just need a separate boot partition???

Grub does not point to anything in the initial boot! The initial boot is the MBR. The result of the pointer is the boot loader. The boot loader now points to which system to load (sometimes based on your selection). If you do not understand that the MBR system has been established sense before Linux then please just listen to the thread and stop arguing. Grub may exist in the “official” location of the MBR but this does not mean anything for a general user! Treat your boot loader as a secondary facility to select your boot device or partition. Send me an email if you need real help.

Old Man
Jeremy
P.S. It says I’m Puzzled but I am not!

This “pointing to” terminology is also wrong. The MBR code doesn’t “point” to anything. It actually loads the next bootloader stage using BIOS calls. There is nothing to be pointed to or jumped to until it has been loaded. That’s why GRUB documentation talks about stage 1.5 and stage 2. Stage 1 is the MBR.

You can read all about how GRUB works with “info grub”.

Windows MBR of course does it differently, as does LILO. As do other bootloaders. So there is no such thing as a generic MBR.

I guess when OpenSUSE setup offers that option (caution! Is is often enabled by default), it just removes any other bootloader previously installed in MBR. That’s why it also wants to activate the boot partition. In the absence of a bootloder in the MBR, the BIOS will execute the code found in the bootsector of the active partition (which could also be Grub if you install it in a partition rather then in MBR). Only one primary partition can have the active flag (0x80). If none partition is active and you don’t have a bootloader in MBR, you will end up with a message: “No system found” or something like that. If two partitions are active at the same time (partitioning tools won’t let you do that, but you could achieve that result while manually editing the MBR), it won’t boot either. Grub and other bootmanagers have an option to set the active flag of the booting partition. It is also required while chainloading DOS based operating systems and some Unix.

Something in openSUSE setup seems however illogical: why does it enable “activate boot partition” when this boot partition is a logical one. From what I know, on MBR based machines, only the parition table with its four primaries is searched for a boot flag.

The DOS and Windows MBR care about the boot flag. IIRC GRUB and LILO don’t and can boot from any partition, even if it’s not marked bootable.

Even the BIOS gets into the act too. I’ve seen one that would refuse to boot the disk if there wasn’t at least one partition flagged bootable. So to be safe, do enable the flag.

Sure it does it points to the partition where the rest of the boot process can be found. It has to know where to look for the next stage. It does not search the whole disk it goes to the a partition where that next stage is found. and yes it does use the BIOS to do it. Since the BIOS having read the MBR now knows the disk layout and the starting point of all the partitions.

Yes, this is the embedding of the block numbers, but this is imprecise terminology. If you use “pointing to”, you should explain that this is not a memory pointer thing since the next stage hasn’t been loaded yet.

Posted by :please_try_again

In the absence of a bootloder in the MBR, the BIOS will execute the code found in the bootsector of the active partition
The BIOS will read only the MBR, if no boot code then comp will not boot that hdd and will check other boot devices.