I'd like to disable my CD/DVD drive so that it doesn't spin up every time I select Save in my Kate editor, or select a file-accessing action in other applications. The spinning up just delays what I'm doing, and I'm not even using the DVD drive. I want to leave the CD in the drive, and not have it spin up. I found a website that said a udev rule will definitely disable the drive. So far, I've tried the following 2 rules (separately), but neither of them disable the DVD drive (it still spins up - even when not mounted):

ENV{ID_SERIAL}=="PIONEER_DVD-RW_DVRTD11RS_SAC1009942", ENV{UDISKS_IGNORE}="1"

KERNEL=="sr0",ENV{UDISKS_IGNORE}="1", RUN+="/bin/touch /home/peter/udev-rule-ran"

The RUN+ in the second instance, creates my test file "udev-rule-ran", so this tells me that my rule file is being executed, and that the rule line is being run. ## My Question: Could you tell me what I should be doing to definitely disable the darned DVD drive? I also want to be able to enable the drive again on the occasions that I need it. ## Supplementary Details: I'm trying very hard to write a udev rule to disable my CD/DVD drive. I've tried various non-udev methods to disable it but none of them work. There is no loaded module¹⁾ for the drive that I can unload, so I can't use that method to disable the drive. *¹⁾ So I think the driver must be compiled into the kernel.*

I'm attempting to do raw reads of an old magneto-optical disk in Debian 10 (I can do this in Windows without issues) I was expecting linux to add the disk as /dev/hd*n* or /dev/sd*n*, but it appears to be seeing it as a cdrom (/dev/sr*n*). Here's the relevant lines from dmesg: [ 22.112062] scsi host33: Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0 aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs [ 37.472036] scsi host36: Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0 aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs [ 38.764112] scsi 36:0:5:0: WORM LMS LD 1200E SCSI 0183 PQ: 0 ANSI: 1 [ 38.780029] scsi target36:0:5: Beginning Domain Validation [ 38.801822] scsi target36:0:5: Ending Domain Validation [ 41.134286] sr 36:0:5:0: [sr1] scsi-1 drive [ 41.134456] sr 36:0:5:0: Attached scsi CD-ROM sr1 [ 41.134516] sr 36:0:5:0: Attached scsi generic sg2 type 4 [ 41.178402] sr 36:0:5:0: [sr1] unsupported sector size 1024. [ 41.312627] PM: Image not found (code -22) when I attempt to read from /dev/sr1 using dd bs=1024 if=/dev/sr1 I get 0 records; presumably because /dev/sr1 doesn't accept a 1024 byte block size, but I know that is what the M/O disk is using. Incidentally, cat /proc/scsi/scsi results in: Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: VMware Model: Virtual disk Rev: 2.0 Type: Direct-Access ANSI SCSI revision: 06 Host: scsi2 Channel: 00 Id: 00 Lun: 00 Vendor: NECVMWar Model: VMware SATA CD00 Rev: 1.00 Type: CD-ROM ANSI SCSI revision: 05 Host: scsi36 Channel: 00 Id: 05 Lun: 00 Vendor: LMS Model: LD 1200E SCSI Rev: 0183 Type: WORM ANSI SCSI revision: 01 is there a way to make linux create a /dev/sd*n* device file for it rather than a /dev/sr*n*?

I have a CD image file which has AARUF as its filename extension and I want to access its files. Using file, I don't get any further information about the format: $ file image.aaruf image.aaruf: data $ Trying to mount the image with fuseiso results in errors: > init: wrong standard identifier in volume descriptor 0, skipping.. > init: wrong standard identifier in volume descriptor 1, skipping.. > init: wrong standard identifier in volume descriptor 2, skipping.. > init: wrong standard identifier in volume descriptor 3, skipping.. > init: wrong standard identifier in volume descriptor 4, skipping.. > init: wrong standard identifier in volume descriptor 5, skipping.. > init: wrong standard identifier in volume descriptor 6, skipping.. > init: wrong standard identifier in volume descriptor 7, skipping..

