Bug 239608

Please attach your yast logs.
http://en.opensuse.org/Bugs/YaST

And the /var/log/messages please. 

Created attachment 117111 [details]
excerpts from log files 

hello, 
attached you find a tar.gz file with a screenshot of the error and several excerpts og logfiles. The excerpts contain all the information generated after a boot process of the machine. The CD filesystem is correctly recognized; the system offers to mount to the CD. However, Yast2's Sax part reacts with the error message. However I did not see any useful information in the y2log-file.

Hmm, can I download the .iso of your monitor CD to be able to reproduce
this problem ? The sample CD I used works. I assume multiple .inf files
or a similar problem... just a wild guess

Thanks

Unfortunately I am only at home on weekends for some time. A direct access to my machine is not possible. Would have to change 2 firewalls. 
Could I upload the ISO image (> 470 MBye) somewhere?

There exist in fact 2 inf files: A standard inf at the top level of the CD (autorun.inf)  and another in a subdirectory "Driver/SM244T.inf". The last one contains the relevant information, of course. I attach both files to this bug 
Regards Ralph 

Created attachment 118506 [details]
autorun.inf of the Samsung CD

Created attachment 118507 [details]
Datei "Datei/Driver/SM244T.inf" of the Samsung CD

It could be that the error stems from a "/" in the name of the second inf-file. It is located in a directory Driver. Its name however is 
"Driver/SM244T.inf" which is in my opinion irregular. I had problems with uploading it; I had to rename it. Sorry that I did not notice that before. I shall try to create a new CD with the file renamed. 
I only wonder why that worked with SuSE 10.1 ......

Hmm, I was able to import the given inf file successfully. I'm sorry but
I cannot download a 470MB iso ;) There is another way to debug this. If you
don't mind try the following:

   su root
   cd /usr/share/sax/api/macros
   ----> Insert the Samsung Monitor CD/DVD
   ----> now call:
   ./getINF

In normal mode you should see the following output:

   SAMSUNG,SYNCMASTER 244T(ANALOG),56-75,30-94
   SAMSUNG,SYNCMASTER 244T(DIGITAL),56-75,30-94

What happens on your side ? any errors ?

Thanks

Hi, 
I tried your suggestion. Unfortunately without much success. ./getINF gives me no answer at all. The perl script just terminates - without an error message.  

