"Linux Gazette...making Linux just a little more fun!"

Experimentation is fun. After all, one of the things that makes Linux so interesting to a number of people is the ability to twiddle settings and see what happens - I'll admit that it's a major factor for me. One of the problems with that, though, is that some types of twiddling can lead to serious problems. A bit like sawing off the branch you're sitting on, in fact...

A number of people write to the Answer Gang with a query that goes something like this:

"Dear TAG: I have a stick of dynamite strapped to the CPU, and I'm not afraid to use it. Now that I have your undivided attention: I ran into a problem while trying to reinstall..."

What it turns out to be - after the police, the fire department, and the burly men in the white coats have come and gone - is that they've run into the classic "fried MBR" problem: install Linux, realize that Windows will screw up the boot record, delete the Linux partition, try to install Windows first... OOPS. The Windows setup runs into a problem and stops.

The reason for all of the above is that they forgot to uninstall LILO, which would have written out the original MBR; as it is, the boot code in the MBR is trying to pass control to the Linux kernel - and that's no longer there.

Nothing helps. The undocumented "fdisk/mbr" option that is supposed to write a clean Master Boot Record seems to have no effect; "fdisk" in interactive mode refuses to delete the "Non-DOS" partition; even the detonator fails to explode. What to do, what to do...

By the way, a factor in the first two problems might be the Windows "lock" command - by default, 'raw writes' to disk are disallowed, and "lock c:" 'locks' the drive to allow writing to it. (For the last problem, stick to the bridge-wire type detonators from Dynamit Nobel, and store them
properly. :)
 

    * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
    Note: The following advice will completely wipe your Master Boot Record,
    which contains all your partition information. DO NOT DO THIS unless you
    know that this is exactly the result you want - it will leave your HD in
    an unbootable state, in effect bringing it back to "factory-fresh", i.e.,
    empty of data and requiring partitioning and formatting.
    * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
 

Linux-based solution

If you can still somehow fire up Linux - say, via Tom's Root-Boot floppy - you can simply invoke "dd", like so:

dd if=/dev/zero of=/dev/hda bs=512 count=1

Yep, that's it. That MBR is gone. Obviously, you have to be root to do this.
 

DOS-based solution

Boot with a DOS floppy that has "debug" on it; run "debug". At the '-' prompt, "block-fill" a 512-byte chunk of memory with zeroes:

f 9000:0 200 0

Start assembly mode with the 'a' command, and enter the following code:

mov dx,9000
mov es,dx
xor bx,bx
mov cx,0001
mov dx,0080
mov ax,0301
int 13
int 20

Press <Enter> to exit assembly mode, take a deep breath - and press "g" to execute, then "q" to quit "debug". Your HD is now in a virgin state, and ready for partitioning and installation.

Obviously, you have to be root... oh, oops. Anybody that walks up with a DOS floppy can do this to your system in about a minute, including boot time. Let's see; where was that article about securing your box, again?...

References

The "dd" man page.

DOS-based fix: Original idea and code by Mark Minasi, used for clearing infected/damaged MBRs in a course of his that I used to teach; all code/command modifications mine.

Copyright © 2001, Ben Okopnik.
Copying license https://www.linuxgazette.net/copying.html
Published in Issue 63 of Linux Gazette, Mid-February (EXTRA) 2001