CD-ROMs not detected unless when booting with one inserted already

[muncrief]

Binary package hint: udev

This is simply a users attempt to reopen bug #431055 which was arbitrarily closed without resolution. The symptoms haven't changed, and the attempted fixes had no effect upon the problem, as was reported by all the users in the original bug report. Here is the original filers description, for it needs no modification:

"When I insert a cdrom, it doesn't appear anywhere in gnome.
in computer:// cdrom drive actually disappears after I insert cdrom
no icon in places, and for sure no automounting.

Nether brasero 'sees' the new cdrom

Bug happened just few days ago.

Fully updated 9.10"

Why this bug was declared fixed is a mystery to me, and I think it will also be a mystery to anyone who reviews bug #431055.

But I spent the half a day it takes to figure out all the GPG nonsense it takes for a normal user to report/reopen a bug, and I hope this time the developers will take it seriously and fix it. It was eventually rated as high priority, and I agree, since not being able to mount or use DVD/CD media is a show stopper for any OS.

If new data is required I will be more than happy to supply it, but I believe bug #431055 supplies all the data, and more, that is necessary.

What is required here is not more data, but simply a developer that wants to fix the problem.

[Martin Pitt (pitti)]

Can you please exactly see what happens for you? Bug 431055 is fixed, and in a comment there you say instead

==== quote ====
If I don't boot with media in the drive my DVD/CD drive is basically dead in the water. Even though I can manually mount it, I can't burn anything to it because Brasero doesn't recognize it. The eject button also doesn't work. Curiously though, K3B does work for mounting, burning, and ejecting.

However if I boot with media in the drive everything works fine. The media is automounted, I can eject it with the button or via Nautilus, and continue to insert, use, and remove media normally.
=== quote ===

> What is required here is not more data, but simply a developer that wants to fix the problem.

I'm afraid we do need more data, since (contrary to bug 431055) it does not happen for everyone, and I cannot reproduce it.

Can you please do the following:

  1. Boot without a CD-ROM inserted (i. e. the situation which reproduces the bug)
  2. Open a terminal and do

        udevadm monitor --udev -e > /tmp/udev.log

  3. Open another terminal and do

        devkit-disks --monitor-detail > /tmp/dk.log

  4. Insert a CD-ROM and wait a couple of seconds. As you say, nothing should happen on the desktop.

  5. Press Control-C in those two terminals to stop the monitoring.

  6. Do

         devkit-disks --dump > /tmp/dk-dump.txt
         udevadm info --export-db > /tmp/udev-dump.txt

  7. Attach /tmp/dk.log, /tmp/udev.log, /tmp/dk-dump.txt, /tmp/udev-dump.txt, and /var/log/kern.log here.

Thanks!

[muncrief (rmuncrief)]

OK, I've done as you requested and attached the logs below. I hope this helps and thank you for addressing this problem so quickly. It looks like I misunderstood what had happened with the other bug, and I apologize. Please let me know if you need any other data or tests. I will be at my computer for the rest of the day. By the way, the drive I have has a SATA interface, and I'm running Ubuntu x86_65 Karmic Alpha 6 with all updates as of this moment.

[muncrief (rmuncrief)]

I just noticed after rebooting with media in the drive that although automount does consistently work, the physical eject button on the drive actually doesn't work. However, I can consistently unmount and eject via nautilus.

[muncrief (rmuncrief)]

Well, I don't know what has changed since yesterday but there is an even worse problem after booting with media in the drive. As I said, I can consistently automount media, and unmount/eject it via nautilus, but only until I close the drive with no media in it.

Once I close the drive with no media in it it is locked shut. The physical eject button doesn't work, and even the command line eject doesn't work. I tried:

eject /media/cdrom0
eject /media/cdrom
sudo eject /media/cdrom0
sudo eject /media/cdrom

No errors are output and the commands complete without delay, however the drive remains locked until I reboot. After reboot the physical eject button works again whether I have media in it or not. Perhaps you need logs to see what's happening when I boot with media in the drive? If so please let me know.

And by the way, whenever media isn't in the drive all ODD icons disappear from nautilus so there is no way to try and eject it from there.

