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

[Mark Morgan Lloyd]

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
(/[EMAIL PROTECTED],0/SUNW,[EMAIL PROTECTED],880/[EMAIL PROTECTED],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
/[EMAIL PROTECTED],0/SUNW,[EMAIL PROTECTED],880

/[EMAIL PROTECTED],0/SUNW,[EMAIL PROTECTED],880
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]


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

forcsated crorectly

[mat.remic]

I hate t_o say I  told you 'so, but I DID.-

Nmae: Angstr om Microsystmes
Sybmol OTCB-B: a_gm,s
Get on board
Closing Monday: .400
Shares traded: 331,485

Sin ce l'sat week, trai_dng is gangbsuetrs.

It. has beugn, n ow w ith the aqusitoin of its new FFT' so,_f tawre and
more server insatlls  Angsrtom Mirco Syestm s can be yo ur ticke,t.

Soon it wi'll be too late, m ake a pur chase of agms in the m orning
on Tuesady.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: bind9 in unstable

[Dave Barnett]

Brian:

Thanks for the comments.  Stock kernel.

Apparently, someone found and fixed this, as tonight an updated version 
of the bind9 package (1:9.5.0.dfsg-3) was available, plus removing the 
daemontools, daemontools-run, and djbdns, fixed the problem.


Cheers,
Dave

brian m. carlson wrote:

On Sun, Jun 15, 2008 at 10:32:40PM -0400, Dave Barnett wrote:

After installation, the daemon tries to start, but prints out:
Starting domain name service...: bindnamed: syscall(capset) failed:  
Invalid argument: please ensure that the capset kernel module is 
loaded.  see insmod(8)


There doesn't appear to be a capset module.  I found a comment from 
my  searching about a capability module, but that module does not 
appear  to be available.


Did you compile your own kernel?  If you did, did you enable
CONFIG_SECURITY_CAPABILITIES and CONFIG_SECURITY_FILE_CAPABILITIES?  If
you're using the Debian kernel, those should be built in.

capset is the system call to set capabilities (see capabilties(7) and
capset(2)).  Obviously those won't work if you don't have capabilities
enabled.




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]