# How Do You Remove Grub From MBR <SOLVED>

## grofaz

Is it possible to remove grub from the master boot record without resort to reformatting the drive ?Last edited by grofaz on Tue Oct 21, 2008 2:20 am; edited 1 time in total

----------

## danomac

You should be able to boot a Windows 98 boot disk and execute

```

C:> fdisk /mbr

```

That command cleans the master boot record. It unfortunately wipes all of the partition tables from the disk, so be careful.

Edit: I didn't read the original post correctly, sorry.   :Embarassed: 

I don't know of a way to do this nondestructively.

----------

## grofaz

Does that method wipe out your install ? I have win xp on hda and gentoo on hdb. Grub is on hda. I want to remove grub without destroying my xp install. Is it possible ?

----------

## d2_racing

Hi, maybe you can use DD to format your MBR.

----------

## cyrillic

 *danomac wrote:*   

> It unfortunately wipes all of the partition tables from the disk, so be careful. 

 

No, "fdisk /mbr" only replaces the first stage bootloader code, not the partition table.

This is the right approach if you want to ditch Linux, and go back to booting an existing DOS/Windows installation.

----------

## i92guboj

 *cyrillic wrote:*   

>  *danomac wrote:*   It unfortunately wipes all of the partition tables from the disk, so be careful.  
> 
> No, "fdisk /mbr" only replaces the first stage bootloader code, not the partition table.
> 
> This is the right approach if you want to ditch Linux, and go back to booting an existing DOS/Windows installation.

 

True.

And using dd, as someone suggested above, will not work if what you meant is to zero-out the boot loader. You need to put another bootloader (which is what fdisk /mbr will do, put the windows/dos loader). Otherwise, you are not going to be able to boot. You could continue using grub though.

----------

## CooSee

 *grofaz wrote:*   

> Is it possible to remove grub from the master boot record without resort to reformatting the drive ?

 

on running WinXP load your XP CD and start the ' XP - Terminal ' with ' Start --> Run --> and 

type ' cmd '   :Exclamation:   change to your CDROM, e.g. ' d:\ ' and cd to the ' i386 ' Folder e.g. ' d:\i386 ' 

and type ' winnt32.exe /cmdcons '

now the installation of the ' Recovery Console ' starts !

complete the installation and restart !

now at the WinXP boot menu you'll have a second option ' Recovery Console ' !

start it ! now if you do ' fixmbr ', the mbr will be replaced by XP !!!

or look here http://support.microsoft.com/?scid=kb%3Ben-us%3B216417&x=9&y=13

sorry for my bad English   :Rolling Eyes:   :Exclamation: 

CooSee ' Ya

----------

## grofaz

Thank you all, great stuff to know!!

----------

## CooSee

 *grofaz wrote:*   

> Thank you all, great stuff to know!!

 

you're welcome   :Very Happy: 

please ' edit ' and add ' solved ' to your thread  :Exclamation: 

CooSee ' Ya

----------

## Ink_arni

 *i92guboj wrote:*   

> And using dd, as someone suggested above, will not work if what you meant is to zero-out the boot loader. You need to put another bootloader (which is what fdisk /mbr will do, put the windows/dos loader). Otherwise, you are not going to be able to boot. You could continue using grub though.

 

Well, it depends on what you want to do, of course. dd would work fine if you only wanted to "uninstall" GRUB, but much caution is needed because you must not destroy the partition table.

After having a look at the Wikipedia article, I speculate that overwriting the first 446 (safer:440) bytes of the disk with zeroes would probably do the job if you don't have a Windows CD ready, and there's a chance that Windows would remain bootable after that!

That's because the Windows boot loader (NTLDR) is not installed on the master boor record, but rather on the first sectors of the first primary (and flagged as bootable) partition of the disk (at least that's true with older versions of Windows, I don't know about Vista). If BIOS fails to boot from the MBR, it automatically tries to boot from there.

Disclaimer: I don't know whether BIOS tries to read a magic number from the other (non-zeroed) sectors of the MBR to determine if the MBR is bootable and what happens if it does (nothing bad hopefully). Also I haven't tried it! But if there was no Windows CD available, I would try using dd (after taking a backup of the whole MBR of course, again with dd).

To take a backup:

```

dd bs=512 count=1 if=/dev/sde of=/media/your/flash/drive/MBR-backup.bin

```

Replace sde with your first hard drive.

For more information:

```

man dd

```

In any case, grofaz, I take no responsibility, even if this process completely destroys all your hard disks, burns your PSU, fries your motherboard and kills your pets!   :Razz: 

----------

## cyrillic

 *Ink_arni wrote:*   

> I speculate that overwriting the first 446 (safer:440) bytes of the disk with zeroes would probably do the job if you don't have a Windows CD ready, and there's a chance that Windows would remain bootable after that! 

 

