Where/how can I learn and gain *complete* control of my MBR?

Post Reply New Topic

I let Debian do some kind of update a few days ago, and one of my Windows systems in this multi-boot setup would not work after that. As odd as this might seem, it appears Debian had somehow altered my BIOS. In any case, fixing that Windows problem has knocked GRUB out of the picture for booting, so now my Debian and Win7 are out "lost in space" somewhere and I do not know how to get them (via GRUB) back into the boot menu. Debian's initial installation altered my MBR in a way that now keeps Win7 from making its own BCD work, so it looks like a manual installation of GRUB is going to be necessary here.

Any suggestions?

For now, I plan to just try running Mint9 from disc. It will run on my machine but not install, and Debian (installed) cannot access my printer.

Just today I saw a report of a bug in which windows overwrites something that grub2 depends on. I'm not sure if it's the same bug, but it sounds similar.

Here's a link that describes it.

Yes, that sounds like what has happened and that is what I want to learn about ... and I thank you!

You have to understand that there is only 1 MBR, if you let an OS write to it, whatever there before will be gone.

Actually, Windows does not put a full fledged boot loader in the MBR. It only writes a single boot sector after the MBR. That code only look into the active partition and load the boot loader there if one is found. The BCD is also stored in the boot partition not the MBR.

Linux for some reason like to write its boot loader to the MBR. Most if not all distro has an option to put it in root instead. You may want to give that option a try.

Windows updates like to overwrite the MBR and some applications on Windows can do it.

When I had Mint8 and used LiLo, I was able to put Mint's loader on Mint's partition, but Debian's installer could not get that done. Then, the thing that is strange here is this:

Windows 98's installer can overwrite whatever Debian's installer did along the line of a boot menu, but Windows 7 cannot. So in my case, I have three different kinds of Windows loaders and Linux to gather together into one, and no system can be free to believe it owns the machine.

I have "virus warning" turned on in my BIOS, and I do not recall an update ever setting it off. But yes, I have in the past at least had trouble with apps and an MBR.

That article is total nonsense!
The MBR and the standard boot sequence is defined by IBM when it released its first harddisk. It only permits the left over of the MBR sector and the sector following that to be used as the boot sector(s). The space after that and the first usable sector for a partition is reserved. Reserved as is "don't use it", not reserved for the boot loader. It's defined as slightly over 1 sector because at that time harddisks are accessed using their geometry. In the worse case, that's all the space before the first usable space for a partition.

Unfortunately, it didn't take long for some creative minds to find some creative use for that normally unused space. I don't think it takes a very creative mind either to imagine how things could go wrong. I have absolutely no sympathy here as they deserved what they got. I hold exactly the same attitude towards GRUB when it's put into that reserved space. Neither Debian or GRUB has any right to rewrite the standard. They can't just claim that space as their own and said nobody should touch it. When they use that space, they are every bit as guilty as the other applications.

The correct way to do things is to put a simple boot code into the boot sector. Because of the space limit, that code can only find the active partition in the MBR, and look into that partition for a boot signature. If that signature is present, the boot code loads the data there assuming that's the boot loader. This boot code is pretty generic, it works for every OS that follows the standard.

In this standard scheme, there's only one active partition. Whether you can choose what OS to boot depends on this boot loader. But in the worse case, you can use a small tool to set the active partition and boot into that OS on the next reboot.

The boot loader installed by Windows is actually standard compliant. The only sin if you can call it is that it doesn't add any entries for linux by itself. That what programs like EasyBCD does.

There's however one catch that is caused by linux's standard way of doing things. By default, linux distros like to put GRUB into the reserved space after the MBR and do not put a copy in root. To use any standard boot loader that doesn't make exceptions for linux, you have to have GRUB in root too.

That however brings up another problem caused by linux. If you ask the installer to put GRUB in root, it usually won't write any boot code to the boot sector. So if you haven't setup any other OS before, your boot chain is broken until you use another tool to write the boot code.

I haven't used the vanilla Debian, does it have any advanced settings? Maybe it's just hidden somewhere.

