Description of problem: A near infinite amount of information can be found in bug 1822948, but it comes down to a sata optical drive in a USB external enclosure causes a hang when an attempt is made to read an encrypted block in a Movie DVD. All the apps that know how to read Movies don't do that. They look at headers and such to determine it is a DVD before going off and reading arbitrary blocks. The blkid tool, on the other hand, seems more like a bull in a china shop, just reading all kinds of data without noticing it is a DVD first. It would be nice for it to pay more attention to the kind of media before going berserk. Because blkid is invoked by udev rules as soon as media is loaded, the drive is rendered useless right away. Don't know if the hang is a kernel problem or a firmware problem. A kernel bug was submitted here: https://bugzilla.kernel.org/show_bug.cgi?id=207327 But it would be nice if blkid wouldn't trigger the error in the first place. Version-Release number of selected component (if applicable): util-linux-2.34-4.fc31.x86_64 How reproducible: 100 percent with a new optical drive. Apparently older optical drives don't generate the hardware errors reading encrypted data. Steps to Reproduce: 1.Put encrypted movie DVD in external USB drive 2.Try to run any program that reads it 3.See the program hang Actual results: Hung Expected results: Working normally Additional info: Bug 1822948 documents a couple of ways to work around this. The first test was disabling udev. With udev squashed, the hangs do not happen. The less drastic work around I'm using now is making my own copy of /usr/lib/udev/rules.d/60-persistent-storage.rules into /etc/udev/rules.d/ and changing the optical media rules to goto to the end instead of invoking blkid.
For the record, the specific DVD drive / USB enclosure combination, as reported in Bug 1822948, is: The drive: LG WH16NS40 Super Multi Blue Internal SATA 16x Blu-ray Disc Rewriter The enclosure: OWC Mercury Pro 5.25" Optical Drive External Enclosure The OWC USB enclosure, as reported in Bug 1822948, Comment 52, is: $ fgrep -A7 -n -m1 'usb 4-1' dmesg-4.txt 1065:Apr 15 12:45:36 kernel: usb 4-1: new SuperSpeed Gen 1 USB device number 3 using xhci_hcd 1066-Apr 15 12:45:36 kernel: usb 4-1: New USB device found, idVendor=1e91, idProduct=de2c, bcdDevice= 1.00 1067-Apr 15 12:45:36 kernel: usb 4-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1 1068-Apr 15 12:45:36 kernel: usb 4-1: Product: Mercury Pro Optical 1069-Apr 15 12:45:36 kernel: usb 4-1: Manufacturer: Other World Computing 1070-Apr 15 12:45:36 kernel: usb 4-1: SerialNumber: 002933001438 1071-Apr 15 12:45:36 kernel: usb-storage 4-1:1.0: USB Mass Storage device detected 1072-Apr 15 12:45:36 kernel: scsi host5: usb-storage 4-1:1.0 The manufacturer's tech specs are here. Note that they explicitly mention Linux: OWC Mercury Pro Optical Drive https://www.owcdigital.com/products/mercury-pro-optical#tech-specs
This is a record of the SCSI READ_10s that occurred after a commercial DVD was loaded. The entries terminate at lba=512, because that read hung. The SCSI READ_10s were captured with the kernel's tracing facilities and processed with a custom awk script. The complete log is in Attachment 1679161 [details]: == snipped from Bug 1822948, Comment 57 == systemd-udevd-7136 10101.278369: cmnd=(READ_10 lba=4101504 txlen=2 protect=0 raw=28 00 00 3e 95 80 00 00 02 00) systemd-udevd-7136 10101.516146: cmnd=(READ_10 lba=4101506 txlen=1 protect=0 raw=28 00 00 3e 95 82 00 00 01 00) systemd-udevd-7136 10101.517146: cmnd=(READ_10 lba=0 txlen=2 protect=0 raw=28 00 00 00 00 00 00 00 02 00) systemd-udevd-7136 10101.775259: cmnd=(READ_10 lba=8 txlen=2 protect=0 raw=28 00 00 00 00 08 00 00 02 00) systemd-udevd-7136 10101.776173: cmnd=(READ_10 lba=16 txlen=2 protect=0 raw=28 00 00 00 00 10 00 00 02 00) systemd-udevd-7136 10101.784320: cmnd=(READ_10 lba=32 txlen=2 protect=0 raw=28 00 00 00 00 20 00 00 02 00) systemd-udevd-7136 10101.793401: cmnd=(READ_10 lba=64 txlen=2 protect=0 raw=28 00 00 00 00 40 00 00 02 00) systemd-udevd-7136 10101.826396: cmnd=(READ_10 lba=128 txlen=2 protect=0 raw=28 00 00 00 00 80 00 00 02 00) systemd-udevd-7136 10101.847772: cmnd=(READ_10 lba=256 txlen=2 protect=0 raw=28 00 00 00 01 00 00 00 02 00) systemd-udevd-7136 10101.875658: cmnd=(READ_10 lba=512 txlen=2 protect=0 raw=28 00 00 00 02 00 00 00 02 00)
Even when there is no hanging like that reported in this bug, blkid induces a small flurry of error messages in the system log, even though the user is not doing anything wrong, and there is nothing wrong with the system hardware or software. To make matters more confusing, blkid does not report any errors in the terminal window when it is run from the command-line. Test procedure: In a terminal window, run: $ journalctl --no-hostname -f Load a commercial DVD into a connected DVD drive. If systemd-udevd is enabled, some error messages will be logged. In a separate terminal window, run: $ blkid --probe /dev/sr0 > /dev/null No errors are displayed in the terminal window. However, errors like these are logged. And some are highlighted in red, which usually signifies a serious error: Apr 19 14:57:17 kernel: sr 5:0:0:0: [sr0] tag#20 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s Apr 19 14:57:17 kernel: sr 5:0:0:0: [sr0] tag#20 Sense Key : Illegal Request [current] Apr 19 14:57:17 kernel: sr 5:0:0:0: [sr0] tag#20 Add. Sense: Read of scrambled sector without authentication Apr 19 14:57:17 kernel: sr 5:0:0:0: [sr0] tag#20 CDB: Read(10) 28 00 00 3d bb c0 00 00 40 00 Apr 19 14:57:17 kernel: blk_update_request: I/O error, dev sr0, sector 16183040 op 0x0:(READ) flags 0x80700 phys_seg 32 prio class 0 Apr 19 14:57:17 kernel: sr 5:0:0:0: [sr0] tag#26 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s Apr 19 14:57:17 kernel: sr 5:0:0:0: [sr0] tag#26 Sense Key : Illegal Request [current] Apr 19 14:57:17 kernel: sr 5:0:0:0: [sr0] tag#26 Add. Sense: Read of scrambled sector without authentication Apr 19 14:57:17 kernel: sr 5:0:0:0: [sr0] tag#26 CDB: Read(10) 28 00 00 3d bb e0 00 00 02 00 Apr 19 14:57:17 kernel: blk_update_request: I/O error, dev sr0, sector 16183168 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 Apr 19 14:57:17 kernel: Buffer I/O error on dev sr0, logical block 2022896, async page read
For the record, the systemd-udev package includes its own copy of blkid: $ udevadm test-builtin blkid /sys/class/block/sr0 $ udevadm test-builtin -h udevadm test-builtin [OPTIONS] COMMAND DEVPATH ... Commands: blkid Filesystem and partition probing ...
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
I've noticed that when I insert a Movie DVD into my USB drive, the `blkid` command tends to hang, making it quite frustrating to manage my drives. It's been a recurring issue, and I hope there's a fix soon. By the way, for those who enjoy watching movies and series, you might want to check out the https://m.flixfox.tv/. It's a great app that offers a wide selection of content for streaming.
The Castle App is your entertainment sanctuary. With Castle APK, find your next binge-watch with ease, thanks to its intuitive design. Download the Castle APK for your entertainment needs. https://www.castlecommovies.com/