Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 215930 - losetup regression: ceased to support the "size"-parameter
Summary: losetup regression: ceased to support the "size"-parameter
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High critical (vote)
Assignee: Gentoo's Team for Core System packages
Depends on:
Reported: 2008-04-02 19:22 UTC by Guenther Brunthaler
Modified: 2008-04-02 21:58 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Guenther Brunthaler 2008-04-02 19:22:43 UTC
Up to <sys-apps/util-linux-2.13.1 losetup had 2 parameters for mapping a subset of a disk image file: -o for offset and -s for size.

This allowed, for example, to mount a specific partition out from an image file containing a complete hard disk with multiple partitions.

This feature was especially useful in combination with VMware or QEMU, because it allowed to directly access the partitions of the virtual hard disk when the Virtual Machines were not running.

But suddenly, starting with util-linux-2.13.1, the -s ("size") parameter seems no longer to be supported by losetup, although -o ("offset") still remains. Although -o will make little sense without -s, except perhaps for encryption-only scenarios.

All my VMware external mount scripts thus suddenly fail.

And even worse, the -s option has not only be removed, it has been recycled to do something different than before: Not it suddenly displays ("show") some information instead of specifying the "size" argument.

Which is dangerous as well: As "-s" now has no argument but had an argument before, the "size" argument will now be mistaken as the first argument in existing scripts, which is certainly not what has been intended.

But the worst thing of all is that there is no workaround: The -s option has not just been renamed to some other name - no, it has been completely removed!

This is a severe loss of functionality which will also break a lot of scripts - in fact *all* scripts which mount partitions from disk image files.

Aside from stopping to use losetup and trying to use device mapper for about the same purpose (which would require changing a lot of existing scripts), I do not know what to do about that totally unexpected and sudden loss of functionality.

At the very least, the "-s" option should be completely removed which will make any scripts using "-s" as for "size" fail instantly, instead of perhaps running with changed functionality.

Reproducible: Always

Steps to Reproduce:
1. Set up a VMware disk image with a partition starting at offset 0x9CE2FE00 bytes and a partition size of 0x61A78E800 bytes. Just as an example. Or use any size you like.
2. losetup -o 0x9CE2FE00 -s 0x61A78E800 /dev/loop3 vmware-flat.vmdk

Actual Results:  
losetup interprets "-s" now as "show size" instead of "mapping size" parameter, and thus fails to provide a loop device for accessing the desired partition.

Expected Results:  
/dev/loop3 should refer to a loop block device 0x61A78E800 bytes in size, referring to the partition of interest.

Messing with losetup is extremely dangerous, because this is a tool intended to be used to mount or dismount disk image files.

If the "-s" parameter is suddenly no longer supported - and even worse - still exists but now does something completely different, it is possible that automated backup scripts and the like will fail in unexpected ways, which can lead to filesystem corruption and possible data loss within those disk image files depending on the usage.

If upstream won't care about this problem, this major change of functionality is severe enough to rename losetup into something else, such as "losetup2", in order to avoid old scripts assuming the same semantics from this tool as there have been in the previous versions, potentially damaging data.
Comment 1 Guenther Brunthaler 2008-04-02 19:28:52 UTC
I have tagged this issue as "critical" rather than "major", because it can result in data corruption.
Comment 2 Guenther Brunthaler 2008-04-02 20:52:31 UTC
I suggest *immediately* re-masking of the new sys-apps/util-linux versions until the issue is resolved!

This will at least avoid data loss for the affected installations.
Comment 3 Guenther Brunthaler 2008-04-02 20:57:11 UTC
Regarding my idea of using the device mapper instead of losetup, there is a problem with this: Nearly every kernel has support for losetup compiled in, but not all kernels have been built with device mapper support.

As a consequence, all those installations will either have to mask all new util-linux versions since the regression was introduced, or have to recompile the kernel with device mapper support enabled.

I know genkernel has dm-support enabled, but a lot of admins prefer to set up their own kernel configurations.

And even if dm-support is enabled, one has first to find a way to emulate losetup's old behaviour using dmsetup. Which might or might not be fun... ;-)
Comment 4 SpanKY gentoo-dev 2008-04-02 21:03:02 UTC
you didnt add loop-aes to your USE
Comment 5 Guenther Brunthaler 2008-04-02 21:13:39 UTC
(In reply to comment #4)
> you didnt add loop-aes to your USE

You are right. But then, I never did, and "-s" still worked until the new version.

Also, my use flag description says:

sys-apps/util-linux:loop-aes - include support for Loop AES encryption

There is no hint that it is also required for mounting *unencrypted* partitions out of unencrypted disk images.

Also, my kernel does not have any AES support enabled, because I'm using TrueCrypt rather than aes-loop. (This allows me to use the same disk images under Linux as well as under that other operating system which is primarily designed for playing games.)

But nevertheless, thanks for the hint - I will immediately re-emerge util-linux with loop-aes enabled and will see whether it helped!
Comment 6 Guenther Brunthaler 2008-04-02 21:58:29 UTC
OK - verified!

I also noted that little message when compiling:

 * USE=crypt has been changed to USE=loop-aes.  If you need
 * support for it, make sure to update your USE accordingly.

and indeed - I have had USE flag "crypt" enabled until now, but never "loop-aes". This message thus explains the regression!

I didn't notice because it was just a "green" message, not a yellow one.

Actually it should have been red and blinking... ;-)

Nevertheless: Issue resolved.

Thanks for your swift reaction!

Closing bug.