[3207] in Release_7.7_team
possible bug in ALS SMP 9.0.25 update script? (fwd)
daemon@ATHENA.MIT.EDU (Stefan Stasik)
Thu Mar 28 14:21:35 2002
Date: Thu, 28 Mar 2002 14:21:32 -0500 (EST)
From: Stefan Stasik <stasik@MIT.EDU>
To: <release-team@mit.edu>
cc: Stefan at Athena <stasik@mit.edu>
Message-ID: <Pine.GSO.4.30L.0203281250220.15969-100000@nerd-xing.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hello:
I reported this on the linux-help@mit.edu mailing list yesterday, and
Camilla Fox said that I should post it here as a bug.
Hopefully this will be fixed before the next Athena-Linux release.
Thank you!
- Stefan Stasik
Stefan Stasik - stasik@mit.edu - (617) 253-2842 - E25-147G
System Manager - MIT Whitaker College Computing Facility
---------- Forwarded message ----------
Date: Wed, 27 Mar 2002 17:11:03 -0500 (EST)
From: Stefan Stasik <stasik@MIT.EDU>
To: linux-help@MIT.EDU
Cc: Stefan at Athena <stasik@MIT.EDU>
Subject: possible bug in ALS SMP 9.0.25 update script?
Hello:
I am reporting what I believe is a bug in the Athena-Linux auto-update
script on SMP systems.
I had two separate machines running, that after the 9.0.24 >> 9.0.25
update, would not boot on the 'linuxsmp' stanza in /etc/lilo.conf.
(Kernel Panic)
After booting the machines fine in the 'linux' (single processor
kernel/mode), this is how I found the two stanza's in /etc/lilo.conf:
-=-=-=-
boot=/dev/hda
map=/boot/map
install=/boot/boot.b
prompt
timeout=50
default=linuxsmp
image=/boot/vmlinuz-2.4.9-31smp
label=linuxsmp
initrd=/boot/initrd-2.4.9-31.img
read-only
root=/dev/hda7
image=/boot/vmlinuz-2.4.9-31
label=linux
initrd=/boot/initrd-2.4.9-31.img
read-only
root=/dev/hda7
bash-2.04#
-=-=-=-
The problem here is that the 'initrd' line in the file should specify
the ..smp.img file, not the regular ...img file.
I changed the one line in the linuxsmp stanza to the following:
initrd=/boot/initrd-2.4.9-31smp.img
re-ran 'lilo -v -v -v', and re-booted the system, and machine then came up
fine in linuxsmp.
This happened on 2 different machines that I manage.
Is it safe to assume this is a bug in the kernel updating process?
Thanks,
- Stefan Stasik
Stefan Stasik - stasik@mit.edu - (617) 253-2842 - E25-147G
System Manager - MIT Whitaker College Computing Facility