I am trying to establish a uni-directional Ethernet link where a singular fiber is used to transmit data to the receiver. The Rx of the transmit side and the Tx of the receive side are not physically connected, like in a Data diode scenario. The problem is, as soon as I detach the tx line from one side, both side link status goes DOWN. can anyone give advice to overcome this problem? do I need to change the Linux SFP driver to mask link status as always UP?

I have some retail Blu-Ray movies with DRM that I want to watch on my Linux desktop. I want to watch the movie directly from the disc. Tutorials I found online tell me how to rip it to a file, but I don't want to use up that much hard drive space when I will only watch the movie a few times. How can I do this?

My slot-loading optical drive (HP BDDVDRW CA21N) spins and up and then ejects every disc, a process that takes about 15 seconds. I've found lots of posts on enabling wanted ejects, but close to nothing on avoiding unwanted ones. I have tried commenting out the relevant line in

/etc/fstab

, and using

sysctl dev.cdrom.lock=1

, both making no change.

/sys/bus/scsi/devices/0\:0\:0\:0/device_b*

seems to always contain zeroes. Further system information follows:

brick@dowland:~$ uname -a
Linux dowland 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30) x86_64 GNU/Linux

brick@dowland:~$ sudo modprobe sr_mod

brick@dowland:~$ sudo dmesg
...
[4251487.063009] sr 0:0:0:0: [sr0] scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw xa/form2 cdda tray
[4251487.093385] debugfs: Directory 'sr0' with parent 'block' already present!
[4251487.093465] sr 0:0:0:0: Attached scsi CD-ROM sr0

brick@dowland:~$ lsscsi --long
[0:0:0:0]    cd/dvd  hp       BDDVDRW CA21N    C2S2  /dev/sr0 
  state=running queue_depth=1 scsi_level=6 type=5 device_blocked=0 timeout=30

brick@dowland:~$ cat /sys/bus/scsi/devices/0\:0\:0\:0/state
running

brick@dowland:~$ cat /sys/bus/scsi/devices/0\:0\:0\:0/uevent 
DEVTYPE=scsi_device
DRIVER=sr
MODALIAS=scsi:t-0x05

brick@dowland:~$ cat  /proc/sys/dev/cdrom/info 
CD-ROM information, Id: cdrom.c 3.20 2003/12/17

drive name:		sr0
drive speed:		24
drive # of slots:	1
Can close tray:		1
Can open tray:		1
Can lock tray:		1
Can change speed:	1
Can select disk:	0
Can read multisession:	1
Can read MCN:		1
Reports media changed:	1
Can play audio:		1
Can write CD-R:		1
Can write CD-RW:	1
Can read DVD:		1
Can write DVD-R:	1
Can write DVD-RAM:	1
Can read MRW:		1
Can write MRW:		1
Can write RAM:		1

Thank you for reading this far! What else should I look at?

I want to use 100GB M-Disc for Backup. How can one determine whether the M-Disc Writing was engraved properly and successfully on the non-volatile substance? I plan to use Brasero for writing. What does one have to do, burn with brasero and everything is figured out automatically when you insert an M-Disc? I have just got a Pioneer BDR-XS07S Blu-Ray Burner. I am using Ubuntu 20.04 LTS.

