search for: luksuuid

...point in the future, >> go to CentOS 7, but that needs my user to be off for a while, and his jobs >> run literally for weeks, with loads upwords of 30 on an HBS (honkin' big >> server).... > > MAPDEVICE=/dev/sdxy ; cryptsetup luksOpen ${MAPDEVICE} luks-$(cryptsetup > luksUUID ${MAPDEVICE}) Something's not right. I did cryptsetup luksOpen /dev/sdb luks-$(cryptsetup luksUUID $(/dev/sdb)) --key-file /etc/crypt.pw It did want the password, so I added --key-file, but it seems to have created /dev/mapper/luks, not the full luksUUID that's in both crypttab and fstab....

Upgraded a RAID. Copied everything from backup. And then my manager said I had to encrypt the drive. I've done that, and made the filesystem, but I can't mount it. CentOS 6. I have the entry in /etc/crypttab, and a key in /etc/crypt.pw, and the luks UUID in /etc/fstab. I cannot find the command that tells it to create the device in /dev/mapper from the info in /etc/crypttab. Clues for

...gt;For BitLocker disks cryptsetup does not (yet? ever?) support reading >UUIDs and this function will fail. This does not matter here so just >ignore the error. > >Note there is no error message, cryptsetup simply returns with a bad >exit code: > >><rescue> cryptsetup luksUUID /dev/sda2 >><rescue> echo $? >1 > >Updates commit bb4a2dc17a78b53437896d4215ae82df8e11b788. >--- > options/decrypt.c | 15 ++++++++++++++- > 1 file changed, 14 insertions(+), 1 deletion(-) > >diff --git a/options/decrypt.c b/options/decrypt.c >index 8eb24bc..6b...

...reading >> >UUIDs and this function will fail. This does not matter here so just >> >ignore the error. >> > >> >Note there is no error message, cryptsetup simply returns with a bad >> >exit code: >> > >> >><rescue> cryptsetup luksUUID /dev/sda2 >> >><rescue> echo $? >> >1 >> > >> >Updates commit bb4a2dc17a78b53437896d4215ae82df8e11b788. >> >--- >> >options/decrypt.c | 15 ++++++++++++++- >> >1 file changed, 14 insertions(+), 1 deletion(-) >> > >&g...

...The original feedback was that ignoring errors from guestfs_luks_uuid would ignore legitimate errors from non-BitLocker disks, so I have modified this series so that errors are only ignored in the BitLocker case. As noted in the 4th patch there is no actual error in the BitLocker case, cryptsetup luksUUID simply exits without printing anything. Rich.

...>> go to CentOS 7, but that needs my user to be off for a while, and his jobs >>> run literally for weeks, with loads upwords of 30 on an HBS (honkin' big >>> server).... >> >> MAPDEVICE=/dev/sdxy ; cryptsetup luksOpen ${MAPDEVICE} luks-$(cryptsetup >> luksUUID ${MAPDEVICE}) > > Something's not right. I did > cryptsetup luksOpen /dev/sdb luks-$(cryptsetup luksUUID $(/dev/sdb)) > --key-file /etc/crypt.pw > > It did want the password, so I added --key-file, but it seems to have > created /dev/mapper/luks, not the full luksUUID tha...

...oes not (yet? ever?) support reading > >UUIDs and this function will fail. This does not matter here so just > >ignore the error. > > > >Note there is no error message, cryptsetup simply returns with a bad > >exit code: > > > >><rescue> cryptsetup luksUUID /dev/sda2 > >><rescue> echo $? > >1 > > > >Updates commit bb4a2dc17a78b53437896d4215ae82df8e11b788. > >--- > >options/decrypt.c | 15 ++++++++++++++- > >1 file changed, 14 insertions(+), 1 deletion(-) > > > >diff --git a/options/decrypt....

...IDs and this function will fail. This does not matter here so just >>> >ignore the error. >>> > >>> >Note there is no error message, cryptsetup simply returns with a bad >>> >exit code: >>> > >>> >><rescue> cryptsetup luksUUID /dev/sda2 >>> >><rescue> echo $? >>> >1 >>> > >>> >Updates commit bb4a2dc17a78b53437896d4215ae82df8e11b788. >>> >--- >>> >options/decrypt.c | 15 ++++++++++++++- >>> >1 file changed, 14 insertions(+), 1 dele...

For BitLocker disks cryptsetup does not (yet? ever?) support reading UUIDs and this function will fail. This does not matter here so just ignore the error. Note there is no error message, cryptsetup simply returns with a bad exit code: ><rescue> cryptsetup luksUUID /dev/sda2 ><rescue> echo $? 1 Updates commit bb4a2dc17a78b53437896d4215ae82df8e11b788. --- options/decrypt.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/options/decrypt.c b/options/decrypt.c index 8eb24bc..6b1c0a8 100644 --- a/options/decrypt.c +++...

...on that was not enabled while booting, because not in the crypttab). I can execute the necessary command stack [1] but just wondering if there is an "enterprise/easy" way to do that ... [1] cryptsetup luksOpen $(blkid -t TYPE="crypto_LUKS" -o device) \ luks-$(cryptsetup luksUUID $(blkid -t TYPE="crypto_LUKS" -o device)) -- LF

...the server will, at some point in the future, go > to CentOS 7, but that needs my user to be off for a while, and his jobs > run literally for weeks, with loads upwords of 30 on an HBS (honkin' big > server).... MAPDEVICE=/dev/sdxy ; cryptsetup luksOpen ${MAPDEVICE} luks-$(cryptsetup luksUUID ${MAPDEVICE}) MAPDEVICE=/dev/sdxy ; mount /dev/mapper/luks-$(cryptsetup luksUUID ${MAPDEVICE}) /mnt -- LF

...+++ b/daemon/luks.c @@ -292,3 +292,28 @@ do_luks_kill_slot (const char *device, const char *key, int keyslot) return 0; } + +char * +do_luks_uuid (const char *device) +{ + const char *argv[MAX_ARGS]; + size_t i = 0; + + ADD_ARG (argv, i, "cryptsetup"); + ADD_ARG (argv, i, "luksUUID"); + ADD_ARG (argv, i, device); + ADD_ARG (argv, i, NULL); + + char *out = NULL; + CLEANUP_FREE char *err = NULL; + int r = commandv (&out, &err, (const char * const *) argv); + + if (r == -1) { + reply_with_error ("%s", err); + return NULL; + } + + trim (out);...

Folks, I have an issue: I've gotten that drive that I posted about the other day encrypted, and things were looking good... until there was a problem with another RAID attached to the box, and I wound up having to reboot. What had been /dev/sdb came up as /dev/sdc. So... is there any way other than using /dev/disk/by-uuid/<uUUID> as the second field in /etc/crypttab to deal with

This combined patch series enables to decrypt LUKS devices on inspection by allowing the UUID of the LUKS device with the --key syntax. I opted for reusing the option instead of adding another one, as I think that device names and UUIDs are different enough that can be properly distinguished. A test for this (patch #4) can be applied only when the patches for common are applied, and the