Bugzilla – Bug 165833
yasst2 sw_single does not start with broken CD in drive
Last modified: 2007-11-06 10:20:15 UTC
SL 10.1 rc1, updated from beta9 via network. My CD drive is blocked with a faulty audio CD and does not react on neither "eject" nor the hw key. Now, when starting "yast2 sw_single" there is simply no reaction. There is no error message, there is no checking of other installation sources (as far as I can see). I would expect yast2 to be more robust than that when handling multiple, possibly unavailable installation sources, and I would *definitely* expect some kind of error message.
Ah. The sw_single suddenly appeared after ~10 minutes. Which is not really a solution (and hopefully no "works as designed").
Please attach the yast logs. Can you further try if this also fails if you insert _any_ audio or data cd? If so, we should raise this to blocker.
Seems to happen with all CDs that block the drive (I have to basically reboot to free the drive, so there's only very limited testing possible). If my CD drive is blocked, the syslog shows something along: Apr 13 15:54:35 linux kernel: st: Version 20050830, fixed bufsize 32768, s/g segs 256 Apr 13 15:54:35 linux kernel: hdd: command error: status=0x51 { DriveReady SeekComplete Error } Apr 13 15:54:35 linux kernel: hdd: command error: error=0x54 { AbortedCommand LastFailedSense=0x05 } Apr 13 15:54:35 linux kernel: ide: failed opcode was: unknown Apr 13 15:54:35 linux kernel: end_request: I/O error, dev hdd, sector 64 Apr 13 15:54:35 linux kernel: Buffer I/O error on device hdd, logical block 16 Apr 13 15:55:35 linux kernel: ide-cd: cmd 0x3 timed out Apr 13 15:55:35 linux kernel: hdd: lost interrupt This in itself is an old problem. You can find the logs at at: http://w3.suse.de/~rplewe/y2logs20060413-1.tgz They are too big for bugzilla...
Might be a silly question: But are you sure there is everything in order with your drive? Normally, trying to mount a CDDA simply fails, so YaST should realize that. Can you see this behaviour in other machines, too?
No, in fact I'm rather sure the drive is quite faulty. That is not the point. The point is: I installed via network, the (old) CD drive based installation sources I had from 10.0 are deleted in yast2 (meaning: not present). So there is *no* reason whatsoever for sw_single to get delayed by a faulty CD drive. So: - either sw_single does something with the CD drive when it's not supposed to touch the drive -> bug - sw_single hangs independently from the CD drive -> worse bug I can't reproduce the hanging on my SLES 10 beta10 machine (which has a working CD drive). That's currently the only other testing environment I got.
OK this places this in a different light. Reassigning to Klaus for further evaluation.
The MediaCD handler from libzypp is newer used in the logs in Comment #13. The problems occurs while hardware detection that is done by YaST2; see last line in y2log: 2006-04-13 15:54:35 <1> coredump(19387) [YCP] StorageDevices.ycp:367 FloppyDrives [] and search for it in "y2log-1" - there you'll see what is detected after the floppy: 2006-04-03 18:16:44 <1> linux(4596) [YCP] StorageDevices.ycp:367 FloppyDrives [] 2006-04-03 18:16:46 <1> linux(4596) [YCP] StorageDevices.ycp:277 IDE CD-RW [] I would tend to say "WONTFIX" because of broken hardware ... Stano?
The question was not if the hw is broken. The question is: why does yast2 touch a piece of hw it is not supposed to touch (and hangs itself in the process)? sw_single gets a list of sources, and then checking possible, not-supplied sources is bad style at least, I think.
StorageDevices constructor.
I do not see what is wrong here. StorageDevices constructor does a SCR::Read(.probe.cdrom). I do no see what is wrong with that. If hardware is broken one cannot expect everthing to work properly.
> I do no see what is wrong with that. Once again: Wrong is that sw_single tries to access a piece of hardware (the cdrom) it has *no* business to touch.
If StorageDevices gets initialized it cannot know which device will be touched after initialisation, therefore it has to detect available devices. So I cannot see what I can do here.
If it a) is a bug b) is not in your area to fix you just *might* consider to assign it to someone who would be the right person to fix/work on it. Whatever "StorageDevices" is, to me it does not sound like something that has to be called automatically when looking for software sources. So, why do you initialize StorageDevices if storage devices are in no way involved? And, vice versa, if I have only local software repositories, do you call some 'NetworkDevices' and get problems if there's no network, too?
In my opinion it is not a bug at all. IMHO it is perfectly fine to call hwinfo to query available cdrom drives, especially if software installation is concerned.
reassigned to yast2-maintainers should they handle this.
This then renders the "Installation Source" part of yast2 a bit... questionable. When given exact instructions (like the list of installation sources), they should be followed. Ignoring them because the system tries to "know better" is a bug (or bad design). I don't think it is fine if the system behaves differently than expected (and told) to behave. However, these surely border on philosophical questions, and I'm not the one to decide. If you are aware of the problem I'm reporting, and decide that it is the way it should be, then do so. I just don't want the bug closed because of a misunderstanding in what the actual problem is. Lowering the priority in any case, since it's at least not a general problem.
Ad comment #16: you read the discussion wrong - YaST does not access the installation source, it scans the system for the available hardware first. We should avoid to call that constructor if not absolutely needed. -> maintainer for future tracking
*** Bug 159888 has been marked as a duplicate of this bug. ***
This problem should be fixed with delayed initialization of StorageDevices (see bug 335582).