This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 230849 - [vmware bug] f7 install does not find hd
[vmware bug] f7 install does not find hd
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
8
All Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
:
: 230989 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-03-03 13:10 EST by Allen Kistler
Modified: 2007-11-30 17:11 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-05 16:59:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Allen Kistler 2007-03-03 13:10:23 EST
Description of problem:
No drives found during installation to VMware WS 5.5.3 and not able to add any,
either.

Version-Release number of selected component (if applicable):
f7-test2-dvd-i386

How reproducible:
Always

Steps to Reproduce:
1. Insert DVD
2. Boot to DVD
3.
  
Actual results:
No drives found to partition.
Not able to add drives.

Expected results:
Drive should be found automatically.
Failing that, should be able to add module for controller.

Additional info:
f7t1 worked okay for installation.
f7t2 fails to find LSI Logic SCSI controller, despite autoloading the mptbase
and mptspi drivers.  (f7t1 installation still boots fine.)
Attempting to add drive results in dialog that says Ethernet interface must be
active (huh?) [graphical install] or results in nothing whatsoever [F2 key in
text install]
Attempting to activate eth0 using dhcp during graphical install locks up.
(tcpdump follows.  .1 is the DHCP server and gateway).
Attempting to activate eth0 using a static config produces absolutely no results
(but it doesn't lock up, either).

11:12:53.956856 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 1
group record(s), length 28
11:12:53.988027 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request
from 00:0c:29:c2:73:37, length: 300
11:12:53.989835 arp who-has 172.16.9.128 tell 172.16.9.1
11:12:54.127958 IP6 :: > ff02::1:ffc2:7337: ICMP6, neighbor solicitation, who
has fe80::20c:29ff:fec2:7337, length 24
11:12:54.989635 arp who-has 172.16.9.128 tell 172.16.9.1
11:12:54.997711 IP 172.16.9.1.bootps > 172.16.9.128.bootpc: BOOTP/DHCP, Reply,
length: 300
11:12:54.999033 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request
from 00:0c:29:c2:73:37, length: 307
11:12:55.013111 IP 172.16.9.1.bootps > 172.16.9.128.bootpc: BOOTP/DHCP, Reply,
length: 300
11:12:55.127519 IP6 fe80::20c:29ff:fec2:7337 > ff02::2: ICMP6, router
solicitation, length 16
11:12:55.989433 arp who-has 172.16.9.128 tell 172.16.9.1
11:12:56.288480 IP6 fe80::20c:29ff:fec2:7337 > ff02::16: HBH ICMP6, multicast
listener report v2, 1 group record(s), length 28
11:12:59.128043 IP6 fe80::20c:29ff:fec2:7337 > ff02::2: ICMP6, router
solicitation, length 16
11:13:03.128855 IP6 fe80::20c:29ff:fec2:7337 > ff02::2: ICMP6, router
solicitation, length 16
Comment 1 Jeremy Katz 2007-03-05 15:42:38 EST
The mptspi driver in the current kernel doesn't seem to like the vmware emulated
disks.
Comment 2 Dave Jones 2007-03-05 23:41:16 EST
*** Bug 230989 has been marked as a duplicate of this bug. ***
Comment 3 Need Real Name 2007-04-02 11:28:09 EDT
This is still broken in FC7T3. This is a regression, it worked before.
The Anaconda installer crashes.
Comment 4 Need Real Name 2007-04-08 13:07:53 EDT
Red Hat - we are constantly encouraged to bugzilla things. We've bugzillaed
this, but there seems to be no progress. I'm sure there is progress, but from
the end users' point of view, no comment means no progress. We have no idea what
is going on.

Is this a difficult bug to fix? Is it likely to make Fedora 7 final?

The lack of an update is made worse because there is now a VMware competitor in
the form of Xen. Not updating this bug, and leaving it hanging around _looks_
suspicious.

Please can we have an update on this problem?

This is not a NEW bug, it's confirmed by Jeremy Katz above.
Comment 5 Dave Jones 2007-04-08 19:39:26 EDT
There's nothing suspicious going on at all, just no-one has had the time to look
into it.
Comment 6 Dave Jones 2007-04-23 13:38:37 EDT
I wonder if this was caused by the missing loading of scsi_wait_scan in the
initrd.  Can someone test this with the latest tree?
Comment 7 Need Real Name 2007-04-23 16:49:46 EDT
Sure. Will test with next Fedora test release + yum upgrade in case initrd is
too old.
Comment 8 Allen Kistler 2007-04-27 20:54:13 EDT
Just downloaded f7t4 dvd.  The problem still exists.
Comment 9 Need Real Name 2007-04-30 12:05:10 EDT
Still broken.
Comment 10 Need Real Name 2007-06-01 04:00:01 EDT
You *have* to be kidding me! This is broken in Final!
Comment 11 Need Real Name 2007-06-01 04:00:56 EDT
Please can someone up the severity, and change the distro f7?
Comment 12 Allen Kistler 2007-06-01 23:41:32 EDT
I can confirm that this bug still exists in the General Availability release.
F-7-i386-DVD.iso with
kernel-2.6.21-1.3194.fc7 &
anaconda-11.2.0.66-1 (?)
Comment 13 Andre Robatino 2007-06-02 09:03:53 EDT
  I appear to be experiencing the same thing.  It's happening with a new 120 GB
HD installed in an 8-year old machine, so I originally thought it was the BIOS.
 But the GParted LiveCD sees the entire drive so I don't think that's it.  See
my post at

http://forums.fedoraforum.org/showthread.php?p=801115
Comment 14 Andre Robatino 2007-06-03 13:58:21 EDT
  I did a successful FC6 install using the CD set (the FC6 DVD failed before
even getting to the boot: prompt), with the drive being detected properly with
the full size, so it's definitely an anaconda bug.
Comment 15 Andre Robatino 2007-06-03 14:03:45 EDT
  Also, as noted in my link above, when I replaced the new drive with an older,
smaller one, the F7 installer detects that drive properly (though the install
fails after that for a different reason).  So the problem can be triggered by
changing the hard drive and nothing else.
Comment 16 Need Real Name 2007-06-03 14:10:51 EDT
Andre - are you installing in VMware, or using an LSI Logic SCSI adaptor?
Comment 17 Andre Robatino 2007-06-03 14:16:59 EDT
  I'm definitely not doing the former, and I don't know what the latter is, so
probably not that either.  It's just a CD/DVD install on a fairly generic 8-year
old machine, and the new hard drive simply replaced the old one.  Other than
that, a new DVD drive to replace the old CD drive, and more RAM, there are no
other hardware changes.
Comment 18 Andre Robatino 2007-06-03 14:37:38 EDT
  Also, the new drive is a WDC WD1200BB.  The machine's 8-year old BIOS doesn't
seem to understand how big the drive actually is - in the BIOS IDE autodetect,
it says 1073 MB, and in the machine's startup screen when booting it refers to
it as 65535 MB.  Nevertheless, the OS clearly can work around this problem, if
it's not relying on the BIOS too much.
Comment 19 Alan Cox 2007-06-05 13:57:09 EDT
If your box isn't running vmware + mpt scsi emulation then file a seperate bug
please.

Comment 20 Fabio 2007-06-07 07:22:20 EDT
I had a FC6 on VMWare-ESX 3.0.1 that worked fine (with LSI Logic).
I did upgrade to F7 and now the server doesn't complete the boot.

I still have the kernel 2.6.20-1.2952.fc6 on FC7 and it boots normal.
If I boot with the new 2.6.21-1.3194.fc7 the module mptbase does not have time
to initialize the controller so... KERNEL PANIC.

The new initrd looks like this:

...cut...
echo "Loading scsi_mod.ko module"
insmod /lib/scsi_mod.ko
echo "Loading sd_mod.ko module"
insmod /lib/sd_mod.ko
echo "Loading scsi_transport_spi.ko module"
insmod /lib/scsi_transport_spi.ko
echo "Loading mptbase.ko module"
insmod /lib/mptbase.ko
echo "Loading mptscsih.ko module"
insmod /lib/mptscsih.ko
echo "Loading mptspi.ko module"
insmod /lib/mptspi.ko
echo "Loading mbcache.ko module"
insmod /lib/mbcache.ko
echo "Loading jbd.ko module"
insmod /lib/jbd.ko
echo "Loading ext3.ko module"
insmod /lib/ext3.ko
echo "Loading uhci-hcd.ko module"
insmod /lib/uhci-hcd.ko
echo "Loading ohci-hcd.ko module"
insmod /lib/ohci-hcd.ko
echo "Loading ehci-hcd.ko module"
insmod /lib/ehci-hcd.ko
insmod /lib/scsi_wait_scan.ko
rmmod scsi_wait_scan
mkblkdevs
resume /dev/sda2
echo Creating root device.
mkrootdev -t ext3 -o defaults,ro /dev/sda1
echo Mounting root filesystem.
mount /sysroot
...cut...

May be the module scsi_wait_scan doesn't wait enough?

The old (FC6, which works) is:

...cut...
echo Creating block device nodes.
mkblkdevs
echo "Loading uhci-hcd.ko module"
insmod /lib/uhci-hcd.ko
echo "Loading ohci-hcd.ko module"
insmod /lib/ohci-hcd.ko
echo "Loading ehci-hcd.ko module"
insmod /lib/ehci-hcd.ko
mount -t usbfs /proc/bus/usb /proc/bus/usb
echo "Loading jbd.ko module"
insmod /lib/jbd.ko
echo "Loading ext3.ko module"
insmod /lib/ext3.ko
echo "Loading scsi_mod.ko module"
insmod /lib/scsi_mod.ko
echo "Loading sd_mod.ko module"
insmod /lib/sd_mod.ko
echo "Loading scsi_transport_spi.ko module"
insmod /lib/scsi_transport_spi.ko
echo "Loading mptbase.ko module"
insmod /lib/mptbase.ko
echo "Loading mptscsih.ko module"
insmod /lib/mptscsih.ko
echo "Loading mptspi.ko module"
insmod /lib/mptspi.ko
mkblkdevs
resume /dev/sda2
echo Creating root device.
mkrootdev -t ext3 -o defaults,ro /dev/sda1
echo Mounting root filesystem.
mount /sysroot
echo Setting up other filesystems.
...cut...

Bye,
Fabio
Comment 21 Dave Habben 2007-06-07 20:52:51 EDT
2.6.20 based kernels continue to boot fine under ESX 3.0.1, it looks like it may
have been one of the changes to the LSI Logic driver in the 2.6.21 kernel:

http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.21
Author: Eric Moore <eric.moore@lsi.com>
[SCSI] fusion - bump version - 3.04.04
[SCSI] fusion - error handling bug fix's
[SCSI] fusion - report wide port sas address's for hba phys

http://www.vmware.com/community/thread.jspa?threadID=87219&tstart=0
"its a vmware issue: the new mptbase driver issued a bug in the scsi emulation"

If you are running Fedora 7 under VMWare you can switch to the BusLogic driver
until the issue is resolved, just make sure you first create a new initrd:
 mkinitrd --preload=scsi_mod --preload=sd_mod --preload=BusLogic
/boot/initrd-2.6.21-1.3194.fc7.img 2.6.21-1.3194.fc7

Worked for me, YMMV
Comment 22 Need Real Name 2007-08-08 05:37:10 EDT
Still broken in F8T1! Blocker?
Comment 23 Dave Habben 2007-09-20 15:53:59 EDT
Just tested with VMWare ESX Server 3.0.2, Fedora 7.91 (Fedora 8 Test 2). When
using the LSI Logic driver under ESX it is still unable to locate any hard drives.


Comment 24 Chuck Ebbert 2007-09-20 17:10:10 EDT
Patch for this is not in test2, it went in after that. Update your kernel and
try again.
Comment 25 Dave Habben 2007-10-05 16:51:48 EDT
I can confirm that this is fixed with Fedora 7.92 (Fedora 8 Test 3) 

I was able to boot the install CD under ESX 3.0.2 and partition the hard drive. 


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