OSDev.org

If you were using 9x, it was extremely touchy about everything making it difficult to dual boot with anything else (GRUB has a "makeactive" command or something to try and circumvent it but that requires the boot partition be hardcoded into the MBR AFAIK)

"makeactive" sets the active flag on the designated partition. Using that, I was able to set up a tripple-Windows / Linux / BSD system no problem.

As long as the active flag was properly set and the non-booting partitions properly hidden. That's why I was confused.

Win2k was much trickier in that regard. Never used XP for any significant length of time.

In my current setup I have the default MBR (the default windows MBR, which has nothing to do with 'windows bootloader' or 'windows bootsector', it's just the MBR!), which chainloads /dev/hda1 's bootsector, which is the windows XP's bootsector. From there, the windows bootloader gets started.

In the XP bootmenu, I have an entry 'linux', which chainloads GRUB's bootsector. This sector resides in a file on the C: partition. The line in boot.ini reads like:
grubboot.bin loads GRUB's second stage, and from there it loads my linux kernel and initrd. Windows XP's bootloader is capable of chainloading any bootsector from within a file, which it has access to (that is - resides on a FAT or NTFS volume). I'm not sure whether it will chainload the bootsector of an unknown partition type - and the only reason why chaiload from file works, is probably that they need this to properly boot a windows9x installation.

The reason why I chose this configuration is that I can now reinstall windows (yeah - so much hassle just for windows ), and let it overwrite the MBR and the active partition's bootsector, without having to set up GRUB again - windows setup doesn't ask you to overwrite boot information, it just does.

cheers Joe

Means that now it's not the Linux bootloader hijacking the MBR, but the Windows one. And you have to readjust the boot sequence both when reinstalling / removing Windows (boot.ini, grubboot.bin) and when doing so with Linux (GRUB stage2).

Just to show that it's not as easy as AR and you made it sound at first.

Dual-booting is a pain, no matter how you twist it.

Sorry, just noticed that Candy already said most of these things.

Regarding dd: I wasn't sure whether the hd's driver under linux would allow to overwrite the entire partition table through the block-write system call. I know, it is a part of the mbr (sector 0), but fdisk under linux does not modify the partition table through reading and writing this block - it does so through special ioctl() calls. So I suspected that the driver itself tries to protect the partition table whenever the sector 0 gets overwritten - and the method they showed in the paper above confirms this. (There they simply replaced the sector 0 by a zero-filled-sector, and then rerun lilo to reinstall its hacked MBR-code - if the driver allowed to freely overwrite the whole sector, this would have scratched the partition table completely)

Or am I missing something in the environment? A backup of the partition table behind the scenes?

cheers Joe

JoeKayzA wrote: Sorry, just noticed that Candy already said most of these things.

Regarding dd: I wasn't sure whether the hd's driver under linux would allow to overwrite the entire partition table through the block-write system call. I know, it is a part of the mbr (sector 0), but fdisk under linux does not modify the partition table through reading and writing this block - it does so through special ioctl() calls. So I suspected that the driver itself tries to protect the partition table whenever the sector 0 gets overwritten - and the method they showed in the paper above confirms this. (There they simply replaced the sector 0 by a zero-filled-sector, and then rerun lilo to reinstall its hacked MBR-code - if the driver allowed to freely overwrite the whole sector, this would have scratched the partition table completely)

Or am I missing something in the environment? A backup of the partition table behind the scenes?

cheers Joe

That could be, although I doubt it. Linux doesn't recognise changes and can overwrite them however if you have anything mounted on it, if you don't use IOCTL calls. If you do, it invalidates them but you still have to reboot. I think it's mainly that that method is more secure for making sure your new stuff is on it, not that the old stuff is protected.

Solar wrote: Means that now it's not the Linux bootloader hijacking the MBR, but the Windows one. And you have to readjust the boot sequence both when reinstalling / removing Windows (boot.ini, grubboot.bin) and when doing so with Linux (GRUB stage2).

In my specific setup, I keep grub's stage2 files on the C: partition too. But that has entirely different reasons. And now I'm really going to investigate whether there is a standard PC-mbr-image or we are all using OS-specific ones. I still go with the opinion that OS-specific boot code should not go into the mbr.

Solar wrote: Dual-booting is a pain, no matter how you twist it.

That is one very true statement, indeed.

cheers Joe

OK, I found something at ATA-Atapi.com, don't know how official this site is. You'll find this, a disassembly of the 'standard ATAPI master boot record'. It seems to do exactly what the windows MBR is supposed to do. For me, that would clear the MBR issue: boot code should always go into a partition's boot sector, the used partition should then be marked active.

cheers Joe

That is more or less what the Windows MBR does except that it uses the LBA INT 13 Extensions which allows it to boot a partition that is deeper then 4GB (or <10GB, whatever) on the drive.

JoeKayzA wrote: OK, I found something at ATA-Atapi.com, don't know how official this site is. You'll find this, a disassembly of the 'standard ATAPI master boot record'. It seems to do exactly what the windows MBR is supposed to do.

Well... first of all, it should be the ATA master boot record, since those drives commonly don't support ATAPI. It's probably best said as ATA/ATAPI.

It does look like the non-windows one to me. I disassembled the one on my own computer once (dunno when, some time ago, believe it was with windows 98) and it referenced the partitions' internal data from the MBR. That would be pretty not ok with non-windows partition types.

And according to GRUB stage1 sources, WinNT (2k? XP? dunno.) does add a couple of "magic bytes" right in front of the partition table that aren't documented anywhere either. I don't know what happens if you tamper with them, but no mainstream OS keeps the MBR sacrosankt.

Candy wrote: Well... first of all, it should be the ATA master boot record, since those drives commonly don't support ATAPI. It's probably best said as ATA/ATAPI.

Sure, sorry about that. ::) I think my typing is too fast...or my brain too slow.

