Re: losetup on a image file containing (GPT) partition doesn't create partition devices

[Mike Frysinger <vapier@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 1768 bytes --]

On 02 Dec 2014 14:29, Phillip Susi wrote:
> On 10/27/2014 4:16 PM, Mike Frysinger wrote:
> > we've been tracking the same bug in Chromium OS: 
> > http://crbug.com/411693 basically, under load, using `losetup -P`
> > randomly fails to create the relevant partition nodes.  atm we have
> > hacks in place to call `blockdev --rereadpt` when it looks like the
> > kernel has failed us.
> > 
> > it would be nice if the kernel didn't ignore the result of the
> > ioctl thus allowing all errors to go unnoticed.  you can see this
> > in drivers/block/loop.c where it calls ioctl_by_bdev multiple times
> > and doesn't check the return value.
> > 
> > since all current kernels are broken though, and might be for the
> > foreseeable future, having losetup issue the ioctl itself might be
> > a good tradeoff.  i think it'd trigger unnecessary overhead
> > (rescanning the device after it already worked), but seems better
> > than having losetup try and check other sources (like if arbitrary
> > partition nodes were created).
> 
> As long as the kernel has a flag that is supposed to cause it to
> interpret the partition table, then it should *work* and not silently
> fail.  This is a bug in the kernel that should be fixed.

i agree the kernel should be fixed.  but like i said, it isn't today, and it 
won't be for a while, and even then it'll take a while for all those fixed 
kernel versions to percolate out to distros.

> As a workaround though, you might consider just not using losetup -P
> in the first place and just run partx when you want to activate
> partitions.  This also has the advantage of working even when the loop
> module is not loaded with the max_parts argument.

thanks, wasn't aware of the partx tool
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]