[nSLUG] kernel setup stack overlaps lilo

bdavidso at supercity.ns.ca bdavidso at supercity.ns.ca
Fri Mar 12 23:08:33 AST 2004


On Thu, 11 Mar 2004, Paul Boudreau wrote:

> Donald Teed wrote:
> >Redhat got into deep doo-doo with users back around 7.0
> >when the up2date utility would apply a new kernel and bust
> >the system.  I don't remember whether it was just a question
> >of rerunning lilo back then or not but that seems to be
> >all this required.  Is Slack trying to catch up to the
> >modern distros and making similar mistakes?  A big "tsk, tsk"
> >if there wasn't even a warning produced by the new package
> >management system.

I will be the first to admit (yes, Mr. Teed, I will admit it!) that this
is a weak point in the Slackware system.  Using "upgradepkg" or any of the
other tools which use it (or at least the ones I have tried, and there are
several) does not run lilo after upgrading the kernel, nor does it print a
big fat warning as it probablt ought to do.  The install script copies the
new kernel in /boot, along with the new System.map file and a config file,
and it updates some symlinks.  I presume that the "upgrade" part means it
first removes the previous kernel etc.  It is up to the user to run lilo.
This can be a "gotcha" for new users.

In fact, if my memory serves, the part of the Slackware install process
that configures and runs lilo has always been the weakest part of the
install and is generally not to be trusted.  Every time I have installed
Slackware, starting with the very first time I installed Linux (don't
remember the Slackware version, but the kernel was 1.2.3) I have edited
/etc/lilo.conf and re-rerun lilo to get it right.

OTOH, I can understand the thinking of the maintainers wrt to
"upgradepkg":  They don't know what boot loader you are using.  It is your
system, and it is up to you to know enough to admin it properly.  It seems
"obvious" that one would check one's lilo.conf and run lilo before
rebooting after upgrading the kernel, and reading the pre-requisite
installation documentation (I think it used to be called something like
"Installation and Getting Started") makes that pretty clear.

Of course <*cough cough*> I always compile my own kernels and run lilo
myself, so I haven't actually been bitten by this particular bug in
upgradepkg.  But keeping a bootable cdrom or boot floppy handy is always
wise in case of brain cramps. (Aside: Is it true that 2.6 kernels don't
support the old emergency boot method of having the kernel image on a
floppy?  I read somewhere that you need to use lilo or similar even for
boot floppies.)

More annoying is that upgrading a library doesn't (or at least doesn't
always) run ldconfig.  Upgrading libc, or even libz, and not running
ldconfig will break just about everything temporarily.  Again, running
ldconfig after upgrading a library seems "obvious" if you've done it a
time or two, but when your upgrade script starts spewing out linker errors
it is pretty unnerving.

Whatever one's feelings about Toyotas or Cadillacs or Ferraris or Yugos
(or, gawd help me, Anglias) I think that we all can agree that, compared
to a BSOD or "Your Windows installation is unstable, please run Setup",
having to run lilo or ldconfig to get everything right again is pretty OK.

Bill Davidson
bdavidso at supercity.ns.ca

More information about the nSLUG mailing list