Candy wrote: It does look like the non-windows one to me. I disassembled the one on my own computer once (dunno when, some time ago, believe it was with windows 98) and it referenced the partitions' internal data from the MBR. That would be pretty not ok with non-windows partition types.

And according to GRUB stage1 sources, WinNT (2k? XP? dunno.) does add a couple of "magic bytes" right in front of the partition table that aren't documented anywhere either. I don't know what happens if you tamper with them, but no mainstream OS keeps the MBR sacrosankt.

Agreed, it would just be interesting what they actually do inside the partition data then. I mean, it can't be anything vital for the boot procedure, since chainloading the bootsector alone also works without notable differences. Could it be just because of support for boot partitions above the 4GB boundary, as AR mentioned? Or some kind of mbr protection - against viruses?

cheers Joe

JoeKayzA wrote:

And according to GRUB stage1 sources, WinNT (2k? XP? dunno.) does add a couple of "magic bytes" right in front of the partition table that aren't documented anywhere either. I don't know what happens if you tamper with them, but no mainstream OS keeps the MBR sacrosankt.

Agreed, it would just be interesting what they actually do inside the partition data then. I mean, it can't be anything vital for the boot procedure, since chainloading the bootsector alone also works without notable differences. Could it be just because of support for boot partitions above the 4GB boundary, as AR mentioned? Or some kind of mbr protection - against viruses?

No, it isn't for the MBR. It's an integrity check for the boot sector. If the boot sector can't be read, the backup boot sector is read. That's a FAT32 specific detail, so it checks for FAT32 first, then loads the second bootsector instead.

So, it doesn't harm but can do good. Still, it's not nice to screw up the standard yet again.

Hi everyone!

Sorry to bring this back from the supposed dead, but I may have found me a solution!

If you check out http://support.microsoft.com/default.aspx?scid=kb;en-us;315224 from Microsoft you'll find some good instructions on how to remove the LILO bootloader so that you can safely erase your LInux partition.

@Candy: Thanks for the suggestion of the 'fdisk /mbr' command in Windows. Unfortunately it is possible to mess up the entire HD with that, at least I am told so by a family friend that has tinkered with Linux before and has had the same problems as me.

Thanks to everyone for their advice, though

Calum wrote: @Candy: Thanks for the suggestion of the 'fdisk /mbr' command in Windows. Unfortunately it is possible to mess up the entire HD with that, at least I am told so by a family friend that has tinkered with Linux before and has had the same problems as me.

The microsoft site you yourself brought in says this:

If Linux Is Not Still Installed
NOTE: The following procedure is not supported by Microsoft and is performed strictly at the discretion of the user. Microsoft assumes no liability for lost or corrupted data. This procedure should be performed only as a last resort.

IMPORTANT: Running fdisk /mbr removes the disk signature from the MBR. If the drive is a member of a Windows fault tolerance set, the drive is no longer recognized as a member of that set.

1. Boot to MS-DOS, and then type the following:
fdisk /mbr
2. Restart your computer.

You will then only mess up the harddisk if:

- It was a dynamic disk in windows.
- You didn't mark the windows partition as active before trying fdisk /mbr

Iirc you cannot make your boot disk a dynamic disk, so the only case in which it would matter was if your linux was on a different disk that was the first disk on the computer, on which you had the boot code that loaded Windows off the second one, and then converted the first one to a "dynamic disk".

I seriously can't see any other reason why it could screw up your system. fdisk plain overwrites anything lilo might screw up, so if anything fails, it's purely Microsoft failing (or the user failing, say, with settings in the OS or in the partition table).