0

I hope you can help me. I have an external (slim) Blu-Ray Drive, which is connected via USB. Whenever I open the drive, the activity-LED starts blinking fast, and I am unable to close the drive. When I try to close it, the tray is getting ejected immediately. I have to disconnect the USB to be able to close the tray.

This must be software-related problem, because I do not have this problem within Windows. I have Ubuntu 20.04.3 LTS. There is an interesting line inside the syslog:

Sep 14 11:36:07 linux-gurke kernel: scsi 6:0:0:0: CD-ROM PIONEER BD-RW BDR-UD04 1.11 PQ: 0 ANSI: 0 Sep 14 11:36:07 linux-gurke kernel: sr 6:0:0:0: Power-on or device reset occurred Sep 14 11:36:07 linux-gurke kernel: sr 6:0:0:0: [sr0] scsi3-mmc drive: 62x/62x writer dvd-ram cd/rw xa/form2 cdda tray Sep 14 11:36:07 linux-gurke kernel: sr 6:0:0:0: Attached scsi CD-ROM sr0 Sep 14 11:36:07 linux-gurke kernel: sr 6:0:0:0: Attached scsi generic sg2 type 5 Sep 14 11:36:13 linux-gurke kernel: usb 6-1: USB disconnect, device number 4 Sep 14 11:36:13 linux-gurke kernel: scsi 6:0:0:0: rejecting I/O to dead device Sep 14 11:36:13 linux-gurke systemd-udevd[8161]: sr0: Process 'cdrom_id --eject-media /dev/sr0' failed with exit code 1. 

The last line "eject media failed" is being written to syslog as soon as I disconnect the drive. So obviously, some process is trying to issue an eject / close tray command while the tray is open, which obviously cannot work, as it is a slim drive, you have to push the tray manually to close it.

Some information:

$> lsusb -s 006:005 -t /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 10000M |__ Port 1: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, 5000M $> lsusb -s 006:005 Bus 006 Device 005: ID 18a5:0428 Verbatim, Ltd Verbatim 4K BD RW 

Note that, the drive is manufactured by verbatim, but inside the syslog, it appears as a pioneer drive.

I already tried echo 0 > /proc/sys/dev/cdrom/autoclose and echo 0 > /proc/sys/dev/cdrom/autoeject, it did not make a difference. Can you guys help me identify the problem?

5
  • I had a similar problem with my CD drive, in particular after using an audio CD. It turned out the culprit was udisk, which wanted to automatically determine the filesystem, and ended up in a loop. After laboriously figuring out how to disable udisk (wasn't easy), the problem went away. This may or may not be related to your problem. Commented Sep 14, 2021 at 10:24
  • I was using audio-cds lately, so this might be my problem, too - what is udisk, and how can I disable it? Bute note that this problem also occurs when the drive is empty. Commented Sep 14, 2021 at 10:27
  • Yes, the problem also occured if the drive was empty (after I used an audio CD), and udev was also involved, though only in a secondary role - it's the udev rules that trigger udisk. Commented Sep 14, 2021 at 18:42
  • I googled a bit about udisk, and this does not sound like anything you want to disable under usual circumstances... Commented Sep 14, 2021 at 19:14
  • I have a very minimalist desktop, so I guess that counts for "unusual circumstances". Commented Sep 15, 2021 at 7:08

1 Answer 1

1

I have found the bad guy causing the troubles. I noticed that whenever the activity LED was blinking fast, systemd-udevd was active with around 3% cpu time. This lead me to issuing the command udevadm monitor -u while inserting the CD and pressing the eject button (I marked the moment when I pressed the button with the press line):

$> udevadm monitor -u monitor will print the received events for: UDEV - the event which udev sends out after rule processing UDEV [6294.187246] change /devices/pci0000:00/0000:00:08.1/0000:2d:00.3/usb6/6-1/6-1:1.0/host6/target6:0:0/6:0:0:0/block/sr0 (block) press UDEV [6319.266413] change /devices/pci0000:00/0000:00:08.1/0000:2d:00.3/usb6/6-1/6-1:1.0/host6/target6:0:0/6:0:0:0/block/sr0 (block) UDEV [6319.393838] change /devices/pci0000:00/0000:00:08.1/0000:2d:00.3/usb6/6-1/6-1:1.0/host6/target6:0:0/6:0:0:0/block/sr0 (block) UDEV [6319.481907] change /devices/pci0000:00/0000:00:08.1/0000:2d:00.3/usb6/6-1/6-1:1.0/host6/target6:0:0/6:0:0:0/block/sr0 (block) UDEV [6319.574832] change /devices/pci0000:00/0000:00:08.1/0000:2d:00.3/usb6/6-1/6-1:1.0/host6/target6:0:0/6:0:0:0/block/sr0 (block) UDEV [6319.672829] change /devices/pci0000:00/0000:00:08.1/0000:2d:00.3/usb6/6-1/6-1:1.0/host6/target6:0:0/6:0:0:0/block/sr0 (block) UDEV [6319.770823] change /devices/pci0000:00/0000:00:08.1/0000:2d:00.3/usb6/6-1/6-1:1.0/host6/target6:0:0/6:0:0:0/block/sr0 (block) UDEV [6319.868807] change /devices/pci0000:00/0000:00:08.1/0000:2d:00.3/usb6/6-1/6-1:1.0/host6/target6:0:0/6:0:0:0/block/sr0 (block) UDEV [6319.966829] change /devices/pci0000:00/0000:00:08.1/0000:2d:00.3/usb6/6-1/6-1:1.0/host6/target6:0:0/6:0:0:0/block/sr0 (block) UDEV [6320.064811] change /devices/pci0000:00/0000:00:08.1/0000:2d:00.3/usb6/6-1/6-1:1.0/host6/target6:0:0/6:0:0:0/block/sr0 (block) UDEV [6320.163830] change /devices/pci0000:00/0000:00:08.1/0000:2d:00.3/usb6/6-1/6-1:1.0/host6/target6:0:0/6:0:0:0/block/sr0 (block) 

those change events kept apearing until I disconnected the device. After a little bit of research, I found the file /lib/udev/rules.d/60-cdrom_id.rules, which contained the line:

# media eject button pressed ENV{DISK_EJECT_REQUEST}=="?*", RUN+="cdrom_id --eject-media $devnode", GOTO="cdrom_end" 

Remember the error which showed up in the syslog? I copied the file to /etc/udev/rules.d and changed the line to

ENV{DISK_EJECT_REQUEST}=="?*", GOTO="cdrom_end" 

This immediately fixed my problem, although it created another: when pressing the eject button, nothing happened. But issuing an eject command with eject /dev/sr0 worked, without the drive going crazy. (This command previously had the same effect like pressing the hardware eject button!)

This might be a bug inside the udev package, Although I cannot be sure of that. And my "fix" surely is only a workaround - something is creating the endless source of udev events which obviously is causing an immediate media eject, as soon as the tray is closed...

Maybe this is helpful for anybody else running inside this problem!

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.