cant get lilo to work

dc_u dc_u at webonline.co.za
Fri Jan 17 13:26:53 PST 2003


I unistalled ez-bios and then lilo started fine. lfs booted fine!! When i
booted into windows it worked fine also, so i see no need to keep ez if
windows works fine anyway.
Thank you very much for your help!!


----- Original Message -----
From: dc_u <dc_u at webonline.co.za>
To: <lfs-support at linuxfromscratch.org>
Sent: Thursday, January 16, 2003 10:51 PM
Subject: Re: cant get lilo to work


> 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
> geometry.
> 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
> boot.
> 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!
> dc
>
>
> ----- Original Message -----
> From: Bill's LFS Login <lfsbill at wlmcs.com>
> To: <lfs-support at linuxfromscratch.org>
> 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=
> 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
> > 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 System.map and
> > new kernel image over and so on, then lilo will not be able to find the
> > right stuff. It makes a new boot.map when you do this and that file
> > gives it needed information at boot time. If anything was created new,
> > moved around or copied, the boot.map 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 System.map 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 wlmcs.com
> >
> >
> > --
> > Unsubscribe: send email to listar at linuxfromscratch.org
> > and put 'unsubscribe lfs-support' in the subject header of the message
> >
>
>
> --
> Unsubscribe: send email to listar at linuxfromscratch.org
> and put 'unsubscribe lfs-support' in the subject header of the message
>


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



More information about the lfs-support mailing list