"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.
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)
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).
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 recommanded to fill the disk with random bits before running cryptsetup; the ubuntu tool at that time did not do this (nor did they erase the swap signature).
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.
Nevertheless, not reporting any UUID is the worst possible behaviour and break things, as demonstrated.
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?
"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.
With your packages: 1fb4-474b- a59e-4285e4768b dd" VERSION="256" TYPE="crypto_LUKS" USAGE="crypto"
$ sudo ./blkid -p /dev/sda3
/dev/sda3: UUID="4d3ba41a-
$ sudo ./blkid -p /dev/sda4
/dev/sda4: ambivalent result (probably more filesystems on the device)
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).
What's actually on /dev/sda4:
00000000 4c 55 4b 53 ba be 00 01 61 65 73 00 00 00 00 00 |LUKS....aes.....|
(...)
00000400 01 00 00 00 25 72 07 00 00 00 00 00 e6 78 04 bd |....%r.......x..|
(...)
00000ff0 00 00 00 00 00 00 53 57 41 50 53 50 41 43 45 32 |......SWAPSPACE2|
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 recommanded to fill the disk with random bits before running cryptsetup; the ubuntu tool at that time did not do this (nor did they erase the swap signature).
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.
Nevertheless, not reporting any UUID is the worst possible behaviour and break things, as demonstrated.
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?