* [dm-crypt] problems mounting encrypted drive on reboot @ 2017-09-20 22:38 Jerry Lowry 2017-09-20 22:53 ` Arno Wagner 2017-09-21 7:25 ` Michael Kjörling 0 siblings, 2 replies; 8+ messages in thread From: Jerry Lowry @ 2017-09-20 22:38 UTC (permalink / raw) To: crypt [-- Attachment #1: Type: text/plain, Size: 2454 bytes --] Hi, I have created an encrypted drive using the following commands: #>cryptsetup --verify=passphrase -- hash=sha256 --keyfile=/dir/file create /dev/mapper/testcui /dev/sdb #>mkfs.ext4 /dev/mapper/testcui I did this all at single user level. running centos 7 on a VM. this all work well until I reboot the system and then it fails to mount the device and drops down it to emergency mode. This is the journalctl output I get. ( yeah I know about the acls on the key file ) device name "testcui" Sep 20 14:19:53 jubilee systemd[1]: Starting Cryptography Setup for /dev/mapper/testcui... -- Subject: Unit systemd-cryptsetup@-dev-mapper-testcui.service has begun start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit systemd-cryptsetup@-dev-mapper-testcui.service has begun starting up. Sep 20 14:19:53 jubilee systemd-cryptsetup[501]: Key file /etc/keys is world-readable. This is not a good idea! Sep 20 14:19:53 jubilee systemd-cryptsetup[501]: Set cipher aes, mode cbc-essiv:sha256, key size 256 bits for device /dev/sdb. Sep 20 14:19:53 jubilee systemd-cryptsetup[501]: *Failed to activate with key file '/etc/keys': Invalid argument* Sep 20 14:19:53 jubilee systemd[1]: Started Forward Password Requests to Plymouth. What is the invalid argument that it is complaining about? Once in emergency mode I can : #>cryptsetup create testcui /dev/sdb ( passcode) And it continues just fine. -- crypttab -- # test disk # /dev/mapper/testcui /dev/sdb /etc/keys plain --fstab-- # # /etc/fstab # Created by anaconda on Tue Dec 15 12:05:51 2015 # # Accessible filesystems, by reference, are maintained under '/dev/disk' # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info # UUID=c4cc85f2-9dbb-4bf8-8b3e-edaa5af3dae9 / xfs defaults 1 1 UUID=2f178edb-b16e-4ea1-85c3-d8243b07a75b /boot xfs defaults 1 2 UUID=a34fac21-a385-494a-a6cc-cae22b87c8c9 swap swap defaults 0 0 /dev/mapper/testcui /cui ext4 defaults 1 2 jerry -- --------------------------------------------------------------------------- Jerold Lowry Principal Network/Systems Engineer Engineering Design Team (EDT), Inc. a HEICO company 3423 NW John Olsen Pl Hillsboro, Oregon 97124 (U.S.A.) Phone: 503-690-1234 / 800-435-4320 Fax: 503-690-1243 Web: _www.edt.com <http://www.edt.com/>_ [-- Attachment #2: Type: text/html, Size: 5020 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dm-crypt] problems mounting encrypted drive on reboot 2017-09-20 22:38 [dm-crypt] problems mounting encrypted drive on reboot Jerry Lowry @ 2017-09-20 22:53 ` Arno Wagner 2017-09-20 22:59 ` Jerry Lowry 2017-09-21 7:25 ` Michael Kjörling 1 sibling, 1 reply; 8+ messages in thread From: Arno Wagner @ 2017-09-20 22:53 UTC (permalink / raw) To: dm-crypt Hi, looks to me like you need to complain to the systemd-people, not to us here. Good luck with that.... Regards, Arno On Thu, Sep 21, 2017 at 00:38:20 CEST, Jerry Lowry wrote: > Hi, > > I have created an encrypted drive using the following commands: > > #>cryptsetup --verify=passphrase -- hash=sha256 --keyfile=/dir/file > create /dev/mapper/testcui /dev/sdb > > #>mkfs.ext4 /dev/mapper/testcui > > I did this all at single user level. running centos 7 on a VM. > > this all work well until I reboot the system and then it fails to mount > the device and drops down it to emergency mode. This is the journalctl > output I get. ( yeah I know about the acls on the key file ) device > name "testcui" > > Sep 20 14:19:53 jubilee systemd[1]: Starting Cryptography Setup for > /dev/mapper/testcui... > -- Subject: Unit [1]systemd-cryptsetup@-dev-mapper-testcui.service has > begun start-up > -- Defined-By: systemd > -- Support: > [2]http://lists.freedesktop.org/mailman/listinfo/systemd-devel > -- > -- Unit [3]systemd-cryptsetup@-dev-mapper-testcui.service has begun > starting up. > Sep 20 14:19:53 jubilee systemd-cryptsetup[501]: Key file /etc/keys is > world-readable. This is not a good idea! > Sep 20 14:19:53 jubilee systemd-cryptsetup[501]: Set cipher aes, mode > cbc-essiv:sha256, key size 256 bits for device /dev/sdb. > Sep 20 14:19:53 jubilee systemd-cryptsetup[501]: Failed to activate > with key file '/etc/keys': Invalid argument > Sep 20 14:19:53 jubilee systemd[1]: Started Forward Password Requests > to Plymouth. > > What is the invalid argument that it is complaining about? > > Once in emergency mode I can : > > #>cryptsetup create testcui /dev/sdb > > ( passcode) > > And it continues just fine. > > -- crypttab -- > > # test disk > # > /dev/mapper/testcui /dev/sdb /etc/keys plain > > --fstab-- > > # > # /etc/fstab > # Created by anaconda on Tue Dec 15 12:05:51 2015 > # > # Accessible filesystems, by reference, are maintained under > '/dev/disk' > # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more > info > # > UUID=c4cc85f2-9dbb-4bf8-8b3e-edaa5af3dae9 / > xfs defaults 1 1 > UUID=2f178edb-b16e-4ea1-85c3-d8243b07a75b /boot > xfs defaults 1 2 > UUID=a34fac21-a385-494a-a6cc-cae22b87c8c9 swap > swap defaults 0 0 > /dev/mapper/testcui /cui ext4 defaults 1 2 > > jerry > > -- > > ----------------------------------------------------------------------- > ---- > Jerold Lowry > Principal Network/Systems Engineer > Engineering Design Team (EDT), Inc. a HEICO company > 3423 NW John Olsen Pl > Hillsboro, Oregon 97124 (U.S.A.) > Phone: 503-690-1234 / 800-435-4320 > Fax: 503-690-1243 > Web: [4]www.edt.com > > References > > 1. mailto:systemd-cryptsetup@-dev-mapper-testcui.service > 2. http://lists.freedesktop.org/mailman/listinfo/systemd-devel > 3. mailto:systemd-cryptsetup@-dev-mapper-testcui.service > 4. http://www.edt.com/ > _______________________________________________ > dm-crypt mailing list > dm-crypt@saout.de > http://www.saout.de/mailman/listinfo/dm-crypt -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- A good decision is based on knowledge and not on numbers. -- Plato If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dm-crypt] problems mounting encrypted drive on reboot 2017-09-20 22:53 ` Arno Wagner @ 2017-09-20 22:59 ` Jerry Lowry 2017-09-21 7:27 ` Ondrej Kozina 0 siblings, 1 reply; 8+ messages in thread From: Jerry Lowry @ 2017-09-20 22:59 UTC (permalink / raw) To: dm-crypt [-- Attachment #1: Type: text/plain, Size: 4376 bytes --] Well, I have traced the error down to cryptsetup.c, line 564. Which is getting a return code of less than 0 from crypt_activate_by_keyfile_offset. So, I don't think it is the systemd folks. Just my guess. --------------------------------------------------------------------------- Jerold Lowry Principal Network/Systems Engineer Engineering Design Team (EDT), Inc. a HEICO company 3423 NW John Olsen Pl Hillsboro, Oregon 97124 (U.S.A.) Phone: 503-690-1234 / 800-435-4320 Fax: 503-690-1243 Web: _www.edt.com <http://www.edt.com/>_ On 9/20/2017 3:53 PM, Arno Wagner wrote: > Hi, > > looks to me like you need to complain to the systemd-people, > not to us here. Good luck with that.... > > Regards, > Arno > > On Thu, Sep 21, 2017 at 00:38:20 CEST, Jerry Lowry wrote: >> Hi, >> >> I have created an encrypted drive using the following commands: >> >> #>cryptsetup --verify=passphrase -- hash=sha256 --keyfile=/dir/file >> create /dev/mapper/testcui /dev/sdb >> >> #>mkfs.ext4 /dev/mapper/testcui >> >> I did this all at single user level. running centos 7 on a VM. >> >> this all work well until I reboot the system and then it fails to mount >> the device and drops down it to emergency mode. This is the journalctl >> output I get. ( yeah I know about the acls on the key file ) device >> name "testcui" >> >> Sep 20 14:19:53 jubilee systemd[1]: Starting Cryptography Setup for >> /dev/mapper/testcui... >> -- Subject: Unit [1]systemd-cryptsetup@-dev-mapper-testcui.service has >> begun start-up >> -- Defined-By: systemd >> -- Support: >> [2]https://url.emailprotection.link/?aU9kur6wsNUi02sZK7jqbqHUDJAa-o4ToSDYQrs9syxvrrIdB1sQAdzV3HPUijEgCYM0mtOEY4w7RKS2IUkVivQ~~ >> -- >> -- Unit [3]systemd-cryptsetup@-dev-mapper-testcui.service has begun >> starting up. >> Sep 20 14:19:53 jubilee systemd-cryptsetup[501]: Key file /etc/keys is >> world-readable. This is not a good idea! >> Sep 20 14:19:53 jubilee systemd-cryptsetup[501]: Set cipher aes, mode >> cbc-essiv:sha256, key size 256 bits for device /dev/sdb. >> Sep 20 14:19:53 jubilee systemd-cryptsetup[501]: Failed to activate >> with key file '/etc/keys': Invalid argument >> Sep 20 14:19:53 jubilee systemd[1]: Started Forward Password Requests >> to Plymouth. >> >> What is the invalid argument that it is complaining about? >> >> Once in emergency mode I can : >> >> #>cryptsetup create testcui /dev/sdb >> >> ( passcode) >> >> And it continues just fine. >> >> -- crypttab -- >> >> # test disk >> # >> /dev/mapper/testcui /dev/sdb /etc/keys plain >> >> --fstab-- >> >> # >> # /etc/fstab >> # Created by anaconda on Tue Dec 15 12:05:51 2015 >> # >> # Accessible filesystems, by reference, are maintained under >> '/dev/disk' >> # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more >> info >> # >> UUID=c4cc85f2-9dbb-4bf8-8b3e-edaa5af3dae9 / >> xfs defaults 1 1 >> UUID=2f178edb-b16e-4ea1-85c3-d8243b07a75b /boot >> xfs defaults 1 2 >> UUID=a34fac21-a385-494a-a6cc-cae22b87c8c9 swap >> swap defaults 0 0 >> /dev/mapper/testcui /cui ext4 defaults 1 2 >> >> jerry >> >> -- >> >> ----------------------------------------------------------------------- >> ---- >> Jerold Lowry >> Principal Network/Systems Engineer >> Engineering Design Team (EDT), Inc. a HEICO company >> 3423 NW John Olsen Pl >> Hillsboro, Oregon 97124 (U.S.A.) >> Phone: 503-690-1234 / 800-435-4320 >> Fax: 503-690-1243 >> Web: [4]https://url.emailprotection.link/?a4pOREhk_4MCW0PtjXkm2I74KsEDNqUHU1TlAGkvY7v8~ >> >> References >> >> 1. mailto:systemd-cryptsetup@-dev-mapper-testcui.service >> 2. https://url.emailprotection.link/?aU9kur6wsNUi02sZK7jqbqHUDJAa-o4ToSDYQrs9syxvrrIdB1sQAdzV3HPUijEgCYM0mtOEY4w7RKS2IUkVivQ~~ >> 3. mailto:systemd-cryptsetup@-dev-mapper-testcui.service >> 4. https://url.emailprotection.link/?arGCBlB4ktQEllVdqrdFEHWz7tmQKHcDNQMQoUiVtXzs~ >> _______________________________________________ >> dm-crypt mailing list >> dm-crypt@saout.de >> https://url.emailprotection.link/?ayE0YSl-8fsjTFuwcayuImPwuXvHCc0cXGaaipszDZOnBozAr3C_ngpEWBBTBT_i-8IP1XBKBwokSgi0QxfTytA~~ > [-- Attachment #2: Type: text/html, Size: 7289 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dm-crypt] problems mounting encrypted drive on reboot 2017-09-20 22:59 ` Jerry Lowry @ 2017-09-21 7:27 ` Ondrej Kozina 0 siblings, 0 replies; 8+ messages in thread From: Ondrej Kozina @ 2017-09-21 7:27 UTC (permalink / raw) To: Jerry Lowry, dm-crypt On 09/21/2017 12:59 AM, Jerry Lowry wrote: > Well, I have traced the error down to cryptsetup.c, line 564. Which is > getting a return code of less than 0 from crypt_activate_by_keyfile_offset. That's systemd's own cryptsetup utility you're talking about I assume. ...anyway can you reproduce the issue using cmd line utility (genuine cryptsetup :)) run with --debug and --key-file options? Regards Ondrej ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dm-crypt] problems mounting encrypted drive on reboot 2017-09-20 22:38 [dm-crypt] problems mounting encrypted drive on reboot Jerry Lowry 2017-09-20 22:53 ` Arno Wagner @ 2017-09-21 7:25 ` Michael Kjörling 2017-09-21 16:28 ` Jerry Lowry 1 sibling, 1 reply; 8+ messages in thread From: Michael Kjörling @ 2017-09-21 7:25 UTC (permalink / raw) To: dm-crypt On 20 Sep 2017 15:38 -0700, from jlowry@edt.com (Jerry Lowry): > I have created an encrypted drive using the following commands: > > #>cryptsetup --verify=passphrase -- hash=sha256 --keyfile=/dir/file > create /dev/mapper/testcui /dev/sdb If that's what you _really_ did, I'm pretty sure it can't have worked. The newline notwithstanding, whitespace still matters, and there is no --verify parameter (you probably meant to use --verify-passphrase). > Sep 20 14:19:53 jubilee systemd[1]: Starting Cryptography Setup for > /dev/mapper/testcui... > -- Subject: Unit systemd-cryptsetup@-dev-mapper-testcui.service has > begun start-up > -- Defined-By: systemd > -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel At a minimum, run cryptsetup directly (not through systemd) with the --debug flag and post back with the output thus obtained. -- Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup) ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dm-crypt] problems mounting encrypted drive on reboot 2017-09-21 7:25 ` Michael Kjörling @ 2017-09-21 16:28 ` Jerry Lowry 2017-09-21 16:49 ` Arno Wagner 2017-09-29 17:37 ` Milan Broz 0 siblings, 2 replies; 8+ messages in thread From: Jerry Lowry @ 2017-09-21 16:28 UTC (permalink / raw) To: dm-crypt [-- Attachment #1: Type: text/plain, Size: 1759 bytes --] If that's what you _really_ did, I'm pretty sure it can't have worked. The newline notwithstanding, whitespace still matters, and there is no --verify parameter (you probably meant to use --verify-passphrase). Yes, I did you verify-passphrase, just a typo! So, from the replies that I have gotten it sounds like there are two different camp ( groups) that are doing something with cryptsetup. Isn't that a duplication of effort? --------------------------------------------------------------------------- Jerold Lowry Principal Network/Systems Engineer Engineering Design Team (EDT), Inc. a HEICO company 3423 NW John Olsen Pl Hillsboro, Oregon 97124 (U.S.A.) Phone: 503-690-1234 / 800-435-4320 Fax: 503-690-1243 Web: _www.edt.com <http://www.edt.com/>_ On 9/21/2017 12:25 AM, Michael Kjörling wrote: > On 20 Sep 2017 15:38 -0700, from jlowry@edt.com (Jerry Lowry): >> I have created an encrypted drive using the following commands: >> >> #>cryptsetup --verify=passphrase -- hash=sha256 --keyfile=/dir/file >> create /dev/mapper/testcui /dev/sdb > If that's what you _really_ did, I'm pretty sure it can't have worked. > The newline notwithstanding, whitespace still matters, and there is no > --verify parameter (you probably meant to use --verify-passphrase). > > >> Sep 20 14:19:53 jubilee systemd[1]: Starting Cryptography Setup for >> /dev/mapper/testcui... >> -- Subject: Unit systemd-cryptsetup@-dev-mapper-testcui.service has >> begun start-up >> -- Defined-By: systemd >> -- Support: https://url.emailprotection.link/?aU9kur6wsNUi02sZK7jqbqHUDJAa-o4ToSDYQrs9syxvrrIdB1sQAdzV3HPUijEgCYM0mtOEY4w7RKS2IUkVivQ~~ > At a minimum, run cryptsetup directly (not through systemd) with the > --debug flag and post back with the output thus obtained. > [-- Attachment #2: Type: text/html, Size: 3402 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dm-crypt] problems mounting encrypted drive on reboot 2017-09-21 16:28 ` Jerry Lowry @ 2017-09-21 16:49 ` Arno Wagner 2017-09-29 17:37 ` Milan Broz 1 sibling, 0 replies; 8+ messages in thread From: Arno Wagner @ 2017-09-21 16:49 UTC (permalink / raw) To: dm-crypt You would think that. Unfortunately, the systemd people are trying to replace a lot of things that worked well before, not just cryptsetup. My guess would be this is an attempt at embrace-extend-extinguish and I can only recommend to avoid systemd altogether. This group here is the original group for cryptsetup, the systemd version is an, apparently badly made, clone. Regards, Arno On Thu, Sep 21, 2017 at 18:28:34 CEST, Jerry Lowry wrote: > If that's what you _really_ did, I'm pretty sure it can't have worked. > The newline notwithstanding, whitespace still matters, and there is no > --verify parameter (you probably meant to use --verify-passphrase). > > Yes, I did you verify-passphrase, just a typo! > So, from the replies that I have gotten it sounds like there are two > different camp ( groups) that are doing something with cryptsetup. > Isn't that a duplication of effort? > > ----------------------------------------------------------------------- > ---- > Jerold Lowry > Principal Network/Systems Engineer > Engineering Design Team (EDT), Inc. a HEICO company > 3423 NW John Olsen Pl > Hillsboro, Oregon 97124 (U.S.A.) > Phone: 503-690-1234 / 800-435-4320 > Fax: 503-690-1243 > Web: [1]www.edt.com > > > On 9/21/2017 12:25 AM, Michael Kjörling wrote: > > On 20 Sep 2017 15:38 -0700, from [2]jlowry@edt.com (Jerry Lowry): > > I have created an encrypted drive using the following commands: > > #>cryptsetup --verify=passphrase -- hash=sha256 --keyfile=/dir/file > create /dev/mapper/testcui /dev/sdb > > If that's what you _really_ did, I'm pretty sure it can't have worked. > The newline notwithstanding, whitespace still matters, and there is no > --verify parameter (you probably meant to use --verify-passphrase). > > > > Sep 20 14:19:53 jubilee systemd[1]: Starting Cryptography Setup for > /dev/mapper/testcui... > -- Subject: Unit [3]systemd-cryptsetup@-dev-mapper-testcui.service has > begun start-up > -- Defined-By: systemd > -- Support: [4]https://url.emailprotection.link/?aU9kur6wsNUi02sZK7jqbqHUDJAa-o4 > ToSDYQrs9syxvrrIdB1sQAdzV3HPUijEgCYM0mtOEY4w7RKS2IUkVivQ~~ > > At a minimum, run cryptsetup directly (not through systemd) with the > --debug flag and post back with the output thus obtained. > > References > > 1. http://www.edt.com/ > 2. mailto:jlowry@edt.com > 3. mailto:systemd-cryptsetup@-dev-mapper-testcui.service > 4. https://url.emailprotection.link/?aU9kur6wsNUi02sZK7jqbqHUDJAa-o4ToSDYQrs9syxvrrIdB1sQAdzV3HPUijEgCYM0mtOEY4w7RKS2IUkVivQ~~ > _______________________________________________ > dm-crypt mailing list > dm-crypt@saout.de > http://www.saout.de/mailman/listinfo/dm-crypt -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- A good decision is based on knowledge and not on numbers. -- Plato If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [dm-crypt] problems mounting encrypted drive on reboot 2017-09-21 16:28 ` Jerry Lowry 2017-09-21 16:49 ` Arno Wagner @ 2017-09-29 17:37 ` Milan Broz 1 sibling, 0 replies; 8+ messages in thread From: Milan Broz @ 2017-09-29 17:37 UTC (permalink / raw) To: Jerry Lowry, dm-crypt On 09/21/2017 06:28 PM, Jerry Lowry wrote: > If that's what you _really_ did, I'm pretty sure it can't have worked. > The newline notwithstanding, whitespace still matters, and there is no > --verify parameter (you probably meant to use --verify-passphrase). > > Yes, I did you verify-passphrase, just a typo! > > So, from the replies that I have gotten it sounds like there are two different camp ( groups) that are doing something with cryptsetup. Isn't that a duplication of effort? Ok, because you tried to hijack other thread and reply out of list privately, I'll try to explain it here: The systemd-cryptsetup uses libcryptsetup to activate devices. So the cryptsetup code is there only once, but systemd decides to "own" and parse /etc/crypttab with own tool - that's OK, crypttab was always owned by init and not by cryptsetup. For your journald log: I am not sure what the invalid parameter means, it could be bug but without additional debug log we cannot say. (systemd should enable better log, it is easy) Anyway, my guess is that you used keyfile in plain mode - then it is used directly as a key, hash parameter does not apply. If there is not enough data for key, it must fail. If you are configuring it with cryptsetup directly, you definitely should see this warning: WARNING: The --hash parameter is being ignored in plain mode with keyfile specified. (Or you have pretty old cryptsetup.) Anyway, if you cannot use LUKS (you should because it solves exactly these issues) then 1) generate keyfile form /dev/urandom, be sure it is at least of the size of encryption key (usually 32 bytes). (dd if=/dev/urandom of=/dir/file bs=1 count=32) 2) use this as keyfile, do not specify hash: cryptsetup --key-file=/dir/file create testcui /dev/sdb 3) then use the same keyfile in crypttab. it should work. m. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2017-09-29 17:37 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-09-20 22:38 [dm-crypt] problems mounting encrypted drive on reboot Jerry Lowry 2017-09-20 22:53 ` Arno Wagner 2017-09-20 22:59 ` Jerry Lowry 2017-09-21 7:27 ` Ondrej Kozina 2017-09-21 7:25 ` Michael Kjörling 2017-09-21 16:28 ` Jerry Lowry 2017-09-21 16:49 ` Arno Wagner 2017-09-29 17:37 ` Milan Broz
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.