Hardware: Dell Optiplex GX1p/P II; Adaptec 3940 base drive, EIDE 2ndary drive. Existing pristine RH 6.0 installed on SCSI drive - boots from partition sda2. RH 6.2 Distribution in partition on hda controller - all files verified. 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" Diagnostics: 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: 65 keymaps 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). -jim stadelmann
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 populated. 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: /etc/conf.modules: 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: ____________________________________________________________ 2c2 < <4>Detected 448881638 Hz processor. --- > <4>Detected 448880324 Hz processor. 45c45 < <4> p5_mmx : 1105.281 MB/sec --- > <4> p5_mmx : 1106.805 MB/sec 48c48 < <4>using fastest function: p5_mmx (1105.281 MB/sec) --- > <4>using fastest function: p5_mmx (1106.805 MB/sec) 57c57,63 < <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. 65c71,72 < <7>VFS: Disk change detected on device fd(2,0) --- > <6>rtl8139.c:v1.07 5/6/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/rtl8139.html > <6>eth1: SMC1211TX EZCard 10/100 (RealTek RTL8139) at 0xd800, IRQ 10, 00:e0:29:5f:b6:0d. 68a76 > <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 been supplied 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 cause problems. Sorry for the delay in handling this issue, I will try to make up for it by helping you resolve this issue now.
Thank you. 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 hardware. 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, -James Stadelmann
Created attachment 7712 [details] fstab containing all mountable partitions on both drives
Created attachment 7713 [details] Partitions
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 self.icw.run () File "/var/tmp/anaconda-7.1//usr/lib/anaconda/gui.py", line 851, in run mainloop () File "/usr/lib/python1.5/site-packages/gtk.py", line 2554, in mainloop _gtk.gtk_main() 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 getScreen self.parts = self.todo.upgradeFindRoot () File "/var/tmp/anaconda-7.1//usr/lib/anaconda/todo.py", line 1090, in upgradeFindRoot return upgrade.findExistingRoots(self.intf, self.fstab) File "/var/tmp/anaconda-7.1//usr/lib/anaconda/upgrade.py", line 55, in findExistingRoots isys.umount('/mnt/sysimage') File "/mnt/redhat/test/qa0217.1/i386/RedHat/instimage/usr/lib/anaconda/isys.py", line 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