|
Bugzilla – Full Text Bug Listing |
| Summary: | losetup --partscan won't create partition devices | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Michal Koutný <mkoutny> |
| Component: | Kernel | Assignee: | systemd maintainers <systemd-maintainers> |
| Status: | RESOLVED UPSTREAM | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | jcheung, sbrabec |
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| See Also: | https://bugzilla.suse.com/show_bug.cgi?id=1170794 | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Bug Depends on: | |||
| Bug Blocks: | 1170048 | ||
The trigger are the two kernel patches that fixed "locking": > d3ef5536274f ("block: fix busy device checking in blk_drop_partitions") > cb6b771b05c3 ("block: fix busy device checking in blk_drop_partitions again") losetup isn't "atomic" operation: > strace -e ioctl losetup --find --show --partscan ~/image.0.raw > (1) ioctl(3, LOOP_CTL_GET_FREE) = 1 > ioctl(4, LOOP_SET_FD, 3) = 0 > (2) ioctl(4, LOOP_SET_STATUS64, {lo_offset=0, lo_number=0, lo_flags=LO_FLAGS_PARTSCAN, lo_file_name="/home/mkoutny/image.0.raw", ...}) = 0 Somewhere between (1) and (2) uevent is triggered and udevd opens the device and (2) fails. Note that ioctl apparently succeeds (EBUSY is swallowed in kernel). TBH, I don't know what a good fix would be. Perhaps udevd being more careful when processing loop uevents? (I'm reassigning to systemd-maintainers, CCing util-linux maintainer). Also keyword: mkosi *** Bug 1170048 has been marked as a duplicate of this bug. *** *** Bug 1170049 has been marked as a duplicate of this bug. *** (In reply to Michal Koutný from comment #1) > Also keyword: mkosi A workaround FWIW https://github.com/systemd/mkosi/compare/master...Werkov:workaround-losetup FTR. since this happens in RC kernel, I've looped in author of the changes [1] to get more information. [1] https://lore.kernel.org/lkml/20200423110738.GA102241@blackbook/ This is being resolved in upstream [1], closing. [1] https://lore.kernel.org/linux-block/20200428085203.1852494-1-hch@lst.de/ |
## Environment kernel-default-5.7.rc1-1.1.g84ddad4.x86_64 systemd-244-3.1.x86_64 util-linux-2.35.1-1.1.x86_64 ## Expected behavior image.0.raw is a whole dist image file # losetup --find --show --partscan ~/image.0.raw would created devices for the image plus the partitions /dev/loop0 /dev/loop0p1 /dev/loop0p2 ## Actual behavior # losetup --find --show --partscan ~/image.0.raw creates only the top device /dev/loop0 > Apr 20 16:54:30 blackbook kernel: loop_reread_partitions: partition scan of loop2 (/home/mkoutny/image.0.raw) failed (rc=-16) ## Observation - this started happening after upgrade of kernel-default (from 5.6.0-rc7-1.g0801cd7-default) or util-linux (from 2.34-4.4) - SIGSTOPping udevd during losetup call allows the scan to succeed