Burning a BIN/CUE image to a CD is pretty easy using cdrdao write --speed 1 --device /dev/sr0 path/to/image.cue , but I can't find any way to verify the burn afterwards. I'm used to Windows utilities like ImgBurn which can read back the disk after the burn is complete to check for errors. The common advice to use cmp /dev/cdrom path/to/image.iso or to compare checksums doesn't work, especially if there's more than one BIN file. Using grep to search for the reference bin file within a dump consumes too much memory—on my system, even with a CD, I run out of memory and the process is killed. Is there a simple way to do this on Linux? ---------- Partial solution : ------------------------- Mount the image as a virtual disk with cdemu load any path/to/image.cue, dump each with cdrdao read-cd --read-raw --device /dev/srX --datafile path/to/dataX.bin path/to/imageX.toc, and compare with cmp path/to/data1.bin path/to/data2.bin && echo "OK!". (Simply using cmp /dev/sr0 /dev/sr1 does not work, so they must be dumped to a temp location first.) Unfortunately, while this worked for the first image I tested, it does not work for any others that I have tried. The two dumps will come out different, producing a false negative, even in the following scenarios: - Repeating the dump yields the same checksum, which rules out a random read error. - Verifying a commercial CD (one that I did not burn myself) against a dump obtained through the internet also fails verification, which rules out a random write error. - A disk burned and successfully verified with ImgBurn on Windows also fails this verification procedure, which rules out any true data corruption (as long as we trust ImgBurn's verification procedure). So, it's probably due to some alignment/padding issue, resulting in a non-bit-perfect copy. This isn't an issue for actually using the burned media, but it will defeat a simple comparison using cmp.

I'm using a 16-to-18-years-old laptop, a Clevo Zeus M3CW, on which I recently installed antiX Linux 19.3. The kernel version is 4.9.235 (compiled for 486). Now, whenever I boot, the kernel complains about I/O errors from device /dev/sr0 - my laptop's built-in CD-ROM. This is what lsblk says about the device:

# lsblk -o +VENDOR,MODEL | head -1 ; lsblk -o +VENDOR,MODEL | grep sr0
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT VENDOR   MODEL
sr0     11:0    1  1024M  0 rom             TEAC     DW-224E-A

The drive is empty - no CD in there. Later while the system runs, I get innumerable dmesg entries such as the following:

[   53.250051] sr 1:0:0:0: [sr0] tag#0 unaligned transfer
[   53.250056] sr 1:0:0:0: [sr0] tag#0 unaligned transfer
[   53.250066] sr 1:0:0:0: [sr0] tag#0 unaligned transfer
[   53.250071] sr 1:0:0:0: [sr0] tag#0 unaligned transfer
[   53.250076] sr 1:0:0:0: [sr0] tag#0 unaligned transfer

and also this:

[   53.312725] REISERFS warning (device sr0): sh-2006 read_super_block: bread failed (dev sr0, block 16, size 512)
[   53.312746] sr 1:0:0:0: [sr0] tag#0 unaligned transfer
[   53.312754] REISERFS warning (device sr0): sh-2006 read_super_block: bread failed (dev sr0, block 128, size 512)
[   53.359602] sr 1:0:0:0: [sr0] tag#0 unaligned transfer
[   53.359617] EXT4-fs (sr0): unable to read superblock
[   53.405593] sr 1:0:0:0: [sr0] tag#0 unaligned transfer
[   53.405606] EXT4-fs (sr0): unable to read superblock
[   53.464594] sr 1:0:0:0: [sr0] tag#0 unaligned transfer
[   53.464608] EXT2-fs (sr0): error: unable to read superblock
[   53.533449] sr 1:0:0:0: [sr0] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[   53.533461] sr 1:0:0:0: [sr0] tag#0 Sense Key : Medium Error [current] 
[   53.533478] sr 1:0:0:0: [sr0] tag#0 Add. Sense: Unable to recover table-of-contents
[   53.533490] sr 1:0:0:0: [sr0] tag#0 CDB: Read(10) 28 00 00 00 00 00 00 00 02 00
[   53.533516] SQUASHFS error: squashfs_read_data failed to read block 0x0
[   53.533528] squashfs: SQUASHFS error: unable to read squashfs_super_block

and these:

[ 2852.951421] sr 1:0:0:0: [sr0] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 2852.951431] sr 1:0:0:0: [sr0] tag#0 Sense Key : Medium Error [current] 
[ 2852.951444] sr 1:0:0:0: [sr0] tag#0 Add. Sense: Unable to recover table-of-contents
[ 2852.951453] sr 1:0:0:0: [sr0] tag#0 CDB: Read(10) 28 00 00 07 ff fc 00 00 02 00
[ 2852.951458] blk_update_request: 1680 callbacks suppressed
[ 2852.951462] blk_update_request: I/O error, dev sr0, sector 2097136
[ 2852.951509] sr 1:0:0:0: [sr0] tag#0 unaligned transfer
[ 2852.951514] blk_update_request: I/O error, dev sr0, sector 2097136
[ 2852.951521] buffer_io_error: 1670 callbacks suppressed
[ 2852.951525] Buffer I/O error on dev sr0, logical block 2097136, async page read
[ 2852.951540] sr 1:0:0:0: [sr0] tag#0 unaligned transfer
[ 2852.951544] blk_update_request: I/O error, dev sr0, sector 2097137
[ 2852.951550] Buffer I/O error on dev sr0, logical block 2097137, async page read
[ 2852.951563] sr 1:0:0:0: [sr0] tag#0 unaligned transfer