When the BIOS boots, it looks for a signature, and then executes the code in those first 446 bytes.

If you overwrite that area with zeroes, then the BIOS will conclude that there is no operating system on the disk.

The only practical way to uninstall a bootloader from the MBR is to replace it with a different bootloader, otherwise you will simply have a computer that doesn't boot.

----------

## Ink_arni

 *cyrillic wrote:*   

>  *Ink_arni wrote:*   I speculate that overwriting the first 446 (safer:440) bytes of the disk with zeroes would probably do the job if you don't have a Windows CD ready, and there's a chance that Windows would remain bootable after that!  
> 
> When the BIOS boots, it looks for a signature, and then executes the code in those first 446 bytes.
> 
> If you overwrite that area with zeroes, then the BIOS will conclude that there is no operating system on the disk.

 

That's not what I remember, but I could be wrong. And what happens if you overwrite the signature, as well?

Your post gives me the impression that either you didn't read everything I wrote or you know something about BIOS that I don't. If that's the case, please provide more information. I don't know much about BIOSes and would be very interested in learning.

Anyway, I promise that I will test that little theory of mine and post here the results. Not now though; I need a working VMware setup first and my VMware modules are currently broken because of a kernel upgrade, so I'll have to reboot in Windows. Probably tomorrow.

PS. To restore the backup taken with dd correctly, I think that you should use the no-truncate option (conv=notrunc).

----------

## i92guboj

 *Ink_arni wrote:*   

>  *i92guboj wrote:*   And using dd, as someone suggested above, will not work if what you meant is to zero-out the boot loader. You need to put another bootloader (which is what fdisk /mbr will do, put the windows/dos loader). Otherwise, you are not going to be able to boot. You could continue using grub though. 
> 
> Well, it depends on what you want to do, of course. dd would work fine if you only wanted to "uninstall" GRUB, but much caution is needed because you must not destroy the partition table.
> 
> After having a look at the Wikipedia article, I speculate that overwriting the first 446 (safer:440) bytes of the disk with zeroes would probably do the job if you don't have a Windows CD ready, and there's a chance that Windows would remain bootable after that!

 

Mmm. I can never say 100%, but that would entirely depends entirely on the BIOS. However, I am really reluctant to believe this. Note that for that to be able to happen, the BIOS would need either some basic filesystem support (unlikely because the amount of code that fits on a BIOS chips usually is not that big) or some hacky code to be able to get low level access to read the OS loader or the kernel. That would be very OS specific as well, which would create all kind of issues like it happens with the grub chainloader stuff.

 *Quote:*   

> That's because the Windows boot loader (NTLDR) is not installed on the master boor record, but rather on the first sectors of the first primary (and flagged as bootable) partition of the disk (at least that's true with older versions of Windows, I don't know about Vista). If BIOS fails to boot from the MBR, it automatically tries to boot from there.

 

It doesn't matter where ntldr is if the bios doesn't load it first. About the bootable flag: it's something that only Windows cares about. It's meaningless for the BIOSes that I know of, and for most other OSes as well. It makes no sense either if you use a bootloader. There might be BIOSes that can do such kind of magic, but in any case I wouldn't rely on it so much.

I think that to definitely answer this question we would need to look at the bios source for a given motherboard. In the while, all we can do is theorize about it and nothing else. Alternatively we could use linuxbios/coreboot and take the control of the boot process on our own hands :p

Cheers.

----------

## cyrillic

 *Ink_arni wrote:*   

> ... or you know something about BIOS that I don't. If that's the case, please provide more information. 

 

I am not much of a BIOS expert either, but I have tried some of these things on actual computers (not virtual machines), so feel free to ask and I will answer what I can.

----------

## Ink_arni

i92guboj and cyrillic, thank you both for your replies.

Indeed, your were right and I was wrong, or, rather, I was a victim of a common misconception: That it is the BIOS itself that loads the boot sector of the first active partition. That's indeed false, although I am 100% certain that I read it somewhere about 3 years ago (Obviously the original author was wrong as well; that doesn't mean that I am innocent, I should have checked the facts before posting!  :Embarassed:  ).

It seems that the Windows boot loader has multiple stages just like GRUB, something I didn't know. The first stage is installed on the MBR and loads the next one, which must be on an active partition. Web pages like this one cleared this for me. (i92guboj: I was under the impression that the BIOS would load by itself what I now know as the second bootloader stage. I never said that the BIOS would boot the OS kernel directly, as you seem to imply!)

Still, although I knew the result, I tested what I said on a virtual machine (A promise is a promise!  :Smile:  ). I installed Windows Server 2008 (much easier to find my installation ISO file than my Windows XP CD!), then I installed Ubuntu JeOS 8.04.1 (wonderful for VMs and installs quickly - much recommended BTW) and finally I booted from a linux liveCD and wrote zeroes on the first 440 bytes of the disk.

