[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#485961: installation-reports: Installer can't locate CD-ROM drive (sparc)



Frans Pop wrote:
On Thursday 12 June 2008, Dennis Boone wrote:
Comments/Problems:
The installer boots fine, and allows me to set keyboard, country
locale, but cannot detect the CD-ROM
(/sbus@3,0/SUNW,fas@3,8800000/sd@6,0:f) drive to continue the
installation.
+SUNW,fas:FAS-336 ESP SCSI:esp_scsi:initrd
POST/OBP outputs, and syslog are attached.

Thanks for all the info, but I'm afraid that my sparc knowledge is insufficient here. Let's see if anyone on the debian-sparc list can help.

From the logs I can see that the esp_scsi module does get loaded, but it does not seem to detect anything at all. Either something is missing (basic scsi drivers?), or the hardware is just not supported by this driver. I've googled around a bit but that did not help either.

We sometimes advise to netboot sparc systems where the CD is not recognized, but that won't help if the harddisk is on the same bus/controller and needs the same driver.

Anyone any idea what could be missing or if this hardware is supported by linux at all? Here's basic hardware info; the installation report [1] has more extensive logs.

5-slot Sun Enterprise E3500, No Keyboard
OpenBoot 3.2.24, 4096 MB memory installed, Serial #12336266.
Ethernet address 8:0:20:bc:3c:8a, Host ID: 80bc3c8a.

{a} ok probe-scsi-all
/sbus@7,0/SUNW,fas@3,8800000

/sbus@3,0/SUNW,fas@3,8800000
Target 6 Unit 0 Removable Read Only device TOSHIBA XM6201TASUN32XCD110312/12/97 Target e Unit 0 Disk SEAGATE ST373405LC 22033EK1BBDY

Once we figure out what's needed, fixing the installer to support that is probably trivial. The trick is in the first part.

Two things that may yet help:
- the output of lsmod after hardware detection (to see if anything obvious
  is not loaded)
- just manually trying to modprobe any driver under
  /lib/modules/../kernel/drivers/scsi and checking dmesg after each for
  some sign of life

Cheers,
FJP

[1] http://bugs.debian.org/485961

Two questions that might possibly help. The first is that I suspect that the internal SCSI bus termination isn't particularly robust, I think that putting an external (68-pin, SE) terminator on the external SCSI connector improves reliability of hardware detection and subsequent driver load from initrd. So:

* Is the kernel doing something which affects the electrical interface, e.g. glitching auto-termination state during initialisation?

The second thing is that Splackware (Bobware 10.2) is much more reliable at detecting disc drives on the internal bus than Debian (Etch, 4.0). One particular failure mode I see with Debian and at least some disk types is that when it scans for the CD-ROM drive it does /something/ which causes the hard disc to appear at multiple SCSI IDs including the one that the CD is at- which obviously screws things totally. So:

* Is the installer doing something which affects the electrical interface, e.g. a badly-implemented SCAM probe?

Diagnostics:

* At POST, does probe-scsi show the CD-ROM and disc drives? With the system running in my workroom which has a disc mounted next to the CD-ROM it does now that I've added an external terminator.

* When able to break into the Debian startup, either in default or rescue mode, does cat /proc/scsi/scsi show only the expected devices? With the system as above it shows the disc drive splurged over all IDs from 0 through 6 and 8 through 15, the CD-ROM drive has vanished.

* When logging in during a Splackware installation does /proc/scsi/scsi show only the expected devices? Does fdisk run, allow you to erase existing devices, and create a Sun-style disklabel? (Yes, yes).

* Let's eliminate an old chestnut. Now that there's a Sun-style disklabel does the Debian installer behave itself? (No, it loads the ESP driver then sits there fiddling with the bus).

* Does Solaris install? Sorry, I'm not trying this- I've not got half a day to spare :-)

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]


Reply to: