problems with lilo

Bill's LFS Login lfsbill at
Thu Jan 16 04:08:13 PST 2003

On Thu, 16 Jan 2003, steven stimpson wrote:

> hello and thanks for reading this. i am trying to install and use lilo but
> when i use lilo i get the error "block move error 0x02"
> anyone heard of this?

Nope. But if it is at boot time, /usr/src/lilo-22.3.3/README says

    Disk error codes ....

    0x02   "Address mark not found". This usually indicates a media
    problem. Try again several times.

I presume the "try again" advice is predicated upon the fact that recent
IDE interfaces are supposed to detect and and assign alternate blocks to
bad sectors. But there are problems that follow if the bad block occurs
when reading. An address mark not found (sector marker missing) might
ultimately result in the "block move..." error?

In second.S (assem code) is

    msg_bm: .byte   10
    .ascii  "Block move error 0x"
    .byte   0


    badmov: pop     bx      ! discard GDT
    push    ax              ! save the error code
    mov     bx,#msg_bm      ! tell the user ...
    jmp     reset           ! (standard
    procedure calls say & bout)

I didn't feel like tracking all the way through, but it looks strongly
like your media error.

If the error is in the $LFS/boot/<kernel-image> area, and repeated
attempts don't get around it, you might try renaming the directory,
making a new /boot directory and rebuilding the kernel stuff. What this
does is keep the "bad sector" in use so it will not be used again and
makes a new set of boot stuff in a different area of the HD.

Alternately, in the boot directory, for each file, do something like

    dd if=<filename> of=/dev/null

If the bad sector is in one of those files, dd should croak. Then rename
that bad file (again, to keep the bad sector from being released and
reused) and recreate the bad component.

As a last ditch effort, if you can afford to destroy the HD contents,
some low-level formatting software (on *older* HDs) may rewrite the
sector markers and/or flag the bad sector and assign an alternate track.

Caution is advised if you are not ... "adventurous" and fairly

BTW, whenever I mke2fs, I tell it to do the bad block mapping. This
(potentially) IDs and reassigns bad blocks *before* they have any
valuable contents.

Keep in mind that as media ages, they may occasionally develop some new
bad blocks. If it is only a few, and infrequently, the media may be
useful for many more years. But if it is a *bunch* and frequent, time to
bail and get a new HD.

A periodic

    dd if=/dev/hdX of=/dev/null bs=10240

can help. Maybe once a month or so?

> thanks
> steven

Bill Maltby
lfsbill at

Unsubscribe: send email to listar at
and put 'unsubscribe lfs-support' in the subject header of the message

More information about the lfs-support mailing list