Bug 1825533

Summary: blkid hangs when Movie DVD is in USB drive
Product: [Fedora] Fedora Reporter: Tom Horsley <horsley1953>
Component: util-linuxAssignee: Karel Zak <kzak>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 31CC: jonathan, kzak, y9t7sypezp
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-11-24 17:34:17 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Tom Horsley 2020-04-18 17:45:24 UTC
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.

Comment 1 Steve 2020-04-18 18:32:13 UTC
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

Comment 2 Steve 2020-04-18 18:54:36 UTC
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)

Comment 3 Steve 2020-04-19 22:28:35 UTC
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

Comment 4 Steve 2020-04-19 22:52:38 UTC
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
...

Comment 5 Ben Cotton 2020-11-03 16:37:26 UTC
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.

Comment 6 Ben Cotton 2020-11-24 17:34:17 UTC
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.

Comment 7 EmmaKutch 2024-05-30 08:59:28 UTC Comment hidden (spam)
Comment 8 EzraFeil 2024-12-17 07:18:05 UTC Comment hidden (spam)