Re: hdd defragmentation / e2defrag

[Daniel Pittman <daniel@rimspace.net>]

On 26 May 2004, Stephane Provost wrote:
> I also want to defrag my drive. When I ran e2defrag, it said the drive
> should be unmounted (ok easy, I guess I'll need a bootdisk, I want to defrag
> /dev/hda0) and also I'll have to run the bootloader configuration tool
> because the image may have moved.
>
> What does the latter part mean ? 

I see that no one has yet answered this part of your question.

> I thought the kernel image was just a file and the bootloader lived in
> the MBR no matter what ? 

...er, no. :)

> What is the magical instruction to reconfigure lilo ? I don't want to
> screw the system up and not be able to reboot (gasp).

Good call, and this may well do that.

So, the MBR is a single 512 byte block of data, of which around 420
bytes can be executable code.  That *isn't* enough to implement a
meaningful boot loader.[1]

So, both lilo and grub use a "second stage" boot loader of some sort.
The tiny code in the MBR loads the second stage, and then the second
stage loads the kernel, and then you have a running system.

both lilo and grub need to know *where* to load that second stage loader
from, and both operate by storing the block numbers on the hard disk
somewhere in that MBR, and loading them blindly at boot time.[2]

grub likes to install the second stage boot loader in the "spare"
sectors between the MBR block and the start of the first partition,
since that is not often used.[3]

lilo, on the other hand, simply stores the location of the second stage
loader in your filesystem...


So, if the defrag utility moves that second stage loader, lilo will fail
to load it, leading to a wonderful 'LI'[4] error message at boot time.

Also, for lilo (but not grub, since it reads actual filesystems), if the
defrag tool changes the layout of your kernel image, booting will fail
for exactly the same reason - lilo uses absolute block locations to load
the kernel as well.


I hope that is clear about *why* you need to do this.

Actually doing it is pretty trivial; this will do it:

] lilo

If you pass enough '-v' options you can see the steps, including exactly
which absolute disk blocks it uses. :)

      Daniel


Footnotes: 
[1]  Well, I once saw something that claimed to do real FS access of an
     ext2 partition in that space, written in assembly language, but I
     never tried it. Anyway...

[2]  grub also has a "stage 1.5" loader concept, in which the MBR loads
     a "stage 1.5" loader that *can* read a filesystem, and then the
     "stage 1.5" loader loads the actual boot loader code...  but
     functionally the "stage 1.5" bit is identical.

[3]  Old fashioned BIOS work-around tools that allowed access to > 8GB
     disks tended to use that space for their boot-time code, for much
     the same reason.

[4]  IIRC, 'LI' is "failed to execute second stage loader"

-- 
I was born when she kissed me.
I died when she left me.
I lived a few weeks while she loved me.
        -- Dixon Steele (Humphrey Bogart), _In a lonely place_