As expected, the result was a complete failure to boot. The VM just hung there. The only useful thing I was able to verify, was the fact that Windows still installs the second stage of its boot loader on the first primary (and active) FAT partition it can find (if there is one), instead of the installation partition (which can only be NTFS for Vista and above). This was the behavior of Windows XP as well, although their loader seems to differ. Anyway, it was an interesting (and time-consuming) experiment.

 *i92guboj wrote:*   

> Mmm. I can never say 100%, but that would entirely depends entirely on the BIOS. However, I am really reluctant to believe this. Note that for that to be able to happen, the BIOS would need either some basic filesystem support (unlikely because the amount of code that fits on a BIOS chips usually is not that big) or some hacky code to be able to get low level access to read the OS loader or the kernel. That would be very OS specific as well, which would create all kind of issues like it happens with the grub chainloader stuff.

 

I believe that booting from the first sector of the first active partition of the disk (in case the MBR fails) would be trivial to implement in the BIOS, because you wouldn't really need filesystem support for that (Unsurprisingly, a "first sector" is always the first sector  :Wink:  ). Reading the partition table would be the only thing needed (at least for primary partitions). However, you are right; it doesn't work that way.

In fact, the way you explained it makes absolute sense: The BIOS has no need to even understand the concept of partitioning.

 *i92guboj wrote:*   

> About the bootable flag: it's something that only Windows cares about.
> 
> [...]
> 
> There might be BIOSes that can do such kind of magic, but in any case I wouldn't rely on it so much.

 

I see.

 *i92guboj wrote:*   

> In the while, all we can do is theorize about it and nothing else.

 

No, we can have empirical data, as well.  :Wink: 

That's what VMware is for, since it is useless for almost everything else! (Too much overhead and awful network performance!)

 *cyrillic wrote:*   

> I am not much of a BIOS expert either, but I have tried some of these things on actual computers (not virtual machines), so feel free to ask and I will answer what I can.

 

I believe that virtual machines would be identical to real PC hardware in respect to booting.

Anyway, thank you both for helping me learn new things.  :Very Happy: 

----------

## i92guboj

Thanks to you for taking the time to do some tests and for sharing the experience with all of us  :Wink: 

----------

## Monkeh

 *Ink_arni wrote:*   

> Indeed, your were right and I was wrong, or, rather, I was a victim of a common misconception: That it is the BIOS itself that loads the boot sector of the first active partition. That's indeed false, although I am 100% certain that I read it somewhere about 3 years ago (Obviously the original author was wrong as well; that doesn't mean that I am innocent, I should have checked the facts before posting!  ).

 

Actually, some BIOSes do. I know this from experience (I have a machine which will not boot without a bootloader in the first sector of the active partition, it does not load from the MBR).

----------

## Ink_arni

 *Monkeh wrote:*   

> Actually, some BIOSes do. I know this from experience (I have a machine which will not boot without a bootloader in the first sector of the active partition, it does not load from the MBR).

 

Well, this just makes things more complex and confusing...

You would think that there would be well-respected standards for something as important as the booting procedure, but no, every damn motherboard and BIOS manufacturer just has to do it his own damn way! (I even have a Gigabyte P4 machine which claims to be able to boot from expansion cards but actually fails to do so. The result: Since the only HDD is the one connected on the separate SATA controller, every time I want to boot it I have to use a CD containing my kernel.)

Unfortunately, since all VMware versions use the same virtual BIOS, I don't have any other means to test. I could use my actual machine but it is too risky, so I'm not going to do it.

Also, a minor correction: *Ink_arni wrote:*   

> PS. To restore the backup taken with dd correctly, I think that you should use the no-truncate option (conv=notrunc)

 

After some testing, it seems that notrunc  makes no difference when restoring (as long as the target is a block device, of course!).

PS. Sorry for the late reply, I was away from my home (and my PC) for a few days.

----------

## cyrillic

 *Ink_arni wrote:*   

>  *Monkeh wrote:*   Actually, some BIOSes do. I know this from experience (I have a machine which will not boot without a bootloader in the first sector of the active partition, it does not load from the MBR). 
> 
> Well, this just makes things more complex and confusing...
> 
> You would think that there would be well-respected standards for something as important as the booting procedure, but no ...

 

Yes, this is quite rare, and is technically an example of a defective BIOS.

----------

## Monkeh

 *cyrillic wrote:*   

>  *Ink_arni wrote:*    *Monkeh wrote:*   Actually, some BIOSes do. I know this from experience (I have a machine which will not boot without a bootloader in the first sector of the active partition, it does not load from the MBR). 
> 
> Well, this just makes things more complex and confusing...
> 
> You would think that there would be well-respected standards for something as important as the booting procedure, but no ... 
> ...

 

Unfortunately they exist.

----------

