"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-42
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 Ubuntu
> 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 generi
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 syste
> 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 ov
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.
--
ub
> 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
https://bugs.launchpad.net/b
** 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 subscr
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 unfortu
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 ar
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 is
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 not
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: crypts
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 ident
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 beca
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 pass
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 syste
> 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 ov
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.
--
ub
> 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
https://bugs.launchpad.net/b
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 ident
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 beca
** 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 subscr
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 unfortu
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 ar
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 is
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 not
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: crypts
"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-42
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 Ubuntu
> 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 generi
** 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 subscr
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 unfortu
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 ar
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 is
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 not
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: crypts
"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-42
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 Ubuntu
> 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 generi
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 syste
> 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 ov
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.
--
ub
> 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
https://bugs.launchpad.net/b
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 ident
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 beca
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 pass
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 syste
> 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 ov
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.
--
ub
> 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
https://bugs.launchpad.net/b
** 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 subscr
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 unfortu
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 ar
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 is
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 not
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: crypts
"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-42
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 Ubuntu
> 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 generi
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 ident
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 beca
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 pass
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 syste
> 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 ov
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.
--
ub
> 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
https://bugs.launchpad.net/b
** 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 subscr
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 unfortu
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 ar
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 is
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 not
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: crypts
"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-42
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 Ubuntu
> 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 generi
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 ident
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 beca
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 pass
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 pass
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 syste
> 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 ov
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.
--
ub
> 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
https://bugs.launchpad.net/b
** 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 subscr
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 unfortu
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 ar
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 is
1 - 100 of 126 matches
Mail list logo
