This is a serious bug that has hosed my system.
Upgraded Ibex to Jaunty (Kubuntu) using the upgrade tool. I have
precisely one encrypted container - no multiple type situation here.
Unencrypted /boot, and encrypted sdaX_crypt. That is all.
Now, I do not get a password prompt to enter my luks
Julien, I think you have a good point here (using the LUKS UUID always,
especially when the other is swap).
Please take this upstream (via their mailinglist, see
http://userweb.kernel.org/~kzak/util-linux-ng/), as Scott suggested, and
hopefully they'll accept it.
Thanks.
--
udev fails to
2.15.1 will just do that for RAID, btw:
http://git.kernel.org/?p=utils/util-linux-ng/util-linux-ng.git;a=commitdiff;h=7103157c8bbf37a56c7c385198267120f72b7866
--
udev fails to identify crypt_LUKS swap partition by uuid
https://bugs.launchpad.net/bugs/362315
You received this bug notification
There is no way to resolve such conflicts automatically.
In some cases (such as the case above), there is.
We would risk serious data loss.
The very worst that could eventually happen here is that the swap is
mounted unencrypted. The only possible data loss is that LUKS key slots
would be
Sorry, nothing to prove here. You totally miss the point. Fix your
broken metadata.
--
udev fails to identify crypt_LUKS swap partition by uuid
https://bugs.launchpad.net/bugs/362315
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
Sorry, nothing to prove here. You totally miss the point. Fix your
broken metadata.
That's already done, mind you.
Now PROVE that my suggestion to expose the LUKS UUID could actually
cause bad things. Go.
--
udev fails to identify crypt_LUKS swap partition by uuid
On Fri, 2009-04-17 at 14:09 +, Julien Plissonneau Duquene wrote:
And this is how a sensible bug supervisor (like most supervisors
actually are) would have done it:
I'm not a bug supervisor. I'm a developer.
- ask for details (mark bug new, incomplete or triaged) ; are
there actually
On Fri, 2009-04-17 at 14:09 +, Julien Plissonneau Duquene wrote:
The software is working exactly as designed.
Probably not.
From the /usr/share/doc/udev/NEWS.gz file:
Libvolume_id now always probes for all known filesystems, and does not
stop at the first match. Some filesystems are
There is not much to add to the explanation. Volume autodetection has to
refuse to return any results for conflicting signatures. It will get
even more picky in the future, we expect.
There is no way to resolve such conflicts automatically. We would risk
serious data loss. Be happy, that the
On Thu, 2009-04-16 at 19:43 +, 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
You self-identified an apparent defect in a particular software package,
when in fact that package was working normally and as designed.
Fact: it worked before jaunty, with jaunty it's broken.
It's often better to *not* jump directly to the source as you did; had
you filed a more generic
** Attachment added: result of udevadm --export-db
http://launchpadlibrarian.net/25532310/udevadm_db
--
udev fails to identify crypt_LUKS swap partition by uuid
https://bugs.launchpad.net/bugs/362315
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Your block device has multiple metadata on it, this isn't supported
** Changed in: udev (Ubuntu)
Status: New = Invalid
--
udev fails to identify crypt_LUKS swap partition by uuid
https://bugs.launchpad.net/bugs/362315
You received this bug notification because you are a member of Ubuntu
Hey, this was setup using the standard ubuntu tools some releases ago.
It used to work until Jaunty. Now it doesn't work. THAT'S A DEFECT
period. Reopening. Someone influent told in some report of some other
package that libvolid folks are not willing to fix bugs, it looks like
this is true
By the way, about multiple metadata is not supported, there are already
multiple links for the same block device in /dev/disk/by-id, e.g.
ata-HTS721060G9AT00_MPC3B2Y3GK0S3E-part1 - sda1
scsi-SATA_HTS721060G9AT00_MPC3B2Y3GK0S3E-part1 - sda1
Why not just do that in /dev/disk/by-uuid when you are
Please don't simply re-open bugs without consulting with the maintainer.
In your case, my understanding of cryptsetup is that it creates a
devmapper device exposing the *unencrypted* data on the partition. It
is quite correct that udev ignores /dev/sda4 - it is an encrypted swap,
and udev can do
Reopening again. Please don't make bugs as invalid without first making
sure that you understand the problem, and that the bug report is
actually invalid. Because in this case it is not. Thanks.
Yes, devmapper exposes the unencrypted partition ... once the partition
is unlocked. At boot time it
Out of interest, if you use the merged blkid/vol_id library available
from my PPA (util-linux, e2fsprogs, libblkid, etc.) what result does
blkid -p give you on that device?
--
udev fails to identify crypt_LUKS swap partition by uuid
https://bugs.launchpad.net/bugs/362315
You received this bug
dd if=/dev/zero of=/dev/sda4
And set up LUKS on that device again.
Feel free to change the bug task from udev to whatever tool you used to
create the device, I've opened a task on cryptsetup speculatively
** Changed in: udev (Ubuntu)
Status: Confirmed = Won't Fix
** Also affects:
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:
A better way to remove a stale swap signature than zeroing the whole thing:
dd if=/dev/zero of=/dev/sdXXX bs=1024 seek=1 count=3
--
udev fails to identify crypt_LUKS swap partition by uuid
https://bugs.launchpad.net/bugs/362315
You received this bug notification because you are a member of
21 matches
Mail list logo