[Martin Pitt (pitti)]

BTW, the broken hardware eject button is covered in bug 397734, should be well within the karmic range.

The first thing that caught my eye is that the CD media capabilities are misdetected. It claims that it's a DVD-RAM, and whatnot. However, it does that here as well, so this is apparently not the reason. I filed that as bug 439701 to not forget about it.

The more interesting difference between my system (where everything works) and your's is that udev does not detect the file system type. For me it says

ID_FS_LABEL=Ubuntu_9.04_amd64
ID_FS_LABEL_ENC=Ubuntu\x209.04\x20amd64
ID_FS_TYPE=iso9660
ID_FS_USAGE=filesystem

This is completely missing for you, and consequently the higher levels don't consider it as an automountable volume.

Can you please run some further tests to track this down?

When booting without a CD-ROM in the drive (i. e. broken autodetection), please insert that CD again, and copy&paste the output of

      blkid -p /dev/cdrom
      sudo mount /dev/cdrom /mnt

After that, please attach /var/log/kern.log (you forgot the previous time, but I'd like to check it if the kernel detected some anomalies).

Thanks!

[Martin Pitt (pitti)]

muncrief [2009-09-30 20:33 -0000]:
> Once I close the drive with no media in it it is locked shut. The
> physical eject button doesn't work, and even the command line eject
> doesn't work.

This is even more interesting. Please attach /var/log/kern.log a few
seconds after this happens.

I tried:
> eject /media/cdrom0

In this situation, can you please do

 strace -f -vv -s 1024 -o /tmp/eject.trace eject /dev/cdrom

and attach /tmp/eject.trace here?

> Perhaps you need logs to see what's happening when I boot with media
> in the drive?

If everything works, I don't really need them (I can compare them with
logs on my system).

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

[Martin Pitt (pitti)]

Oh, and another thing just came to my mind: Is your CD-ROM in
/etc/fstab? If so, please comment it out and try again. (This is
another potential difference)

If you are unsure, please just attach /etc/fstab, and I'll walk you
through it.

Thanks!

[muncrief (rmuncrief)]

OK, I've attached the data you requested. Sorry for forgetting the kernel log before. I did have the cdrom in /etc/fstab and I removed it. I thought it fixed the problem at first because after I rebooted and inserted the DVD it automounted, but it only did it once. I tried rebooting numerous times after that and it never automounted again. So here come the logs ...

[Martin Pitt (pitti)]

Thanks. So blkid/mount proves that it's not just a failure in fs detection in the rules, the kernel is not able to talk to the device properly. dmesg is full of errors like

Sep 28 22:24:55 entropod kernel: [ 22.502856] sr 2:0:0:0: [sr0] Sense Key : Illegal Request [current]
Sep 28 22:24:55 entropod kernel: [ 22.502859] sr 2:0:0:0: [sr0] Add. Sense: Read of scrambled sector without authentication
Sep 28 22:24:55 entropod kernel: [ 22.502863] end_request: I/O error, dev sr0, sector 15694208

Did you try this with a copy-protected movie DVD perhaps? Do you get the same problem with a normal data CD-ROM or CD-RW? I. e. is it specific to the medium or does it happen with any medium?

There are also lots of error messages like

Sep 30 13:15:22 entropod kernel: [ 506.717387] sr 2:0:0:0: [sr0] Sense Key : Illegal Request [current]
Sep 30 13:15:22 entropod kernel: [ 506.717389] sr 2:0:0:0: [sr0] Add. Sense: Logical block address out of range
Sep 30 13:15:22 entropod kernel: [ 506.717391] end_request: I/O error, dev sr0, sector 15694328
Sep 30 13:15:22 entropod kernel: [ 506.717393] Buffer I/O error on device sr0, logical block 3923582
Sep 30 13:15:22 entropod kernel: [ 506.717394] Buffer I/O error on device sr0, logical block 3923583

which could be a variant of copy protection, a bug in the CD drive firmware, bad media, or a bug in the kernel; hard to tell for me, this would need input from some kernel specialists.

So, let's see on which kind of media this problem occurs in the first place. Thanks!

