After a standard security/stability upgrade of lenny I witnessed the same
problem as Xavier, namely that lilo would stop with:
liloLoading LinuxEBDA is big; kernel setup stack overlaps LILO second
stage
(I am not sure whether there were any points after "lilo". I think not,
but if there were, then there were only very few - i.e. not a line or
half a line or such)
What I did exactly was upgrading from linux-image-2.6.26-2-686
2.6.26-19lenny1 to 2.6.26-21 inside aptitude and *at the same time*
deinstalling the old linux-image-2.6.18-6-686 2.6.18.dfsg.1-26etch1.
Aptitude did what I told it to do and did not complain, and ended without
error. The only thing indicating a problem were the following lines (from
/var/log/apt.log - since I did not catch them during the down/upgrade,
and translated from czech, since that's how the locale is set):
Preparing to replace linux-image-2.6.26-2-686 2.6.26-19lenny1 (with
.../linux-image-2.6.26-2-686_2.6.26-21_i386.deb) ...
The directory /lib/modules/2.6.26-2-686 still exists. Continuing as
directed.
Done.
Unpacking replacement linux-image-2.6.26-2-686 ...
...
Configuring package linux-image-2.6.26-2-686 (2.6.26-21) ...
Running depmod.
Running mkinitramfs-kpkg.
Not updating initrd symbolic links since we are being updated/reinstalled
(2.6.26-19lenny1 was configured last, according to dpkg)
Not updating image symbolic links since we are being updated/reinstalled
(2.6.26-19lenny1 was configured last, according to dpkg)
...
Removing package linux-image-2.6.18-6-686
The link /vmlinuz.old is a damaged link
Removing symbolic link vmlinuz.old
Unless you used the optional flag in lilo,
you may need to re-run your boot loader[lilo]
The link /initrd.img.ol is a damaged link
Removing symbolic link initrd.img.ol
Unless you used the optional flag in lilo,
you may need to re-run your boot loader[lilo]
Removing configuration directory of package linux-image-2.6.18-6-686 ...
...
And that's it, no errors anywhere.
After upgrading I rebooted and ended up with the lilo error reported by
Xavier and repeated above.
Strangely enough (!!!) I could *still* boot into the removed (!) 2.6.18-6
kernel and allthough the bootprocess complained about a lot of missing
kernel modules (or modules.dep ? I don't know, I can't find it anywhere
in the logs), but somehow miraculously (!) it was able to install the
networking stack... Then, from the shell I issued:
# lilo
Fatal: open /boot/vmlinuz-2.6.18-6-686
After that I reinstalled the old linux-image-2.6.18-6-686
2.6.18.dfsg.1-26etch1 package and rebooted.
Now everything was fine and I could boot into the new 2.6.26 kernel
without lilo complaining.
Running lilo from the command line would show me the bootable kernels:
# lilo
Added 2618-6-hda5
Added 2626-hda5
Added windows
# ls -l /
[...]
initrd.img -> boot/initrd.img-2.6.18-6-686
initrd.img.old -> boot/initrd.img-2.6.26-2-686
[...]
vmlinuz -> boot/vmlinuz-2.6.18-6-686
vmlinuz.old -> boot/vmlinuz-2.6.26-2-686
It seems that even if lilo.conf is half broken - i.e. it's missing some of
the kernels, the install process will nevertheless install the new kernel
but somehow break halfway through the process and not properly install the
new kernel.
*t
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
