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