For the Windows family, install will always write a generic boot code to the boot sector and the boot loader of that OS to the partition you install it to. The only exception is when you install Windows9x and the NT series in the same partition but that is not something I would recommend.

After installing Windows, you'll always get the boot menu of the last OS you installed and the menu will contain all the OS that the installer understands. That means no linux as Windows installer doesn't recognize any linux at all. If your linux has the necessary boot loader in its partition, you can use something like EasyBCD to add the entries and Windows' boot loader can boot linux as well.

If you install linux after Windows, then it'll usually put GRUB after the MBR. In that case, installing any other OS will break linux's way of doing things. If you want GRUB back, boot into some live CD and install it manually.

A better way is to put GRUB in its own partition or root. Since your machine is not linux exclusive, you don't have to worry about the boot sector. In this way, you just have to set the active partition back to the boot loader you want after installing any OS. Off course you may still need to tell that boot loader about any new OS you installed.

Question: is this an x64 system? And if it is, why are you using a BIOS/MBR and not an EFI?

Statement: bcdedit from a WinPE enviroment should be able to sort you out... mostly.

If you're using an MBR though, worst case scenario you can just change the active partition flag.

Unless leejosepho get rid of all his 32-bit OSes (Windows 9x, 2000, 32-bit XP), he can't really switch to EFI.

Unless he's virtualizing those OSes. And I don't get why you wouldn't anymore, with a 31 bit user addressable space on most of them, even a pretty basic machine with 4-6 GB of RAM is better off virtualizing a 32 bit OS from a support/usability standpoint.

I understand and I certainly agree, and I had forgotten IBM's initial role there. However, and while still meaning to respect your expertise: Are you certain that unused space was meant to *never* be used? I first began learning some of this kind of stuff on a Commodore, and writing "tight code" and "packing it in" were orders-of-the-day for a variety of reasons. In any case, and just as many people doubted there would ever be a PC in every house, I suspect few people thought there would ever be more than one cook in the MBR kitchen.



That is what I want, and I now think I finally have the software to make it possible for me to be the only "cook" mixing things together here. However, third-party stuff can also be troublesome. In the past, OnTrack's stuff has not always formatted drives correctly, and now in this modern day even EasyBCD cannot always find things and has trashed my Win7's loader a couple of times ,,, but I think something about GRUB (yet another third-party piece, as I see it) might have played a part in that.

From its website: "It installs itself in the first track of the hard disk, wich is reserved for these kinds of programs. It can also be instaled on a floppy disk, without using the hard disk." (emphasis added)

To me, "wich" and "instaled" make me wonder about the possibility of typos -- a.k.a. "crash" -- in the code! But actually, I have purchased some boot software that should let me put a menu anywhere I wish and then go to it simply by telling my BIOS to just never mind about "C" at all and to move along to somewhere else instead.

I have been using SuperGRUB from a bootable CD for the past several days, but I have not tried to actually install it because I know nothing about how it "thinks" or operates or what its utility-menu selections actually do. Overall, Linux and GRUB do not seem intuitive to me even in SuperGRUB's GUI form, and it is going to take a while for me to ever become even awkwardly proficient (no disasters) in a terminal. Along that line, however, I might do an upgrade from Mint 8 to Mint 9 via "apt" or whatever since the GRUB installer (and definitely the partitioner) for Mint 9 seems to have some kind of issue with my machine.

I do not recall specifically asking about multi-boot loaders on Debian's forum, but some other folks there did try to help me get my printer working ... and at that time, easyBCD and everything on my machine were getting along just fine until some kind of Debian (or GRUB?) update somehow trashed the boot loader I had previously let it put on my "C". I do not want or mean to bad-mouth GRUB, but I will never again let it anywhere near my MBR or boot sector.

Microsoft likes to ensure that other operating systems are not in any boot list unless they are previous versions.
Linux will allow you to boot back into Windows.

I'd run the install disk and look at "repairing" the install and take a look at the GRUB/GRUB2 loader