Bug 105682

either tino or danny are responsible ;) 

please add the output of 'lshal' and: 
- 'tar -cjf udevinfo.tar.bz2 /dev/.udevdb'

Created attachment 46693 [details]
Output of 'lshal'

Created attachment 46694 [details]
Output of 'tar -cjf udevinfo.tar.bz2 /dev/.udevdb'

looks like a problem with the symlinks. sdb is never a cdrom device. sr0 is the 
cdrom device.  

Was this a fresh installation? Did you canged the hardware after the 
installation? (did you tried Beta2?)

please attach:
- /etc/udev/rules.d/20-cdrom.rules
- output of 'lsscsi'

Yes, this was a clean install.  The hardware was unchanged afterwards, as was
the software.  The one thing that we modified was the kernel; we had to make a
minor patch to the included kernel source in order to get the ethernet
(intel/marvell gigabit ethernet controller) working.

We haven't tried Beta 2.

/etc/udev/rules.d/20-cdrom.rules contains:

# cdrom links generated by YaST2
#
BUS="scsi", ID="2:0:0:0", SYSFS{removable}="1", SYMLINK="cdrom"

'lsscsi' yields:

[0:0:0:0]    disk    ATA      ST3120026AS      3.05  /dev/sda
[1:0:0:0]    cd/dvd  TDK      DVDRW880N        1.33  /dev/sr0
[2:0:0:0]    disk    IN-WIN   iAPP  HS-CF      1.95  /dev/sdb
[2:0:0:1]    disk    IN-WIN   iAPP  HS-MS      1.95  /dev/sdc
[2:0:0:2]    disk    IN-WIN   iAPP  HS-SM      1.95  /dev/sdd
[2:0:0:3]    disk    IN-WIN   iAPP  HS-SD/MMC  1.95  /dev/sde

I think this rule is wrong written by YAST  it should be:
BUS="scsi", ID="1:0:0:0", SYSFS{removable}="1", SYMLINK="cdrom"

YaST2 just uses the entry for "sysfs_bus_id" provided by hwinfo to create 
that line in the cdrom.rules file. No idea why it uses the disk instead of
the cdrom. 
Please attach files /var/log/YaST2/y2log* from this installation so I can see
what data was provided by hwinfo. 
I am adding Steffen to cc: maybe hwinfo detected something wrong.

Please run 'getsysinfo' after install starts and attach the tar file. 

Created attachment 46921 [details]
'/var/log/YaST2/y2log*'

What is 'getsysinfo' and where would I find it?  (It doesn't appear to be 
installed by default in beta 1)  By 'after install starts,' do you mean I need 
to reinstall from scratch and stop it at a certain time? 

No, just wait until yast starts and run getsysinfo on console 2. 

Created attachment 46929 [details]
Output of 'getsysinfo' while 'yast' is running

The YaST2 log contains the following:

2005-08-17 13:02:56 <1> linux(3179) [YCP] StorageDevices.ycp:313 ProbeCDROMs
([$["bus":"SCSI", "bus_hwcfg":"scsi", "class_id":262, "dev_name":"/dev/sr0",
"dev_name2":"/dev/sg5", "dev_names":["/dev/sr0"], "dev_num":$["major":11,
"minor":0, "range":1, "type":"b"], "device":"DVDRW880N", "driver":"ata_piix",
"linkname":"/dev/cdrom", "model":"TDK DVDRW880N",
"old_unique_key":"pky6.s96VgamCppC", "prog_if":3, "rev":"1.33",
"sub_class_id":2, "sysfs_bus_id":"2:0:0:0", "udev_links":["cdrom"],
"unique_key":"twPO.vioLdypABb0", "vendor":"TDK"]])

This clearly indicates that the cdrom drive had a "sysfs_bus_id" of "2:0:0:0"
during installation. No idea why it apparently has "1:0:0:0" in installed
system. But apparently YaST2 cannot know that the "sysfs_bus_id" will change
with different system boots. This needs to be prevented. 

No idea who is reponsible for device handling during system startup.
But of course it must be assured that values like "sysfs_bus_id" have
the same value in inst-sys and installed system.

Yes, looks like different module loading order is the cause. 
Isn't udev supposed to make us independent of this? ;-) 

Tja, kay, i fear you should have a look at this...

You simply can't depend on the scsi bus enumeration. You need to use another
persistent property of the device and not the kernel number.
Thomas, Steffen? Who can fix that? udev can't do anything here.

Of course I can write to the rules file whatever is told me.
The current version was told to me by Hanns Reinecke for SL 9.3.
What should a line for a cdrom look like in 10.0?

Ho-hum. The udev rules have not been quite correctly. As it turned out, the
persistent links for cdroms have not been generated.

Created attachment 49042 [details]
50-udev.rules

Updated udev rules file.

With the updated rules file, I get something like:

2005-09-07 13:48:57 <1> g40(7684) [YCP] clients/cdrom.ycp:241 CDROMRead $["bus":
"SCSI", "bus_hwcfg":"scsi", "changed":false, "class_id":262, "configured":false,
 "dev_name":"/dev/sr0", "dev_name2":"/dev/sg1", "dev_names":["/dev/sr0", "/dev/d
isk/by-path/pci-0000:03:05.0-scsi-1:0:0:0"], "dev_num":$["major":11, "minor":0, 
"range":1, "type":"b"], "device":"/dev/sr0", "driver":"sata_sil", "model":"PLEXT
OR DVDR   PX-712A", "notready":true, "old_unique_key":"P2bE.vCye3LNOLa3", "prog_
if":3, "rev":"1.03", "sub_class_id":2, "sysfs_bus_id":"1:0:0:0", "udev_links":[]
, "udi":"/org/freedesktop/Hal/devices/storage_model_DVDR___PX_712A", "unique_key
":"twPO.dDdPRJZyZh6", "vendor":"PLEXTOR"]

So we should match on the 'by-path' entry in "dev_names", this should guarantee
us that the device link will not change.

The udev rules entry would be something like:

 ENV{ID_PATH}=="disk/by-path/pci-0000:03:05.0-scsi-1:0:0:0", SYMLINK+="cdrom"

and needs to come _after_ the main rules have been read, eg stored under
'55-cdrom.rules'.

The udev rules to create by-path links for scsi opticals are submitted to autobuild.

Something like this:
  ENV{ID_PATH}=="pci-0000:03:05.0-scsi-1:0:0:0", SYMLINK+="cdrom"

should work. (if applied after 50-udev.rules)

So far YaST2 created /etc/udev/rules.d/20-cdrom.rules, 
I now changed this to create /etc/udev/rules.d/55-cdrom.rules.

It should now create lines in this file like the following (in one line):
ENV{ID_PATH}=="pci-0000:03:05.0-scsi-1:0:0:0", SYSFS{removable}="1",
SYMLINK+="cdrom"

Is this ok?

Yes, looks good. Any reason for the removable check? If yes, it should use '=='.

No real reason, it was just there in SL 9.3.
Should I remove it?

I don't know why it was added. Maybe it should prevent the cdrom link to be
created if someone removes the cdrom drive and connects a hard disk to that
connector? Don't know if we need this - having it should not cause problems. But
'==' would be nicer.

I already replaced the "=" by "=="

Should be fixed in RC2