I should also note that if I insert a CD, it automounts and reads fine. My questions: 1. What makes the kernel try to read from /dev/sr0 all the time? Especially on boot, when it's not in /etc/fstab nor mentioned in the grub configuration. 2. How can I make the kernel give up on this device? From the get-go or after failing a few times?

A couple of months ago I installed Windows 10 version 1909 in a Linux Mint 19.1 (Tessa) QEMU/KVM guest. Using USB Redirect (aka USB Redirection, virsh attach), a USB to SATA bridge is connected to a SATA optical drive to read discs. Approximately once an hour, Linux would reset the USB device causing a delay (a few minutes) in reading the disc from Windows 10: usb 1-1.6: reset high-speed USB device number 8 using ehci-pci Approximately once every two hours, Linux would disconnect the USB device killing the disc read from Windows 10: usb 1-1.6: USB disconnect, device number 8 Multiple drives, USB to SATA bridges, cables, power supplies, and discs were tested. It's not a hardware issue or disc issue. For comparison, using this same Linux Mint 19.1 QEMU/KVM host with a Windows 7 guest and the same optical disc (or any optical disc) is free of issues.

I cannot mount a DVD, most probably because it is blank, so it contains no filesystem. Is there a way to be sure that the disk is blank?

I'm putting together a quick-and-dirty script to read 100s of CD/DVDs onto a NAS. It takes care of ejecting and loading the tray, but I haven't figured out a simple way to wait/block for the medium to become available to the OS after inserting the tray. - eject -t exits as soon as the tray closes - mount will fail with *No medium found* if it's run immediately after eject, but also when it's run 15 seconds later. The discs are fairly old and some take considerable time to become available, so I'd like to avoid the "sleep for 2 minutes" non-solution. Any ideas? Using ubuntu 18.04.

Let's say that I set the block size of dd or ddrescue to 256K. A sector of flash drives usually has 512 bytes, a sector on optical data discs has 2048 bytes. Let's assume that in the next 256 KB, **just one sector is unreadable.** Every other sector is readable. ### What happens to the multiblock transfer? * Does it transfer anything at all? * Does it transfer the readable parts as usual? It would be great if it did transfer **all readable blocks** as usual.

How can I see the Windows attributes on optical discs? Examples: * Hidden. * Read-Only. * System file. The ACL tools on Linux still do not display the _hidden_ attribute for instance.

