[vox-tech] HOWTO [NOT] remove lilo...

[Rick Moen]

Quoting msimons@moria.simons-clan.com (msimons@moria.simons-clan.com):

> At the last installfest we had one helper run the following command:
>   dd if=/dev/hda2 of=/dev/hda bs=1 count=512
> 
>   The stated objective was to uninstall Lilo from the MBR....

First problem is that the "if" (input file) parameter is wrong:  The
(specified) first 512 bytes of hda2 constitute the boot sector of the
drive's second partition.  I believe the helper meant to say
"if=/dev/zero", which is virtual device furnishing an endless stream of
zeros, suitable for writing to something you want to null out.

Second problem is that he got the "bs" (block size) and count parameters
reverse:  He meant to type "bs=512 count=1".  While the end-result is
the same, performing a single-byte transfer operation, repeated 512
times is rather silly and inefficient.  What he intended was to copy 512
bytes of data, and do so a _single_ time.

Third of course is:

>   Unfortunately that is not a valid way to remove lilo from the MBR
> because two things share the first 512 bytes of a hard drive:
>   - The Master Boot Record.
>   - The Partition Table.

Quite so.  The first 446 bytes of a 512-byte IBM/Microsoft-style disk
label[1] is program space, where resides whatever program takes over
control from the Int13h BIOS boot routine, during startup.  The next 64
bytes following that is the four-entry partition table (16 bytes/entry).
Last comes two byte that normally go unused, but which NT Disk
Administrator uses for "disk signatures".

>   So that command replaced the MBR with something that was not Lilo
> and wiped out the partition table.

The intention was likely to overwrite (only) sector zero's program
space, with zeros, like this:

# dd if=/dev/zero of=/dev/hda bs=446 count=1

Most people would (_instead_ of the initital dd command, not as a
mechanism to recover from it) just reach for an MS-DOS boot floppy, boot
it, and then type "FDISK C: /MBR".  It's wise to re-submit that command
several times, since for mysterious reasons that operation sometimes
doesn't "take".  What the command does, when it works, is install into
the 446-byte program space Microsoft Corporation's unnamed first-stage
loader program, which is just smart enough to find the first primary
partition bearing the active (bootable) flag, and branch to its
sector-zero contents, whatever those might be.

I'm always amazed when people get all anxious over how to get
Microsoft's unnamed program back into the first-stage program space in
sector zero.  Usually, _avoiding_ having it land there is a bigger
problem.  People who prefer using other things there to control booting
are forever having to restore their preferred bootloaders, after
Microsoft OS installers do their usual trick of overwriting whatever is 
in that location, without bothering to consult the user.

>   If the partition table is trashed, a manual copy of the partition table
> or gpart can help to restore it.

In advance of any disaster such you've described, one can make a safety
copy of the entire sector-zero contents easily, like this:

# dd if=/dev/hda of=/root/sectorzero-2003-01-23.tar.gz bs=512 count=1

You could then archive the file for safekeeping onto a floppy:

# mcopy /root/sectorzero-2003-01-23.tar.gz bs=512 a:

> Over the last few years we have had similar things done a few other
> times at other installfests. 

The usual warnings about commands run with root authority apply double,
when the root user wields dd.

> The dos, NTFS and Linux / partition were all intact and could be 
> read from any Linux rescue CDs.  Unfortunately we either didn't have 
> a valid XP boot loader or _something_ was wrong with the XP filesystem
> which prevented it from booting.

Wild speculation: disk signature?

>   Over the next almost 12 hours a whole bunch of things were tried... 
> I'm not sure a complete list of things would be possible but here
> are some:
>   - fdisk /mbr from a Win 98 rescue floppy.

Again, all _this_ does is overwrite the first 446 bytes of sector zero
with the traditional MS-DOS first-stage boot-loader program.  It's
useless for recovering lost partition tables.

>   What ended up fixing the boot problem was a commercial partition 
> resizing program was told to add a few MB worth of space into the NTFS.
> as soon as that was done, XP booted and ran a filesystem check and
> found no errors.

Again, this would likely have set the "disk signature" in the last two
bytes of sector zero.  Might be what XP needed, or maybe not.  I don't
know.

My sympathies for the machine's owner.

[1] As opposed to a BSD disk label or a MacOS one, both of which Linux
can also contend with (among others).

-- 
Cheers,                   I once successfully declined a departmental retreat,
Rick Moen                 saying that on that day I planned instead to advance.
rick@linuxmafia.com                  -- Alan J. Rosenthal, in the Monastery