cant get lilo to work

dc_u dc_u at
Thu Jan 16 12:51:35 PST 2003

Yes, i did run /sbin/lilo after making changes. The job of ez-bios is to
enable windows to use my entire disk, so i think it may chache the disk
I did try making hda1 inactive and then making the extended partition active
and hda5. I only got the message: 'no operating system' when i tried to
Perhaps i should try grub, i guess i can find info on that in the lfs hints.
I do have a backup of my MBR on a disk. It's the disk i installed ez/bios
with. It's a utility called maxblast. It's for maxtor harddrives that is
used with an old bios. the strange thing is that when i run the maxblast
program it tells me that the harddrives actual heads are ony 16 while
ez-bios says it 255 at boot time. the geom ez gives at boot time is:
255heads 63sectors and 4982cyllinders.
The reason i'm using a floppy is because i've never succeeded in getting
lilo to run. I had to use the distro cd and boot a rescue kernel and then
make a bootdisk.
Ill try to uninstall ez and see what happens.
Thanks for your help so far!

----- Original Message -----
From: Bill's LFS Login <lfsbill at>
To: <lfs-support at>
Sent: Thursday, January 16, 2003 10:10 PM
Subject: Re: cant get lilo to work

> On Thu, 16 Jan 2003, dc_u wrote:
> <Disclaimer>
> 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".  :-))
> </Disclaimer>
> 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
>    /mbr
> 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=
> > "
> > in my lilo.conf file and it didn't help. i ran into another problem, in
> > 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
> failure.
> 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
>     disk=/dev/hda
>         heads=255
> sectors=63
> 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

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