20

A hard drive that I use only for data storage still has GRUB from past Ubuntu installations.

How can I remove GRUB from it without harming the rest of the drive's data?

Background

I occasionally move the data drive between computers with various boot order configurations, so I would like it to be non-bootable in order to avoid having to accommodate it in each computer's BIOS settings.

When I power on a computer while only the data drive is attached, the following appears:

error: no such device: fdf38dd4-9e9d-479d-b830-2a6989958503.
grub rescue> 

I can confirm from old backups of /etc/fstab that this was the UUID of a root partition that I recently reformatted and which no longer exists. Here's the the data drive's partition table and raw master boot record.

Please note that I'm not interested in workarounds that don't answer my primary question. I can think of several ways to work around this issue, but it bothers me on principle that I don't know how to directly resolve it. Every installation procedure should have a counterpart uninstallation procedure.

2
  • Just curious - if you delete the files in /boot/grub (which I assumed you did), does the mbr code really matter? I don't think it will get used by anything else, will it? I could be wrong, but I wouldn't think it would be used, and I'd hate to screw around with something at such a low level if I cared about the data. May 4, 2012 at 2:12
  • Can you dump the raw MBR data and post it here? You should be able to do something like sfdisk -d /dev/sdb > sdb.out. May 5, 2012 at 16:39

6 Answers 6

26

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 from the current IP (so to 0x65).

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 newbie 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/zero again 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

Hope this helps.

2
  • 1
    I'm giving you a plus one for anticipating and preventing a serious noob error.
    – psitae
    Mar 19, 2018 at 11:10
  • Thanks a bunch, I did my best to prevent as many noob errors as possible: making a backup, not writing directly to the block device in case count is forgotten, not directly using a common block device name, specifying that the backup file should be made off of the device being changed, an example of what a successful clearing looks like, how to undo if you screw up. I figure if you're knowledgeable enough to know what I'm getting at you can cut through the baby steps and just do all of this in a single command. But I'm not going to give you that command if you're still learning. ;) Mar 20, 2018 at 17:46
2

WARNING: EXTREMELY DANGEROUS

You can use dd command from Linux itself (it removes partition table):

 # dd if=/dev/null of=/dev/sdX bs=512 count=1

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

  1. http://www.cyberciti.biz/faq/linux-how-to-uninstall-grub/
6
  • Those byte counts look uncomfortably arbitrary. Do you know if they're the same for GRUB2?
    – ændrük
    May 4, 2012 at 2:08
  • 1
    The byte count is because the partition table lies between 446 and 512. Of course, this begs the question of why you want to remove the grub MBR... it isn't hurting anything just sitting there unused. If you want another boot loader instead, just install it and it will replace grub.
    – psusi
    May 4, 2012 at 2:39
  • 3
    Wow, this type of answer should have "WARNING: EXTREMELY DANGEROUS" written in big red letters all over it. I'm sure the OP is capable of doing this but I'd hate to see some newbie user copy-pasting the first command into the terminal without even knowing what "partition table" is
    – Sergey
    May 4, 2012 at 2:47
  • 2
    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. May 5, 2012 at 16:36
  • 3
    Umm.. I don't know why you guys are freaking out, the commands that tachyons pasted don't do anything at all. You can test with touch testfile, dd if=/dev/urandom of=testfile bs=512 count=1, sudo losetup /dev/loop7 testfile, sudo dd if=/dev/null of=/dev/loop7 bs=446 count=1, sudo hexdump -Cv /dev/loop7. As you can see /dev/null is not a 0 source, it's a EOF source. dd cannot and will not copy anything from /dev/null you need to use /dev/zero. Second @Breakthrough, no undefined behavior is possible if the first byte of sector 0 is 0x00. I don't know why you think that. Jul 26, 2012 at 17:47
2

My experience with

sudo install-mbr -i n -p D -t 0 /dev/sda

is, that it successfully un-installed grub2 from /dev/sda (where my Windows 7 is installed), so the first part of the question "How do I remove grub from /dev/sda?" has been answered.

However, the 2nd part of the question, which is "How do I restore the MBR of /dev/sda?" has not been answered since the install-mbr command failed to restore the MBR. As a result, Windows does not boot any more and the Windows boot manager reports an error about a damaged MBR and asks the user to repair from a windows repair CD.

1

After reading the Wikipedia article on the subject I'd like to propose a few additional solutions:

  1. Change boot order in BIOS :)

  2. 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:

  3. Install mbr package and use install-mbr command like this:

    sudo apt-get install mbr
    sudo install-mbr -i n -p D -t 0 /dev/sda
    

Credits: HOW TO: Recover Windows MBR using Ubuntu LIVE CD

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 is 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 hang 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...

0

Another more simple solution.

In my case i had Debian linux but wanted to use Mandriva, will work for others too

Turn off your pc, then remove the disk that boots that you dont want to boot (that has grub)

Simply put in a bootable usb made from the mandriva iso or other variant you like to install there are tools for making bootable usb sticks from iso files use google (or you could us a burned installer from cd rom)

Now most linux installers give you a choice of what to do, try and play / use for evaluation or portable linux or run setup to install it. At this point we just wait (move up down cursor so the screen will wait but dont press enter or click with the mouse).

Just remind at this point your USB / or / CDRom has started and is running. now its time to plugin back the harddisk that we temporaly removed wait a minute (some bios do require a small wait a minute is more then enough)

Continue to setup process since most installers contain partitions tools you can do whatever you want. well its a simple solution, i got rid of an old linux setup simply as a beginner

0

Old question, but as it happened to me yesterday, I solved it like this: I turned off the computer, physically disconnected the incriminated hard drive, started again the computer, then

~ $ sudo update-grub

Done this, I switched off the computer, reconnected the hard drive and my old Windows 7 partition, no longer existing since 2 years ago, didn’t show up—finally.

I understand this is a down to earth solution, but it works. One day I’ll wipe that hard drive totally, and any remaining trace of GRUB will disappear.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .