Comment 11 for bug 362315

On Thu, 2009-04-16 at 19:43 +0000, Julien Plissonneau Duquene wrote:

> "Won't fix" is less bad than plain "invalid" but still not appropriate
> IMO. This is the cow-boy way of "fixing" problems: shoot them first, if
> they survive shoot them again, then eventally think about them.
>
I disagree.

You self-identified an apparent defect in a particular software package,
when in fact that package was working normally and as designed.

It's often better to *not* jump directly to the source as you did; had
you filed a more generic bug, our QA team would have been able to triage
it far more effectively and identify the real problem.

> With your packages:
> $ sudo ./blkid -p /dev/sda3
> /dev/sda3: UUID="4d3ba41a-1fb4-474b-a59e-4285e4768bdd" VERSION="256" TYPE="crypto_LUKS" USAGE="crypto"
> $ sudo ./blkid -p /dev/sda4
> /dev/sda4: ambivalent result (probably more filesystems on the device)
>
Right, so blkid behaves the same.

> Correct detection should stop as soon as a LUKS header is detected, and
> report the LUKS UUID. Why? Because if this was an actual swap partition,
> the LUKS header would have been deleted by mkswap (see zap_bootbits).
>
BZZT.

For every person that authoratively asserts, as you just did, that X is
always preferred over Y - I can find you somebody who asserts the exact
opposite.

Years of trying to deal with this sanely led upstream to the simple
conclusion that there is never a preference of X over Y or Y over X.

The better solution is to ensure that there is never a case of
conflicting meta-data on a block device.

> So yes there is a stale swap signature, probably coming from a previous
> distro before I switched to ubuntu. As far as I know it's not
> cryptsetup's job to erase what's there.
>
It is recommended, see util-linux etc.

> If you leave this as "Won't fix", it actually means that migrating from
> previous Ubuntu releases with encrypted swap partitions is not
> supported. Also probably means that installing Ubuntu Jaunty with a LUKS
> swap over over existing partitions is not supported, and going to fail.
> Please document this in release notes. Thanks.
>
No.

I've left the udev task of this as Won't Fix - if previous versions of
cryptsetup were broken, and did not correctly erase conflicting
metadata, then cryptsetup can be fixed and the migration dealt with
there.

(Our bug tracker uses multiple tasks, so this bug is still open, it's
just rejected as a udev problem - another reason you should have filed a
more generic bug before diving in yourself.)

> What is so hard about marking this bug as "confirmed" so 1. others have
> a better chance to know about it, and 2. it gets a better chance to be
> fixed someday?
>
Because it isn't a bug. The software is working exactly as designed.
If you'd like to complain about the design of the software, upstream is
a far better place to do that - we're just a distro.

(Note that vol_id is deprecated in udev, so your complaints should be
directed at the new libblkid in util-linux-ng)

Scott
--
Scott James Remnant
<email address hidden>