In addition I have burned a CD with the file renamed from "Driver/SM244T.inf" to "SM244T.inf" and with everything else unchanged. Same result - error message from Yast2 -> sax (see the first tgz file in the attachments of this bug. So the error does not depend on the (strange) filename "Driver/SM244T.inf" (meaning that the path including the Driver directory is something like ......../Driver/Driver/SM244T.inf   if the "/" in the filename is not escaped -> therefore I called the file name irregular). 

I should mention that the DVD drive is an LG drive -> I read somewhere that Opensuse 10.2 has difficulties with these drives. I therefore tried to insert the Samsung CD into my Pioneer burner drive instead. -> Same problem.

However, everything works fine with the Samsung CD in either of both drives with SuSE 10.1 on the same machine. It also works with my self burned CD. 
What is the difference regarding Yast + sax between 10.1 and 10.2 ? 

Regards Ralph 

Sorry guys, it was rather late yesterdy night .... so I missed something ....

I tested the getINF macro again. 
It works with SUSE 10.1 and gives exactly the results as predicted by Marcus Schaefer. 

With OpenSUSE 10.2, however,  there is an error message : 
"Can't use an undefined value as an ARRAY reference at /usr/share/sax/modules/WinINF.pm line 147."

I did not see it yesterday because I inserted the CD before using ./getINF . In such a case KDE offers the standard dialogue for detected CDs and then getINF does not provide you with a message. I tested this, too. 

So we at least have an error message now. 
Regards Ralph

Hmm, line 147 is a comment at least in my WinINF.pm code ?
Could you call the the macro within the debugger:

   perl -d ./getINF
   b readDisk
   n
   n
   n
   ....

What's the output there ?

Thanks

Hi,
did some more tests (including the debugging). The first result is that getINF behaves erratically, not really predictable. 
If you repeat the following steps several times you sometimes get an error message and sometimes not. 
Step 1: Open DVD device tray and insert CD without closing the tray. 
Step 2: Start getINF -> tray is drawn inwards by DVD device  - KDE demon detects device - KDE window opens  that offers to show CD contents with konqueror  - answer positively 
(In the background getINF may produce an error message or sometimes not)
Step 3: Close konquerer window (which displays the CD contents correctly)
Step 4: umount /dev/hda 
Step 5: open DVD device tray again and start the whole process again. 

Sometimes getINF produces an error message at Step 2, sometimes not. I tested this with 2 different DVD drives (/dev/hda - an LG drive; /dev/hdb - a Pioneer drive). Please see the files "erratic_behaviour_getINF_hdx.txt" for this erratic behaviour. 
I repeated the tests with SUE 10.1 - this erratic behaviour does not appear there. 

When you run getINF with the debugger you get two different situations which correspond to the described scenarios with and without error message. See the files 
"getINF_error_case_debug.txt" for a situation wih error message. The file "getINF_no_error_msg_debug.txt" contains the debug results for a situation in which getINF just stops without error message. 

I thin that the erratic behaviour is strange already. Nevertheless I hope that the results in "getINF_error_case_debug.txt" help to analyze the bug. 

Kind regards 
Ralph 
 

Created attachment 120778 [details]
Erratic behaviour of getINF with a LG drive

Created attachment 120779 [details]
Erratic behaviour of getINF with a Pioneer drive

Created attachment 120780 [details]
Debug output of getINF in case of an error message

Created attachment 120781 [details]
Debug output of getINF in cases with no error message

Sorry, I see that the file names are changed when I fill out the "comment" field during submission/upload of the attachment files. 

So the erratic behaviour described in comment 12 is documented by the attachments 
"Erratic behaviour of getINF with a LG drive" and "Erratic behaviour of getINF with a Pioneer drive".
The debug output for a situation with an error message is documented in the attachment 
"debug output of getINF in case of an error message" .
The debug output for a situation without an error message is documented in the attachment 
"debug output of getINF in cases with no error message" 

Sorry for the inconvenience. 
Regards
Ralph 

sorry I'm confused :) Would you mind to call getINF from
runlevel 3... no desktop no other magic 

   init 3
   cd /usr/share/sax/api/macros
   ----> Insert the Samsung Monitor CD/DVD
   ----> now call:
   ./getINF

any difference ?

Thanks

any news here ?

Hi, 
had no time last weekend. Sorry that you had to wait. 
Today I tried with level 3 (no KDE, no Gnome, no magic ...). 
Result: ./getINF just terminates without any error messages in 15 of 15 cases I tried. With debugging on you get the same result as in attachment with id=120781 (Debug output of getINF in cases with no error message).

To verify again that the CD is not readable I used yast in level 3 -> sax2 is started with an svga mode -> inserted CD -> same error as before -> CD not readable.

The previously described erratic behaviour of ./getINF on level 5 (with KDE) can still be reproduced -> sometimes you get an an error message (see attachment id=120780 for debugging output) - sometimes you do not get it. 

Regards 
Ralph 

 

Hmm, this sounds really strange... the debug output said two files are
opened but no information was read... what the heck

Could you check the output of

   /usr/sbin/sysp -D

it should output all your CD/DVD device names, are they correct ?

Thanks
   

Hi, 
here is the output: 

rux64:~ # /usr/sbin/sysp -D
/dev/hda,/dev/hdb

This is OK. /dev/hda is a LG DVD device, /dev/hdb is a Pioneer burner - see the following excerpts from boot.msg (1st attachment to this bug): 

<6>NFORCE-CK804: IDE controller at PCI slot 0000:00:06.0
<6>NFORCE-CK804: chipset revision 242
<6>NFORCE-CK804: not 100% native mode: will probe irqs later
<6>NFORCE-CK804: 0000:00:06.0 (rev f2) UDMA133 controller
<6>    ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
<6>    ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
<7>Probing IDE interface ide0...
<4>hda: HL-DT-STDVD-ROM GDR8164B, ATAPI CD/DVD-ROM drive
<4>hdb: PIONEER DVD-RW DVR-110, ATAPI CD/DVD-ROM drive

and 

<6>forcedeth: using HIGHDMA
<6>usbcore: registered new driver usbfs
<6>usbcore: registered new driver hub
<6>hda: ATAPI 52X DVD-ROM drive, 256kB Cache, UDMA(33)
<6>Uniform CD-ROM driver Revision: 3.20
<7>ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
<6>hdb: ATAPI 40X DVD-ROM DVD-R-RAM CD-R/RW drive, 2000kB Cache, UDMA(66)

Kind regards
Ralph 

finally I found the bug, the device was umounted before reading takes
place. What a mistake. I apologise for being so stupid

fixed 

No need to apologize - as SuSE user I am happy that the bug is identified and that it can be resolved. What comes next? Will a Yast2 update be provided? I have not seen any so far ... 
Kind regards 
Ralph  

you can find updated packages here:

   http://ftp.opensuse.org/pub/opensuse/repositories/SaX2/