If you have been dual booting with Linux, then you probably know one of the Linux boot managers like Grub or LILO has been installed in the MBR of your hard drive. What can you do when you no longer want Linux on that hard drive? This tutorial will show you how to use your 7 DVD and BOOTSECT.EXE to restore the "bootsector code" of the MBR and allow you to begin booting to Windows 7 again.
1. Boot your computer to the Windows 7 DVD (or to a "Repair CD"). At this screen choose to install now.
2. Select your language and click next.3. Click the button for "Use recovery tools".
Load drivers if you have a SoftRAID4. Then select "Command Prompt".5. When open, the command prompt will look like this:6. The command we will use, bootsect.exe, is in a folder (named boot) on the DVD.We need to know what drive letter has been assigned the DVD drive to access the folder.In this screen shot, the 7 DVD is letter: GCode:Type: diskpart and press Enter Type: select disk 0 (zero) and press Enter type: list volume and press Enter7. Use your DVD drive letter andto verify that bootcect.exe is there (if you really need to)Code:Type: exit and press Enter to close Diskpart Type: G: (use the letter of your DVD drive) and press Enter Type: cd boot and press Enter Type: dir and press Enter8. To restore the "bootsector code":
Code:TYPE: bootsect /nt60 SYS /mbr and press EnterNOTE: If this method fails to restore the MBR, you can try the bootrec command as it is also a tool for repairing the MBR.9. When completed successfully,
Code:Type: exit and press EnterThis will close the command prompt window.10. Now select Shut Down or Restart11. Then you can reboot your computer into Windows.
Related Tutorials
============================
http://tech.reboot.pro/showthread.php?tid=2145
Insert the win7 recovery disc inside a CD/DVD or flash drive (use YUMI)
after booting the disc, go to the command prompt and type the following:
This part makes sure that "access denied" won't show up when restoring mbr.
Code: (SELECT ALL CODE)Diskpart
list vol
sel vol Z (The Z changes according to what drive letter your WINDOWS installation exists)
act
exit
Code: (SELECT ALL CODE)bcdboot D:\windows /s X:
bootsect /nt60 D: /mbr
===========================
http://tech.reboot.pro/showthread.php?tid=1424
If you have a Windows 7 installation disk, or also known as a repair disk, which every Windows 7 user should take the time to burn off to a CD from their Windows 7, you can boot from the disk through your boot menu or changing the boot order to boot from that disk.
In here there's an option for command prompt. It will start you off in a System32 drive for the Windows machine it previously found on the window before it allows you to choose cmd prompt as an option, and it labels this as X but don't be alarmed.
From here you want to navigate to the boot dir, so using this command, that can be done:
Code: (SELECT ALL CODE)
cd BootThen in here there's a file called bootsect.exe. This is what our lifesaver is going to be... Since we run (Or I) Windows 7, you need to remember the parameter /nt60, this basically is short for the Windows NT 6.0 and greater. Any earlier, and you would have to use /nt52 which should be anything below Vista if i'm correct.
Here's the command we're going to use:
Code: (SELECT ALL CODE)
bootsect /nt60 SYS /mbrThere's a force command, but I would recommend not using it, since it's not really needed for this and it is a little dangerous.
This command basically tells you to repair/update the boot record for the SYSTEM drive allocated to your Windows OS found during the CD's startup. Once this is done, you can use the exit command to close the window, and then choose to Reboot your machine.
You should now be able to get back into Windows, and no more annoying Grub boot menu asking you if you want to boot from Linux or Windows. I never used my Linux is the thing, so I finally decided to get rid of it after some thought, and now I can just use my Windows. :)
===========================
http://askubuntu.com/questions/131168/how-do-i-uninstall-grub
WARNING: EXTREMELY DANGEROUS
Do not do this. The first command will wipe out the partition table (as the OP mentioned), but the second command will cause undefined behaviour if the MBR is not configured properly.
1 You can use dd command from Linux itself (it removes partition table):
# dd if=/dev/null of=/dev/sdX bs=512 count=1
2 Just remove MBR, without the partition table (see comment below):
# dd if=/dev/null of=/dev/sdX bs=446 count=1
Replace
/dev/hdX with your actual device name such as /dev/hda. Use fdisk -l command to find out device name:# fdisk -l
Source
------------------------------
dump the raw MBR data
sfdisk -d /dev/sdb > sdb.out-------------------------
you can render the device not bootable simply by making the first few bytes of the disk 0x00.
Typically (and this is true for both grub, grub2 and ntldr iirc) the very first byte of your drive is going to be an x86 jmp instruction. This occurs before even the disklabel, because when passing execution to the device to bootstrap it, it simply sets the CPU to suck in the device information as code. If it has invalid code it triggers an interrupt and the BIOS handles the exception and goes to the next bootable device.
For instance, the beginning of my disk starts with:
00000000 eb 63 90 d0 bc 00 7c fb 50 07 50 1f fc be 1b 7c |.c....|.P.P....||
The first part is
eb 63 which is Jump to offset 0x63.00000060 00 00 00 00 ff fa 90 90 f6 c2 80 74 05 f6 c2 70 |...........t...p|
00000070 74 02 b2 80 ea 79 7c 00 00 31 c0 8e d8 8e d0 bc |t....y|..1......|
Execution continues from here.
The end of the sector looks like this:
000001b0 cd 10 ac 3c 00 75 f4 c3 ed db 96 d6 00 00 80 01 |...<.u..........|
000001c0 01 00 83 fe ff ff 3f 00 00 00 c1 07 a6 0e 00 fe |......?.........|
000001d0 ff ff 83 fe ff ff 00 60 00 11 00 00 38 29 00 fe |.......`....8)..|
000001e0 ff ff 82 fe ff ff 00 08 a6 0e 00 58 5a 02 00 00 |...........XZ...|
000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
If your disk is formatted as an MBR partition table then it only needs two things to be present, the partition table which is at offset
0x1be and the MBR signature, 55aa which occurs at the very end of the sector at offset 0x1fe. 0x1be is decimal 446.
The following will (of course) make the device unbootable. But this is what you want. If you don't want to make your device unable to be booted then don't do this mmm-kay? I'm assuming your device is /dev/sdz, simply because not many people have a /dev/sdz, and this lowers the risk of some idiot newb blindly copy pasting commands.
First, copy the MBR to a file for a backup.
sudo dd if=/dev/sdz of=/some/where/safe/preferably/not/on/dev/sdz/backup.mbr bs=512 count=1
Next, make a copy of that file:
cp backup.mbr backup.mbr.test
Next, we have to create a loopback device (so that the contents don't get truncated.) And apply the changes on our fake sector 0 as a test:
sudo losetup /dev/loop7 backup.mbr.test
sudo dd if=/dev/zero of=/dev/loop7 bs=446 count=1
sudo losetup -d /dev/loop7
Hexdump the file and make sure that the entire partition table is intact:
sudo hexdump -C backup.mbr.test
You should see something like:
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 01 |................|
000001c0 01 00 83 fe ff ff 3f 00 00 00 c1 07 a6 0e 00 fe |......?.........|
000001d0 ff ff 83 fe ff ff 00 60 00 11 00 00 38 29 00 fe |.......`....8)..|
000001e0 ff ff 82 fe ff ff 00 08 a6 0e 00 58 5a 02 00 00 |...........XZ...|
000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
00000200
Now,
0x1be is where you see 80 on the hexdumped output, this can also be 00 and still be valid. (It's the "bootable" flag in the partition table, you can leave it alone, because it's completely ignored by most modern BIOSes...) The byte at 0x1bf though will almost NEVER be 0x00 (it's most commonly 0x01 but it can take other values) you can compare this against your backup.mbr to make sure that nothing past 0x1be is changed.
Once you're satisfied that you applied the change correctly then you can directly copy the file over the first part of the disk. The reason why you want to do the file rather than
/dev/zeroagain is for safety against typos. If you accidentally omit count=1 you're gonna have a bad time, copying a file on the other hand will never run past the EOF, ever. So it's safer.sudo dd if=backup.mbr.test of=/dev/sdz
Next hexdump your disk to make sure that the changes took as expected.
hexdump -C /dev/sdz | head
Compare up to
0x200 against backup.mbr.test to make sure it's what you want.
Finally, if anything screws up for whatever reason you can simply copy the backup of the MBR back onto the drive via:
sudo dd if=backup.mbr of=/dev/sdz
After reading the Wikipedia article on the subject I'd like to propose a few additional solutions:
- Change boot order in BIOS :)
- The best and the safest one: use fdisk to remove "bootable" flag from any partitions on that drive. Most MBRs look for a "bootable" partition to chain-load from, so I would expect GRUB to just do nothing if there are no such partitions. Haven't tested though.If the above does not help, try installing a free clone of standard MBR code:
- Install
mbrpackage and useinstall-mbrcommand like this:sudo apt-get install mbrsudo install-mbr -i n -p D -t 0 /dev/sda
I mean, from reading the Wikipedia article, I have an impression that the only thing which identifies the MBR is its signature which is at the very end of the sector (bytes 510 and 511). The first 446 bytes of MBR supposed to contain machine instructions. The BIOS is supposed to transfer control to the bootloader regardless of the actual contents of the first 446 bytes, provided that MBR signature is present:
On IBM PC-compatible computers, the bootstrapping firmware contained within the ROM BIOS loads and executes the master boot record.[14]... Thus, the beginning of the MBR is expected to contain real mode machine language instructions.[14] The BIOS reads the MBR from the storage device into physical memory, and then directs the microprocessor to the start of the boot code.Due to the restricted size of the MBR's code section, it typically contains only a small program that copies additional code (such as a boot loader) from the storage device into memory. Control is then passed to this code, which is responsible for loading the actual operating system....The bootstrap sequence in the BIOS will load the first valid MBR that it finds into the computer's physical memory at address 0x7C00. The last instruction executed in the BIOS code will be a "jump" to that address, to direct execution to the beginning of the MBR copy. The primary validation for most BIOSes is the 0xAA55 signature on the end, although a BIOS implementor may choose to include other checks, such verifying that the MBR contains a valid partition table without entries referring to sectors beyond the reported capacity of the disk.
So my understanding is that MBR always supposed to contain a bootloader, and zeroing the first 446 bytes of it would not stop BIOS from trying to boot from the disk - but it is likely to make the computer hand while trying to execute invalid code.
UPDATE: Also, this article suggests that to make the disk to look "un-bootable" for BIOS you should actually edit the MBR signature at the and of the sector (using any disk editor). I'm not sure if it's going to affect OS seeing the partition table on the disk though... but at least you can always modify those bytes back...
LibreOffice
Firefox
OpenSUSE