[Martin Pitt (pitti)]

As for the broken eject, both ioctls which should cause the eject fail:

4038 ioctl(3, CDROMEJECT, 0) = -1 EIO (Input/output error)
4038 ioctl(3, BLKRRPART, 0x7fffcb7fa6d0) = -1 EINVAL (Invalid argument)

I guess this is somehow related to the other problems that you have with your drive.

Did you get these errors in 9.04 (Jaunty) as well? Or is this a regression? If it worked in 9.04, did you upgrade or did you install 9.10 from scratch? In the former case you should still have the old kernel (2.6.28...) in the boot menu. Do you also get these errors if you start this?

[muncrief (rmuncrief)]

First of all, just to let you know my level of expertise, I was an R&D engineer for over two decades, but generally considered an embedded systems designer because I'm a multi-disciplined hardware/firmware/software engineer, developing everything from custom microprocessors and assemblers, to enterprise Windows and Unix applications. But of course, since most high technology jobs like mine have been exported from this country by the Democrats and Republicans, I will be eternally unemployed but can comfortably live off the earnings from before America abandoned its own people.

So I hope you can understand that I've tried all kinds of media, from commercial DVD's to home burnt ones, to commercial and home burnt audio and data CD's.

And all of this media works great under Jaunty, Windows XP x64 Professional, and Windows 7 RC.

And I upgraded from Jaunty once, but since then have been reinstalling Karmic since Alpha 6 was released, and I believe I've reinstalled it from scratch four times, the last time being last night.

So the problem here is definitely Karmic.

[Martin Pitt (pitti)]

> So I hope you can understand that I've tried all kinds of media

OK, thanks for confirming.

So it would be great if you could do another test to see whether the problem is in the kernel or in user space: can you please install the jaunty kernel again from

  http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux-image-2.6.28-15-generic_2.6.28-15.52_amd64.deb

