cant get lilo to work

Bill's LFS Login lfsbill at
Thu Jan 16 12:10:44 PST 2003

On Thu, 16 Jan 2003, dc_u wrote:

A lot of folks *luv* grub and the LFS book will be replacing lilo with
that. From what the grubbers say, they *may* be able to get you going
faster than pursueing a lilo solution. According to them, grub "walks on
water" while lilo "passes water in emergencies".  :-))

Just for safety, I suggest, in Windows, formatting a boot floppy (it
used to be 'format /s a:') and copying the fdisk program to it. Test and
make sure you can boot from the floppy and the fdisk will let you look
at the disk. Then the undocumented (at least it used to be undocumented
- M$ has surely documented it by now) command line parameter


can recover the master boot record for you.

Hey, while your there, write down the disk geometry that fdisk shows. If
it differs from what we saw in sfdisk, that may be a big clue. But it
may have been changed when you installed lilo.

> i did read the README. it says that i should include " disk= heads= sectors=
> "
> in my lilo.conf file and it didn't help. i ran into another problem, in the
> README.disk file
> my problem gets described nicely, but when i tried to make a diagnostics
> disk i found out that my
> stiffy drive doesnt work in my Mandrake distro. when i try to mount my
> floppy i get an device
> unknown message. i attached the output from sfdisk -l /dev/hda as well as my
> lilo.conf file

Something tells me this one is going to be tough. A few questions make
me worry about this. I'll be rambling here a bit - trying to fish for
possible causes and "unseen" influences. Also, it may spark some
thoughts in your mind that yield the answer.

First, why have you always used a floppy to boot your Mandrake? Is it
because you weren't able to boot it by activating the hda5 partition or
the ez-disk wasn't able to boot that partition? If so, that may be a
clue that the ez-disk is doing what I think - I think it is altering the
HD geometry before calling the OS loader. Or maybe the ez-disk just
looks at the boot flag and that is always on hda1?

I only ask in case it offers some clues as to why you are getting this

Have you been able to boot windows by selecting it from the lilo menu at
boot time? This answer may give us a clue.

In a previous post, I asked

    BTW, if you made a change to lilo.conf, did you remember to run lilo
    again to install the new boot information?

We need to know - after updating the lilo.conf, did you run lilo? If you
did not, and you had made your new kernel, copied your and
new kernel image over and so on, then lilo will not be able to find the
right stuff. It makes a new when you do this and that file
gives it needed information at boot time. If anything was created new,
moved around or copied, the may not be valid anymore.

Did you run lilo after any updates, copies or moves of /boot stuff?

I see nothing obviously wrong with your lilo.conf. *If* the geometry at
*boot* time is the same as the sfdisk output shows, I don't *think* you
need the


because the sfdisk output shows the same geometry. You did not include
the 'cylinders='. Any reason for that? Regardless, when
you type in 'lilo' before trying to reboot, lilo will see this same
geometry. What in the README file indicated you needed this stuff? I
know for many older versions, this would be useful, but the new lilo is
not subject to 1024 cyl limits and will get the geometry the kernel has
determined at the time lilo is run from the Linux system. Maybe ez-disk
is changing the geometry and you are trying to correct it? This will not
do it because this only changes what lilo sees when you run 'lilo' from
the Linux system, not what it sees at boot time.

>From the lilo source directory, doc/user.tex:

    If incorrect information is returned, booting may fail in several
    ways, typically with a partial ``LILO'' banner message. In this
    document, that is called a ``geometry mismatch''.

This sounds to me like it might be that. From that same document:

    The disk geometry parameters can be obtained by booting MS-DOS and
    running the program \path{DPARAM.COM} with the hexadecimal BIOS code
    of the drive as its argument, e.g. \verb"dparam 0x80" for the first
    hard disk. It displays the number of sectors per track, the number
    of heads per cylinder and the number of cylinders. All three numbers
    are one-based.

The '\path{DPARAM.COM}' is a .tex symbol, not the real name of the
program. The '\verb"dparam 0x80"' is probably really 'dparam 0x80'. But
since it's M$, I don't know. I *suspect* that if ez-disk is changing the
geometry, the dos/win will use them unchanged and we might see
something different than what the sfdisk and/or the dos fdisk showed.

Anyway, *if* there is a geomentry mismatch, it looks like it would
have to be a boot time, *not* lilo install boot blocks time (that
happens when you type in 'lilo' before you try to reboot). Of course you
only need to type in lilo when you move things around or make a new
kernel and so on.

When you boot, does your ez-disk stuff show, or can you get it to tell
you, what geometry it is using/passing to the boot loader(s)? Those
things typically do the "lying about the geometry" for you and I wonder
if it is changing the geometry before lilo is invoked. If it has a
"diagnostic" or "verbose" mode, enable it to get as much insight as
possible to what it is doing and what parameters it passes.

Can you "disable" the ez-disk and see what happens? Since you

Have you tried executing lilo -v -v -v when you have booted into your
Mandrake partition? After copying the into /boot and the lfs
kernel into the Mandrake /boot, your should do this and see if all looks
as you expect. Redirect stdout and stderr to a file, like

    lilo -v -v -v >/tmp/lilo.out 2>&1

and then you can examine that with an editor or attach to another post
to this list.

BTW, if that works and you have put lilo on the MBR, you
should be able to boot your Mandrake system without the floppy.

Hmmm. Have you tried making the hda1 *inactive* (remove the "activate"
or "boot" flag)? I know there are cases where this interacts with boot
activities. Make sure you have a DOS floppy that will boot and has fdisk
so you can turn it back on. If you are then able to boot Mandrake or
LFS, we have found the problem.

Conversly, have your tried "activating" the hda5 or hda7 partitions?

That's all I can think of at the moment. Any dual-boot guys out there
with some old BIOS experience that might chime in? Espcially folks using
specialized BIOS programs?

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