I've seen this behavior across distros (probably across operating systems, too) and across optical-media drive makes/models. It appears any CD, DVD, and/or Blu-Ray drive, if an attempt is made to open() /dev/sr0 while the tray is open, the tray will close, and until it is finished closing the call to open() will block. Once the tray finishes closing, the drive enters an "identification" state in which will attempt to determine what type of media is in it (whether there's a CD, DvD, Blu-Ray, or something else in it, and therefore which laser it should use), which usually takes a few seconds, during which any calls to open() on the device (including the call that caused the tray to close in the first place) will fail with a no media error. Put another way: 1. The CD tray is opened and a disc is put in by the user. 2. Some command is run that will open /dev/sr0 for reading or writing (e.g. mount, dd, dvdbackup etc.) 3. The CD tray will close itself, and the command will block until the tray has closed all the way. 4. Once the tray finishes closing, the command immediately reports no media and exits. The drive begins to identify the newly-loaded media. 5. The user tries to run the command again before the identification phase is complete (during which some "media present" flag is evidently not set). The command fails instantaneously with the same No Media error. 6. After a few seconds, the drive is ready to read the media. 7. The user runs the command a third time. This time the command succeeds. My theory as to what's happening (this is only a theory): 1. During step 2 of the above, Linux makes a request to the drive. The drive sees that its tray is open, and closes it. 2. The tray finishes closing, and the drive reports to the operating system that it has entered an identification phase, probably by setting some "busy" flag and clearing "media present" or what have you. 3. Linux, seeing that the "media present" flag is clear, immediately reports to the application that there is nothing for it to do. My first question is, why does this happen? Why doesn't Linux check the busy flag? Windows does (or at least it looks like it does; in some versions a CD icon appears next to the cursor during this identification phase). My second question is, is there any way around this? Is there any way to know, without completely bypassing the kernel, if the DVD drive is in the identification phase or if there really is no media in it?

If the PC sends a request to read a sector on an optical disc, which turns out to be unreadable, the drive deadlocks the program into responselessness and motionlessness, until it returns the sector or an error. During the time the program is locked by the drive, which makes the program effectively a slave, how can I see the pending SCSI request with details such as read retry count and requested LBA?

# Summary My laptop's optical drive stopped reading discs a while ago, but I'm never given an error; I want to figure out what exactly is wrong with my optical drive. # Background This is a Toshiba Satellite laptop with Fedora 27. dmesg identifies the drive as MATSHITA DVD-RAM UJ8E2. # Details I noticed the drive stopped reading some time ago after traveling. It may have taken shock damage then, but I'm not sure since I only read CDs/DVDs occasionally (so I don't have an accurate timeline for when it stopped working). When a disc is inserted, I hear the optical drive spin and it sounds like some data is read, but my system never acknowledges that a disc is there. Eventually, the drive spins down. # Linux commands to troubleshoot? I found some older questions, but they were about verifying the integrity of the actual disc media, not the drive itself. Are there any tools to help me debug / figure out the point of failure on an optical drive?

I have a video DVD that I'm trying to extract but that is very hard to read (takes several days and not finished). **Is there any way to find out if the problem is a physical damage of the surface of the optical disc, or some corruption in the file system?** I'm asking because the disc has no visible physical damages, and I want to take proper action in the continued tries to extract it data. E g need to know if a polishing of the surface of the disc might help.

I have a DVD that I can't rip or copy using regular commands. If I try to copy it it will first copy at normal speed, but then slow down and take a very long while to do seemingly nothing. Right now I'm trying to extract whatever data there is using dd to make a .iso-image of it. I use the following command: dd if=/dev/sr0 of=image.iso bs=2048 conv=noerror,notrunc iflag=nonblock noerror: continue after read errors notrunc: do not truncate the output file nonblock: use non-blocking I/O Now the extraction has come to the difficult part and I get messages like the one below all the time: dd: error reading ‘/dev/sr0’: Input/output error 486221+0 records in 486221+0 records out 995780608 bytes (996 MB) copied, 76031,9 s, 13,1 kB/s It ticks up a few bytes for each minute. As you can see this has been going on for a while now ... **So my question is: What is my computer doing now?** The drive slowed down, but is still able to extract some data (the byte counts increases)? Does the lower speed make it easier to read the data, or is the drive just trying to read the same data over and over until it gets some of it? **What is happening?** :)