Bug 1169932 - losetup --partscan won't create partition devices
losetup --partscan won't create partition devices
: 1170048 1170049 (view as bug list)
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Kernel
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: systemd maintainers
E-mail List
Depends on:
Blocks: 1170048
  Show dependency treegraph
Reported: 2020-04-20 15:06 UTC by Michal Koutný
Modified: 2020-06-03 09:49 UTC (History)
2 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Michal Koutný 2020-04-20 15:06:32 UTC
## Environment


## 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

## 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
Comment 1 Michal Koutný 2020-04-20 16:01:20 UTC
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

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
Comment 2 Michal Koutný 2020-04-21 09:57:26 UTC
*** Bug 1170048 has been marked as a duplicate of this bug. ***
Comment 3 Michal Koutný 2020-04-21 09:58:51 UTC
*** Bug 1170049 has been marked as a duplicate of this bug. ***
Comment 4 Michal Koutný 2020-04-22 10:29:01 UTC
(In reply to Michal Koutný from comment #1)
> Also keyword: mkosi
A workaround FWIW
Comment 5 Michal Koutný 2020-04-23 11:09:42 UTC
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/
Comment 6 Michal Koutný 2020-04-28 10:25:40 UTC
This is being resolved in upstream [1], closing.

[1] https://lore.kernel.org/linux-block/20200428085203.1852494-1-hch@lst.de/