(clicking will invoke gdebi, which should work) and select that in the grub menu? (Press shift during boot to get the menu, it's hidden by default). If you run karmic under the jaunty kernel, do you still get the bug?

Thanks!

[muncrief (rmuncrief)]

Excellent idea, but I have to get some sleep now (it's 2:30AM here), but I'll do it first thing after I get up and report back ASAP.

[muncrief (rmuncrief)]

OK, I installed the Jaunty kernel as requested with no problem. Unfortunately, and surprisingly, it worked the same as the Karmic kernel. None of my media will automount, and once I open and then close the tray without media it locks up. I even saw the same USB errors during boot, which also surprised me. I thought they were caused by the Karmic kernel but I guess not. However, I don't have any problems with any of my USB devices so this is not an issue.

After this I wanted to do a sanity check so I restored my Jaunty installation (I use SystemRescueCD and have my user data on a separate partition so I can quickly switch operating systems) and all the CD and DVD media works great. There are simply no problems with my ODD drive under Jaunty, so something is definitely wrong with Karmic.

I'm going to do a clean install of the Karmic beta now and I'll report back when I'm done. I know this is a frustrating problem, but hang in there and I will be happy to continue to run any tests you need. I see that there are a lot of people with ODD problems under Karmic, while others have no problem at all, so this appears to be a serious issue that needs to be worked out before the final Karmic release.

It will only take me a few hours to install the Karmic beta and after that it might be useful to run tests under Jaunty and Karmic and see what the difference is. Other than that I don't have any suggestions and how to proceed with the debugging, but you're the dev and I'm sure you'll think of an effective strategy!

[muncrief (rmuncrief)]

Wow, a lot of people must be trying to download the beta. I tried direct and torrent downloads and they both would take a day or more. So I'm going to keep Jaunty installed for now because I don't think installing alpha 6 again would change anything. So if you want me to run any tests on Jaunty or the Karmic installation I already have (it's completely up to date anyway, I was just going to clean install the beta just in case it might clean up any alpha errors) let me know.

[muncrief (rmuncrief)]

OK, I did a clean beta install and still have the same problems. Just let me know what to try next.

[Martin Pitt (pitti)]

If the jaunty kernel has the same problem, that's an interesting finding, thanks! So the next thing I'd like to try is to check if one of the udev probing programs causes this. So let's disable as much as possible (but let the system still boot):

  cd /lib/udev/rules.d
  sudo mv 60-cdrom_id.rules{,.disabled}
  sudo mv 75-cd-aliases-generator.rules{,.disabled}
  sudo mv 95-devkit-disks.rules{,.disabled}

Then please reboot and see if you can mount CDs manually (sudo mount /dev/sr0 /mnt) and if blkid works again (blkid -p /dev/sr0). If it now works, then we scored! In this case, please rename the rules above back from .rules.disabled to .rules one after another to find out the culprit.

If it still doesn't work, I'll attach a stripped down 60-persistent-storage.rules which will avoid touching the CD.

   sudo cp 60-persistent-storage.rules{,.orig}
   sudo cp /where/you/downloaded/60-persistent-storage.rules .

and the same reboot/test cycle again.

[Martin Pitt (pitti)]

stripped down 60-persistent-storage.rules

[muncrief (rmuncrief)]

No, I think you misunderstood, the drive works perfectly with Jaunty. It only has problems under Karmic. In fact a gnome-vfs crash just occurred and apport generated an automatic bug report with all kinds of trace data. It's bug #440427. Hopefully you can look at the data and see what happened.

Would you still like me to try the rules changes? If so just let me know and I'll do it tomorrow. It's 1:00AM and I've got to get some sleep now.

[muncrief (rmuncrief)]

Oh wait, I see what you mean. It did fail with the Jaunty kernel under Karmic. Sorry, it's getting late and I'm not thinking straight :)

In any case after reviewing the apport bug data if you still want me to try the rules changes I'll do it tomorrow. Good night for now.

[Martin Pitt (pitti)]

the gnome-vfs crash should be fairly irrelevant in this bug context (GNOME does not even use gnome-vfs any more, since Ubuntu 8.04 "hardy"). So please try the rules changes.

P.S. I'm away from now until Sunday evening, so I can not respond before next Monday. Good luck!

[muncrief (rmuncrief)]

I ran the tests as you requested with all the latest updates and "60-cdrom_id.rules" is the culprit. Whenever its enabled blkid is silent and I can't mount. Note that even with the cdrom_id rules commented out the drive becomes locked after mounting media and then closing the tray with no media in it. However, I can reliably manually blkid, mount, unmount, and eject multiple DVDs and CDs so long as I never close the tray when its empty, because after that it becomes locked and I have to reboot. And of course the physical eject button never works, but I believe that's filed under a different bug.

[Martin Pitt (pitti)]

Great, seems we are homing in to the real problem. With the rules disabled, please boot. Now do

  sudo strace -vv -s 1024 -f -o /tmp/cdrom_id.trace /lib/udev/cdrom_id --debug --export /dev/sda

and copy&paste the output here and attach /var/log/kern.log and /tmp/cdrom_id.trace.

Is mounting broken now? I. e. does above command trigger the problem for you?

[Martin Pitt (pitti)]

Whoops, "sr0", not "sda". Fixed command:

sudo strace -vv -s 1024 -f -o /tmp/cdrom_id.trace /lib/udev/cdrom_id --debug --export /dev/sr0

(this is all one line, by the way; Launchpad breaks it into two)

[muncrief (rmuncrief)]

OK, test done. I first verified I still couldn't blkid or mount with the cdrom_id rules enabled (since a lot of updates have been occurring) and I couldn't, so I disabled the rules and rebooted and was able to blkid/mount. Then I ran the trace you requested, but was still able to blkid/mount after them (I think we were hoping I wouldn't be able to). I've attached the trace and kernel log.

[muncrief (rmuncrief)]

I just got home an updated and rebooted and my ODD drive works perfectly now!. I don't know what you devs did, but it sure worked for me. Thank you very much.

You can close this bug unless someone else is still having problems.

[Martin Pitt (pitti)]

I very much suspect that bug 438065 was the culprit for most, if not all, of these problems. Unfortunately I only learned about that one yesterday, so I couldn't mark it as a duplicate right away and had to torture you with all these debugging steps.

But I'm glad it's resolved now, thanks for your report!