Bug 6907 - Botched kernel upgrade
Botched kernel upgrade
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
6.0
All Linux
medium Severity high
: ---
: ---
Assigned To: Michael K. Johnson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-11-10 21:53 EST by whitis
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-02-06 00:32:30 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description whitis 1999-11-10 21:53:52 EST
Installing redhat 6.0 and then upgrading the kernel to
2.2.5-22smp screwed up /etc/lilo.conf making the system
unbootable.  Worse the upgrade failed to make a new
initrd, deleted the old kernel, and deleted the old
modules.  This left the system not only unbootable but
incompatible with the rescue disks and the install disks.

Redhat has a very bad habit of deleting old stuff which
you still need when you do an upgrade.  And they botched the
upgrade.
Any competent system manager always keeps at least one old
kernel around
to boot from when they do an upgrade.  Also, it is good to
keep the
loadable kernel modules from at least the current kernel
version
and the one which corresponds to the prior kernel and the
ones
which correspond to the version of the kernel on the install
disk (if
you have to boot from that) and rescue disk.

Kernel upgrades should also rewrite lilo.conf so that
the old kernel becomes, say, oldlinux and the new one
becomes linux and the default.  Actually, the best
way to do this is always make a boot name be of the form
linux-X.Y.Zpdq and have linux be an alias for the most
recent ones.  Never delete an old kernel, initrd, or modules
without explicit user choice.  This is could be as simple as
appending the new configuration to /etc/lilo.conf and then
running it through
   sed -e 's/alias=linux//'.
A little more work is needed to convert any lilo.conf files
created using your oldconvention, such as
   sed -e 's/label=linux/label=linux-unknown-version/
If the system is availible, sed won't be availible but you
can safely skip this step and just create a decent lilo.conf
by the new convention.

# tried to reboot system.   reboot failed misserably
"loading linux...."
# can't use the custom boot floppy because redhat install
failed
# when it tried to create it.
# tried rescue disk.  rescue disk fails even more miserably.
# inserted redhat 6.0 boot disk
# boot: linux root=/dev/hda1 initrd=
# actually boots, but modules are screwed up and not
networking
# because modules are screwed up.  The initrd= trick
# is needed to keep the install program from running but
# you lose all the handy modules (and it won't work for
# scsi devices.
# The problem seems to be that /etc/lilo.conf was for
2.2.5-15
# but the kernel has been upgraded to 2.2.5-22smp and
# redhat, YET AGAIN, deletes stuff you still need when it
# does an upgrade.
# Okay, we will rebuild lilo.conf and rerun lilo
# guess what, there is no initrd that matches any version of
# the kernel that hasn't been deleted.  Well, ok, we just
# run mkinitrd, right?  wrong!  mkinitrd won't run because
# it needs a loopback device which won't work because
modules
# are screwed up.
# Blood pressure reaching dangerous levels
#
# edited lilo.conf to use /boot/vmlinuz-2.2.5-22smp with
# NO initrd, ran lilo and rebooted.
emacs /etc/lilo.conf
reboot
# now we build the initrd now that we are running a kernel
# which can run the modules which stillexist on the system.
mkinitrd /boot/initrd-2.2.5-22smp.img 2.2.5-22
emacs /etc/lilo.conf
lilo
reboot
Comment 1 Cristian Gafton 2000-01-04 17:20:59 EST
Assigned to dledford
Comment 2 Bill Nottingham 2000-02-06 00:32:59 EST
This is how rpm's -U upgrade works; it removes the old package.
You're correct in that you normally don't want to use
this for kernels; see the Kernel-Upgrade-HOWTO.

Note You need to log in before you can comment on or make changes to this bug.