Bug 2026511
| Summary: | blkid fails to complete when targeting non-block devices | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Nathaniel Weddle <nweddle> |
| Component: | util-linux | Assignee: | Karel Zak <kzak> |
| Status: | CLOSED ERRATA | QA Contact: | Radka Brychtova <rskvaril> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 8.5 | CC: | loberman, rskvaril, swachira |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | util-linux-2.32.1-31.el8 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-05-10 15:30:52 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: | |||
I'd like to amend my initial expectation here as the RC's are probably only specific to block devices. There is no way for blkid to force a device to issue and RC. Maybe adding a timeout so that if blkid ioctl goes without a response from kernel for some time, it prints a timeout failure on the device and drops to command prompt or continues with the next device if multiple devices are being queried. How this presented here was this. The customer ran blkid /dev/* and hit the non block device, /dev/port file. This crashes a VMware guest so we told them its not a good idea to run this the way they did. Nathan was able to also show that /dev/hidraw0 hangs when touched. The idea here is to maybe change blkid such that if a wildcard is presented, its only block devices that get probed and the others are ignored. Seem like a simple change as we already have the file names and check the file type to see if its a block device. Regards Laurence blkid (libblkid) supports block devices, regular files, and char devices (UBI devices). I have added (in the upstream tree) patches to libblkid and blkid(8) to be more careful with devices before it starts to read it. https://github.com/util-linux/util-linux/commit/ab5304a7a34bfa45d9bee205ca4e26f03db6e79d https://github.com/util-linux/util-linux/commit/7eb6d9ce4526b968e30f7e538cbbbdf9938e5891 https://github.com/util-linux/util-linux/commit/64cfe6ac37631a6347bd4005c72dd2d37e737f5e but I'm not sure if this is so important that we need to backport it to RHEL-8. What do you think? Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (util-linux bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2022:2100 |
Description of problem: Running blkid and tareting non-block device fails to complete (no RC). I've specifically noted this failure against /dev/hipraw devices. I've not reproduced against any other devices I've tried but it's possible I've missed some. Per man page: ~~~ RETURN CODE If the specified device or device addressed by specified token (option --match-token) was found and it's possible to gather any information about the device, an exit code 0 is returned. Note the option --match-tag filters output tags, but it does not affect return code. If the specified token was not found, or no (specified) devices could be identified, or it is impossible to gather any information about the device identifiers or device content an exit code of 2 is returned. For usage or other errors, an exit code of 4 is returned. If an ambivalent probing result was detected by low-level probing mode (-p), an exit code of 8 is returned. ~~~ Version-Release number of selected component (if applicable): util-linux-2.32.1-24.el8.x86_64 and earlier How reproducible: # blkid /dev/hipraw* Actual results: Have to interrupt (ctrl+c) to return to command prompt Expected results: exit code of 2 is returned (if I'm readin the man page correctly) and drops to command prompt. Additional info: Initial issue was found because CU ran: # blkid /dev/*