[nSLUG] kernel setup stack overlaps lilo
bdavidso at supercity.ns.ca
bdavidso at supercity.ns.ca
Sat Mar 13 00:37:58 AST 2004
On Fri, 12 Mar 2004, Donald Teed wrote:
> Two bits of interest:
> 1. "make install" of 2.6 kernel will actually check to see if you have
> a lilo executable (on Gentoo we tend to have only one of these
> things), and ask if you want to run it. I'd imagine it would also
> check if you have grub but I have not tried it.
No, I don't think it does. But then , as P. Cordes said, with grub you
don't actually have to run grub to make the new image bootable -- and
although I have used grub on a RH9 system, I really need to read the
documentation on it and overcome my inertia and start using it.
OTOH, a quick look at the 2.6 kernel Makefiles shows that there is a
target "fdimage" that creates a boot floppy image. I haven't tried that,
either, but I should.
> 2. My 2.6 kernels are too big for a floppy. The smallest one (a bzImage)
> was 1.6 MB and my current one is 1.8 MB. But I never use boot floppies
> anymore. All machines have a CDROM and the mobos support
> booting from CDROM, so I boot up a Gentoo or Knoppix CD for
> any maintenance. Even for my software Raid 5 system, I can
> boot up the Gentoo Live CD, sftp to get a copy of my raidtab
> from another server, and start the raid up (support for installing
> to a software raid disk was one of the initial reasons I decided
> to try gentoo).
My current 2.6.3 kernel image (bzimage) is 903617 bytes, and it still
contains some stuff that I either don't need or should be in modules. Of
course, my home machine is pretty simple.
As to CDROM vs floppy, you are right that all new machines contain a
bootable CDROM. However, just yesterday I was working on an old machine
and wanted to boot from a CDROM to run some diagnostics, but that option
was not available in the BIOS, so sometimes a boot floppy can be very
handy. And sometimes a CDROM is hosed (although floppy drives are more
likely to be non-functioning in older machines than the CDROM drive). And
my new cheap laptop doesn't even have a floppy drive -- mind you, it's a
piece of shit and doesn't have a serial port either, and just died for the
As to RAID: I sympathize, having coerced a couple of Debian Woody systems
to boot from RAID1 partitions. To get that working I found the use of a
boot floppy to be invaluable, but a boot CDROM would also have worked.
With newer kernels and raidtools, I don't think you actually need
/etc/raidtab, the kernel groks the RAID configuration from the persistent
superblock, and you can build the array using raidtools without
referencing the raidtab file. A while ago a machine using a RAID1 mirror
had a problem on boot, and wouldn't recognize one of the drives. I wasn't
sure whether the problem was the drive or the controller, so I removed the
drive, stuck it in another machine (it was hdc in both machines), booted
the new machine from a knoppix CD, and used the raidtools to examine the
drive. The raid tools correctly told me everything I needed to know about
the partitions, the drive seemed OK, so I put it back after using
mdadm to mark it bad, the add it back to the array (details are fuzzy, but
see mdadm(8)). Check it out, and free yourself from raidtab!
> On Fri, 12 Mar 2004 bdavidso at supercity.ns.ca wrote:
> > Hi:
> > 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
> > _______________________________________________
> > nSLUG mailing list
> > nSLUG at nslug.ns.ca
> > http://nslug.ns.ca/cgi-bin/mailman/listinfo/nslug
> nSLUG mailing list
> nSLUG at nslug.ns.ca
bdavidso at supercity.ns.ca
More information about the nSLUG