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 
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ā¦ 
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ā¦ 
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ā
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ā¦
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.