On Fri, Feb 12, 2016 at 10:45:17PM -, Andri Möll wrote:
> Even though this seems to be fixed, I'm still seeing UUID= mountpoints
> failing in Ubuntu 14.04.03 when that mountpoint is on a LVM logical
> volume.
Use of UUID= for LVM volumes is unsupported because a UUID is not guaranteed
to be a
Even though this seems to be fixed, I'm still seeing UUID= mountpoints
failing in Ubuntu 14.04.03 when that mountpoint is on a LVM logical
volume. Switch fstab to use /dev/mapper/a-b syntax, initramfs gets
generated with cryptsetup et al. included.
--
You received this bug notification because yo
cryptsetup (2:1.0.7~rc1-1) unstable; urgency=low
* new upstream release candidate, highlights include:
- use better error messages if device doesn't exist or is already used by
other mapping (closes: #492926)
- check device size when loading LUKS header
- add some error
** Branch linked: lp:ubuntu/karmic/cryptsetup
--
cryptsetup does not understand UUID= in fstab and conf.d/resume
https://bugs.launchpad.net/bugs/287879
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-b
** Bug watch added: Debian Bug tracker #522041
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=522041
** Also affects: cryptsetup (Debian) via
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=522041
Importance: Unknown
Status: Unknown
--
cryptsetup does not understand UUID= in f
** Changed in: cryptsetup (Debian)
Status: Unknown => New
--
cryptsetup does not understand UUID= in fstab and conf.d/resume
https://bugs.launchpad.net/bugs/287879
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs ma
Hi - I am trying to determine if this issue applies to me. Is this the
right place to ask some questions? (newbie)
My system:
$ uname -a: Linux 2.6.27-7-generic #1 SMP x86_64 GNU/Linux
$ dpkg -s cryptsetup
Package: cryptsetup
Status: install ok installed
Architecture: amd64
Version: 2:1.0.6-6ubunt
Thanks Kees - you have no idea of the frustration each time I had to
recover from a live-CD after the cryptsetup package updated without my
realising and regenerated an initrd image without the keyscript
included!
--
cryptsetup does not understand UUID= in fstab and conf.d/resume
https://bugs.lau
This bug was fixed in the package cryptsetup - 2:1.0.6-7ubuntu5
---
cryptsetup (2:1.0.6-7ubuntu5) jaunty; urgency=low
* debian/initramfs/cryptroot-hook: fix support for UUID and LABEL correlation
between fstab and crypttab (LP: #287879).
-- TJMon, 16 Feb 2009 23:00:00 +000
I adjusted your patch slightly to declare "original" as a local
variable, and to use "by-*" instead of "by*" in the latter check, just
to match to if clause directly. Thanks!
** Changed in: cryptsetup (Ubuntu)
Assignee: (unassigned) => Kees Cook (kees)
Status: Confirmed => Fix Committ
Updated the debdiff to be based off 7ubuntu4:
cryptsetup (2:1.0.6-7ubuntu5) jaunty; urgency=low
* debian/initramfs/cryptroot-hook: fix support for UUID and LABEL correlation
between fstab and crypttab (LP: #287879).
-- TJ Mon, 16 Feb 2009 23:00:00 +
** Attachment removed: "Jaunty
Updated the debdiff to be based off 7ubuntu3:
cryptsetup (2:1.0.6-7ubuntu4) jaunty; urgency=low
* debian/initramfs/cryptroot-hook: fix support for UUID and LABEL correlation
between fstab and crypttab (LP: #287879).
-- TJ Thu, 12 Feb 2009 16:45:00 +
** Attachment removed: "Jaunty
cryptsetup (2:1.0.6-7ubuntu3) jaunty; urgency=low
* debian/initramfs/cryptroot-hook: fix support for UUID and LABEL correlation
between fstab and crypttab (LP: #287879).
-- TJ Thu, 12 Feb 2009 16:45:00 +
** Attachment added: "Jaunty debdiff"
http://launchpadlibrarian.net/2255378
** Tags added: qa-jaunty-foundations
--
cryptsetup does not understand UUID= in fstab and conf.d/resume
https://bugs.launchpad.net/bugs/287879
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists
Ooops! The patch in comment #7 was premature. This is how it should be:
diff -Nu cryptsetup-1.0.6/debian/initramfs/cryptroot-hook
/target/usr/share/initramfs-tools/hooks/cryptroot
--- cryptsetup-1.0.6/debian/initramfs/cryptroot-hook2009-02-09
18:42:15.358063612 +
+++ /target/usr/share/in
My previous suggested patch would cause unwanted side effects when
device aliases/symlinks are used for non-crypt disks.
This patch should provide the desired result without causing a
regression:
diff -Nu cryptsetup-1.0.6/debian/initramfs/cryptroot-hook
/target/usr/share/initramfs-tools/hooks/cr
Confirmed and still affecting Jaunty.
The root-cause is /usr/share/initramfs-tools/hooks/cryptroot
(debian/initramfs/cryptroot-hook in the source package).
The script is called when update-initramfs is executed. It is
responsible for correlating /etc/fstab entries with those in
/etc/crypttab and
The problem is not the accessibility of the UUID. All UUIDS (encrypted
or not) are available when the initramdisk is created, and that is the
point that is currently broken.
--
cryptsetup does not understand UUID= in fstab and conf.d/resume
https://bugs.launchpad.net/bugs/287879
You received this
That should read - "isn't the partition decrypted by the time fstab is
read to mount the LVM volumes?"
--
cryptsetup does not understand UUID= in fstab and conf.d/resume
https://bugs.launchpad.net/bugs/287879
You received this bug notification because you are a member of Ubuntu
Bugs, which is sub
I can confirm this bug on Ubuntu 8.10. Nikolaus is correct. Not only may
UUIDs be used to reference LVM volumes in /etc/fstab, this is the
default configuration in 8.10. I followed the instructions here
(https://help.ubuntu.com/community/EncryptedFilesystemLVMHowto) in order
to create a LUKS+LVM en
Since the fstab manpage documents the UUID syntax, how do you justify
your claim that "in /etc/fstab you must use /dev/mapper/ entries"?
Actually, it seems to me that you misunderstood the point of the
bugreport. This bug is about cryptsetup, since cryptsetup is the
application that fails to parse
In /etc/fstab you must use /dev/mapper/ entries, because this is
what you mount. Afaik the UUID= entries placed in /etc/crypttab should
work, as should LABEL= entries and also direct /dev/XdaY.
Did you misunderstand how it all works or is it still a bug? If so, then
include all configuration files
22 matches
Mail list logo
