Red Hat Bugzilla – Bug 19558
Attempt to upgrade existing RH6.0 on SCSI fails in ananconda
Last modified: 2007-04-18 12:29:27 EDT
Hardware: Dell Optiplex GX1p/P II; Adaptec 3940 base drive, EIDE 2ndary
Existing pristine RH 6.0 installed on SCSI drive - boots from partition
sda2. RH 6.2 Distribution in partition on hda controller - all files
RedHat distribution on /dev/hda9 - and found.
Using the boot-20000407.img along with the update-disk-20000419.img:
Boots correctly, identifies the correct Adaptec Controller driver, aic7xxx.
On boot requested: linux updates
Request expert install - upgrade
Although the SCSI drive is found and the root partition is correctly
designated as sda2,
Anaconda reports " Can't mount sda2 - Block device required"
Traceback (innermost last):
File "/usr/bin/anaconda/read", line 342 in ?
intf.run(todo, test - test)
File "/tmp/updcus/todo.pg", line 719 in upgrade FindPages
File "/usr/lib/anaconda/fstab.pg", line 464, in mountFilesystem
raise SystemError, (errorno,msg)
System Error: (15,'Blockdevice Required')
This is preventing me from doing a pre-purchase test of RH6.2 to see
whether it has any conflicts with VMWare. The entire distribution is
unusable if it can't be installed.
A check of the RH 6.0 SCSI partition which was to be upgraded shows that the
entire root partition lies below the 1024 cyl boundary limit.
Is ananconda trying to create yet another /boot partition (which would be beyond
the limit)? Currently in RH 6.0, /boot is part of the /dev/sda2 root parition.
Since you are doing an upgrade it is not trying to allocate any new partitions.
What kind of messages do you see on virtual console 3 (hit cntl-alt-F3)?
It seems that your SCSI driver is not loading properly for some reason.
I subsequently made two new attempts to upgrade:
I. linux updates expert
anaconda immediatly prompts for a drivers disk.
if I put the RH6.0 aic7xxx.o (and ethernet drivers) on an ext2 floppy
anaconda complains that the driver disk is the improper release.
if I ignore the driver disk, it proceeds to the point where I am
given a null list of SCSI drivers to choose from.
The virtual console (3) reports:
load 9 keymaps
going to insmod fat.o (path is NULL)
going to insmod vfat.o (path is NULL)
partition /dev/hda9 selected (this is the correct distrib partition)
mounting device hda9 as ext2 (this is correct - it is a Linux part)
created 1 inode
downloading 4194304 bytes
recursive copying /tmp/update-disk/lost+found
recursive copying /tmp/update-disk/1w
going to insmod raidx.0 (path is NULL)
[ Installation terminates]
On tty2, /proc/pci shows Adaptec AHA-294002 irq 11
II Use graphical install as default
Here, it actually finds and configures the aic7xx driver.
found suggestion of aic7xxx
found aic7xxx driver
found devices justProbe is 0
going to insmod aic7xxx.o (path is NULL)
[probes buses and finds both ethernet cards]
going to insmod 3c59x.o (path is NULL)
going to insmod rtl8139.o (path is NULL)
...raid 0 .. (path is NULL)
The other screens (F4) shows that the Adaptec controller was detected and
downloaded (I included all this info from a Win Netscape session viewing
the actual screens but it crashed when I attempted to submit it - I will
reproduce it again if necessary).
A review of previous bug reports there may be a relationship between this bug and 10388, 10645, and 11093. My machine uses both SCSI and EIDE
(onboard) controllers. Lilo is *not* in the MBR of the SCSI but rather in the RH 6.0 boot partition, /dev/sda2. Furthermore, I use Boot Magic operating
from the MBR of the EIDE (/dev/hda) to permit boot of several operating systems. As far as Boot Magic is concerned, the EIDE drive is drive 1 and the
SCSI is drive 2.
This configuration has presented no problems whatever using RH 6.0, SCO Unixware 7, SCO OpenServer 5.0, or the Win '98 parititions.
Additionally, the update attempt shows clearly on the DMESG screen that the Adaptec Controller is recognized, and downloaded prior to the error.
Since this problem was completely absent in RH 6.0, I believe it should be treated as a bug because it prevents individuals from upgrading.
In light of the previous bug reports, I will now try to have the BIOS designate the SCSI as drive 1, but since I must boot the install from the floppy, I don't
believe this will have any effect. I will report back here success/failure in using this procedure.
Created attachment 5159 [details]
Dmesg, syslog, and Directory Tree for aborted RH6.2 Update
Created attachment 5160 [details]
Dmesg, syslog, Directory Tree for aborted RH6.2 expert mode update attempt
Two attempts to upgrade RH 6.0 to RH 6.2 were run - in each case output from the
install screens were copied to text files on a mounted floppy:
In text expert updates upgrae mode, all pci devices including the Adaptac SCSI
controller were detected but not initiated - pull-down screen for SCSI contained
NULL list of devices while the pull-down list for the Ethernet Adapters is
In graphic mode (upgrade), anaconda detected and attempted to initiate the SCSI
controller and the two Ethernet controllers (as opposed to the text mode) but
only succeeded in creating mod entries for the Ethernet cards:
alias: eth0 3c59x
alias: eth1 rtl8139
alias: parport_lowlevel parport_pci
There should be an entry:
alias scsi_hostadapter: aic7xxx
after the SCSI Adaptor is configured.
It appears that perhaps the install kernel does *not* have support for this
device and no aic7xx modules appear anywhere in the install distribution.
The syslog file resulting from the expert vs the graphics install clearly show
that the text mode completely ignores the SCSI adaptor while the graphics modes
tries to initiate it:
Difference in syslog < == expert text mode ? == graphic mode
(references to fd0 reflect my manual mounting of a floppy to record data)
Note specifically that the expert update mode shows no reference to the Adaptec
SCSI adaptor while the graphics mode does:
< <4>Detected 448881638 Hz processor.
> <4>Detected 448880324 Hz processor.
< <4> p5_mmx : 1105.281 MB/sec
> <4> p5_mmx : 1106.805 MB/sec
< <4>using fastest function: p5_mmx (1105.281 MB/sec)
> <4>using fastest function: p5_mmx (1106.805 MB/sec)
< <7>VFS: Disk change detected on device fd(2,0)
> <6>(scsi0) <Adaptec AHA-294X Ultra2 SCSI host adapter> found at PCI 2/10/0
> <6>(scsi0) Wide Channel, SCSI ID=7, 32/255 SCBs
> <6>(scsi0) Downloading sequencer code... 396 instructions downloaded
> <4>enable_irq() unbalanced from d88128e2
> <4>scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.1.28/3.2.4
> <4> <Adaptec AHA-294X Ultra2 SCSI host adapter>
> <4>scsi : 1 host.
< <7>VFS: Disk change detected on device fd(2,0)
> <6>rtl8139.c:v1.07 5/6/99 Donald Becker
> <6>eth1: SMC1211TX EZCard 10/100 (RealTek RTL8139) at 0xd800, IRQ 10,
> <7>VFS: Disk change detected on device fd(2,0)
It is also noted that the install script detects both the SCSI 6.0 root
directory on sda2 and a backup of the 6.0 root directory on hda8 and creates
/dev entries for each in /tmp (i.e. /tmp/sda2 and /tmp/hda8) but neither is
mountable - there is no /tmp dev entry for sda or hda.
It is remarkable that the script can detect the RH6.0 root partition on device
/sda2 but not mount either it or the /hda8 partitions.
This script is seriously flawed in so many places, it is impossible to begin to
list them all. It looks for files in directories and cannot find them because
they actually exist in other directories; it either initializes or doesn't
initialize the Adaptec SCSI adaptor according to whether one asks for text or
graphics mode, it does not contain modules for anything (the modules directories
are unpopulated), it creates untraceable links in it's directory tree, are among
a few of the blatant errors reported.
The entire install sessions with syslogs for graphics and expert upgrade
attempts including the directory trees are attached as the files: grafmod.txt
and expertmod.txt respectively.
It appears that the ananconda script has been hacked so often that it no longer
is even testable - I strongly recommend that a patch be issued and the entire
script be rewritten to respect standard Unix directory rules (e.g. why are
normal dev entries put in /tmp rather than in /dev/ in the memory disk). It
would be much easier to maintain it it's dirctory tree mirrored the actual tree
created for /.
Why has there been no action on this report? The supplementary information has
long ago without response.
It has been my experience that problems arise with booting EIDE/SCSI systems if
the boot partition is not on the first IDE drive. There are so many
combinations of behavior of SCSI BIOSes and system BIOSes that it is not
possible to handle them all.
That said, it looks like there is a problem related to anaconda's behavior on
your system. It would help to know the original partitions on the 6.0 system,
as well as its /etc/fstab file. Clearly for some reason references are being
made to /dev/sda2 and w/o the Adaptec driver being loaded this will certainly
Sorry for the delay in handling this issue, I will try to make up for it by
helping you resolve this issue now.
I'm not sure my previous documentation indicates that the Adaptec Driver is not
being loaded - the graphics mode output suggests it is (see previous discussion
and included files). The reason that /dev/sda2 is referenced is simply that it
is, in fact, the only bootable RH 6.0 root partition on the machine on either
drive - this is absolutely correct.
It's been awhile since I made several tries at the upgrade.
The *only* boot/root partition for Linux RH 6.0 is on the SCSI controller
primary partition /dev/sda2. There is a bootable Windows '98 on /dev/sda1 but
the /root partition that Linux lies in it's entirety well below the 8G 'limit'.
The LILO resides only in the /dev/sda2 partition - Partition Magic is used to
switch between the two.
This is a dual-boot system and the original Windows '98 partition existed
*before* the installation of RH 6.0 which was done without any problem from the
CD ROM to the SCSI Partition. There was no confusion between the IDE and SCSI
controllers at that time.
Only the 1st EIDE Controller is enabled in FW (the 2nd is disabled to permit my
internal modem to be configured at INT 15). I have an EIDE drive configured as
the primary drive on the 1st IDE Controller which now has some Linux partitions.
The IDE Drive contains a second bootable Win '98 configuration.
I believe that one of the experiments I performed was an attempt to upgrade to
RH 6.2 via an NFS partition containing the 6.2 distribution from another machine
which is an all-IDE configuration and on which this exact same partition was
used to upgrade it. That is - the RedHat partition on this machine which was
exported via NFS to the Optiplex is coherent and correct since it was already
successfully used in upgrading that machine.
In that experiment, as I recall, I actually disabled *all* IDE Controllers in
firmware so that the SCSI drive was the only drive in the system. Anaconda
still was unable to proceed due to reported unreadable simlinks.
In another experiment, the 6.2 RedHat distribution was located on a dedicated
partition on the IDE Drive (orginal attempt).
My concern is what changed between the original RH 6.0 Distribution and the RH
6.2 Distribution which accounts for it's ability to install on the exact same
Attached is the fstab (fstab.txt) file and output from cfdisk for each of the
two drives. This system is currently functional in all respects with regard to
all the disk partitions under RH 6.0.
Please request any and all additional documentation or any tests you wish me to
perform as required.
Thanks again for your assistance,
Created attachment 7712 [details]
fstab containing all mountable partitions on both drives
Created attachment 7713 [details]
Assigning to a developer.
New Attempt with different configuration:
1) Disabled the IDE Drive in Optiplex CMOS
2) Disabled the IDE Controllers in CMOS
3) Set boot preferences in CMOS as follows:
2940U2W:00 Seagate ST3940
System BIOS Boot Devices
Thus the system boots directly from the SCSI drive with no IDE References.
I used the RH 7.0 bootnet.img file on floppy to install via FTP from a
RH 7.0 Workstation with the distribution on a vfat partition (the same one
used to install the Workstation).
expert mode fails to find anything and the drivers.img file contains no
reference to the proper Ethernet adapters (2) or to the SCSI Controller (1).
Attempting to install using the 'graphics' mode causes the probe to find all
devices including the Adaptec Controller Adaptor and appears to load drivers for
them all. The install script finds the distribution on the Workstation and
loads both stages from it.
It then reports "No Drives Found"
I used the shell window to look at the /proc entries for the scsi.
1) The /proc/scsi/aic7xxx directory was populated (like RH6) with the '0' file.
This file is identical to the RH 6.0 file of the same name except
there are no statistics.
2) The /proc/scsi/scsi file had a single line: No Drives Found.
Everything else seemed normal including the download to the Adaptec Adapter
and it's report as documented in the aix7xxx file.
I will attach the following:
From the fully-configured and working (this) RH 6.0 configuration:
proc_aic7_6 (the /proc/scsi/aic7xxx/0 copy)
proc_scsi_6 (the /proc/scsi/scsi copy)
From the RH 7.0 installation attempt:
proc_aic7_7 (the install's /proc/scsi/aic7xxx/0 copy)
proc_scsi_7 (the install's /proc/scsi/scsi copy)
Created attachment 9479 [details]
RH 7.0 Install's /proc/scsi/scsi file
Created attachment 9480 [details]
RH 7.0 Install's /proc/scsi/aic7xxx/0 file
Created attachment 9481 [details]
RH 6.0's /proc/scsi/scsi file - same configuration
Created attachment 9482 [details]
RH 6.0's /proc/scsi/aic7xxx/0 file - same configuration
I can't explain why /proc/scsi/scsi says 'No Drives Found'. I tried upgrading
from 6.0 to a recent internal tree and got a traceback. In short, I am unable
to reproduce the original bug.
Traceback (innermost last):
File "/usr/bin/anaconda", line 509, in ?
intf.run(todo, test = test)
File "/var/tmp/anaconda-7.1//usr/lib/anaconda/gui.py", line 376, in run
File "/var/tmp/anaconda-7.1//usr/lib/anaconda/gui.py", line 851, in run
File "/usr/lib/python1.5/site-packages/gtk.py", line 2554, in mainloop
File "/usr/lib/python1.5/site-packages/gtk.py", line 125, in __call__
ret = apply(self.func, a)
File "/var/tmp/anaconda-7.1//usr/lib/anaconda/gui.py", line 478, in nextClicked
self.setScreen (self.currentScreen, self.nextClicked)
File "/var/tmp/anaconda-7.1//usr/lib/anaconda/gui.py", line 587, in setScreen
new_screen = screen.getScreen ()
File "/var/tmp/anaconda-7.1//usr/lib/anaconda/iw/examine_gui.py", line 31, in
self.parts = self.todo.upgradeFindRoot ()
File "/var/tmp/anaconda-7.1//usr/lib/anaconda/todo.py", line 1090, in
return upgrade.findExistingRoots(self.intf, self.fstab)
File "/var/tmp/anaconda-7.1//usr/lib/anaconda/upgrade.py", line 55, in
117, in umount
raise ValueError, "isys.umount() can only umount by mount point"
ValueError: isys.umount() can only umount by mount point
I have tried again with the latest internal tree as of March 2, 2001, and things
seem to be fine. I did an upgrade from a 6.0 scsi system to the latest tree and
things went fine. I can't really explain what has changed except that perhaps
there was some driver weirdness that has been worked out. Resolving as rawhide.
Please reopen if the bug reappears in the future. If you're interested, try
the Wolverine public beta (released on Feb. 19, 2001) and see how that works for
you. It is available at ftp.redhat.com/redhat/beta/wolverine/en/iso