On 09/01/2014 09:41 PM, Dale R. Worley wrote: >> From: Francis Moreau <francis.moro@xxxxxxxxx> > >> Right after associating a loop device with a disk image file, I'm using >> lsblk to retrieve some info about the partitions. >> >> If I'm doing this as root: >> >> $ losetup /dev/loop0 /tmp/installer-disks/disk0.img && lsblk -n --raw >> --paths -o NAME,PARTTYPE /dev/loop0 && losetup -d /dev/loop0 >> >> then the output is missing the parttypes: >> >> /dev/loop0 >> /dev/loop0p1 >> /dev/loop0p2 >> >> However adding a sleep or 'udevadm settle' after setting the loop device >> the parttypes are correctly showed: > > It looks like the process of determining the partitions is > asynchronous, and is not assured of being completed when losetup > returns. Still lsblk lists the partitions. I'm not sure how lsblk works. It seems that it relies on udev to get certain information, parttype is an example but doesn't for listing partitions of block devices. That seems to make the whole process racy. If this is correct, I'm wondering why lsblk relies on udev to retrieve block device metadata. Can't it find them out directly from the kernel ? > > What happens when you add -P to losetup? The manual page (for Fedora > 19) says "force kernel to scan partition table on newly created loop > device", which suggests that the partition scan will be completed by > the time losetup returns. Adding -P doesn't help. Actually the kernel correctly detected the partitions embedded in the loop device. But udev hasn't handled the associeted events yet when lsblk is called. Thanks -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
