Booting error lilo-22.5.8, linux-2.4.23, LFS-5.0

Andrew Calkin calkin at ieee.org
Sun Nov 30 22:19:12 PST 2003


On Mon, Dec 01, 2003 at 08:07:30AM +0200, Leho wrote:
> Ken Moffat wrote:
> > On Sun, 30 Nov 2003, Leho wrote:
> > 
> > 
> >>Leho wrote:
> >>
> >>>Loading LFS.....................
> >>>BIOS data check successful
> >>>Uncompressing Linux...
> >>>
> >>>Invalid compressed format (err=2)
> >>>
> >>>--System halted
> >>>
> >>>______
> >>>
> >>>Weird. I used Lilo, nasm-0.98.38, modutils-2.4.26, bin86-0.16.14
> >>>
> >>>compiled nasm as blfs-cvs and bin86 as LFS4.1
> >>
> >>I had working lfs with linux-2.4.22 and a needed updates in kernel
> >>because of networking in blfs and I thought that it is good idea to
> >>achieve two goals with one motion. New kernel and networking support.
> >>
> >>Ok I figured that out. I did not run "lilo -v" after new kernel build.
> >>Is it necessary? Why does that LFS-4.1 contain a note about it if it is?
> >>Or am I blind. I think it is necessary. I read it form
> >>"linux-2.6.0-test11 README"
> >>
> >>quote:
> >>To use the new kernel, save a copy of the old image and copy the new
> >>image over the old one.  Then, you MUST RERUN LILO to update the loading
> >>map!! If you don't, you won't be able to boot the new kernel image.
> >>
> >>
> >>
> > 
> > 
> >  I don't quite understand what you're asking, but since you're another
> > user of the one true x86 bootloader (TM) I'll attempt to answer.
> > 
> >  Lilo stores a list of which blocks in the filesystem contain each
> > kernel it knows about.  The normal problem is that somebody recompiles a
> > kernel (keeping the name of the boot file the same) and doesn't rerun
> > lilo - the odds are that the filesystem will use different blocks to
> > store the new file.  Maybe your kernel is just called /boot/vmlinuz-lfs
> > and you've overwritten the old one ?  It's always a good idea to give
> > kernels a name including the version, and any extraversion you've added
> > (e.g. -1, -2, ... as you try different options - adding the extraversion
> > also puts modules into separate directories, which can be useful.
> > 
> >  If you're asking why version 5.0 of the lfs book doesn't mention this,
> > it's because it went to grub.  One of the advantages of grub is that it
> > can read the filesystem when it boots, so it can access the file by
> > name.
> > 
> > HTH,
> > 
> > Ken
> 
> To make things more clear:
> 
> I build a first kernel in lfs. I copy the bzImage to /boot and 
> System.map also.
> 
> When I build a new kernel and wanna keep my old one also and make new 
> item in the lilo prompt menu. I can copy the bzImage to another name 
> like lfskernel but the Sysem.map remains with the same name. I overwrite 
>   the old one. Is is ok?
> 
> The problem was that, I built an new kernel for lfs and installed it but 
> did not  run lilo -v before reboot and then it did not booted into lfs 
> with new kernel and said the error in the first message. The I read from 
> the "linux2.6.0 README" that quote in the next message. Then I took an 
> action and reruned "lilo -v" in the host system and wholaa LFS boots up.
After making a new kernel, if you want to keep your old kernel then
don't copy over the original (i.e. either rename the old one or have a
different name for the new one), and update the lilo.conf file
appropriately so that the menu tags point to the correct file. I think
the System.map file can be used for either kernel (I have not had any
problems when overwriting old System.map files at least), however
whenever I change anything in either /boot directory or lilo.conf, I
_always_ run lilo to update the boot loader. I think the -v switch
just increases verbosity. In fact, I run lilo -v followed by lilo -q
(query), just to make sure that everything seems ok, before rebooting.
If any error is given, I sort it out and then check again until no
error message is given.

//Andrew



More information about the lfs-support mailing list