View previous topic :: View next topic |
Author |
Message |
Hu Administrator
Joined: 06 Mar 2007 Posts: 22705
|
Posted: Wed Aug 03, 2022 1:08 pm Post subject: |
|
|
The partition containing a LUKS volume will have a PARTUUID. The block device exposed after LUKS is unlocked will not have a PARTUUID, but does not need one, because part of unlocking the LUKS device is picking the /dev/mapper name under which the decrypted device will appear. Therefore, you can control and predict that name, independent of the hardware, so you can use PARTUUID to refer to the partition containing the LUKS header+encrypted data, and use a name like /dev/mapper/my-chosen-name to refer to the decrypted LUKS device. |
|
Back to top |
|
|
pjp Administrator
Joined: 16 Apr 2002 Posts: 20488
|
Posted: Wed Aug 03, 2022 7:16 pm Post subject: |
|
|
X4DE wrote: | pietinger wrote: | X4DE wrote: | how can I specify the device for **dm-mod.create** with uuids instead of /dev/<block_name> ? |
AFAIK this is not possible because it accepts only major/minor number or /dev/xxxx (I am not sure about this). But if you want try, then try with PARTUUID and NOT with UUID (they are different). |
PARTUUIDs are only for partitions, sadly didn't worked for identifynig the luks partition | If you know the UUID, you might be able to identify the device associated with that UUID:
findmnt -no SOURCE /dev/disk/by-uuid/<UUID-separated-by-hyphnes> _________________ Quis separabit? Quo animo? |
|
Back to top |
|
|
dsreyes1014 n00b
Joined: 19 Oct 2015 Posts: 23
|
Posted: Tue Nov 15, 2022 4:08 pm Post subject: |
|
|
I'm a bit confused. Are we just using dm-mod.create="..." to input the plaincrypt key in the efistub? I just could not get this to work and not too sure how to debug any issues. |
|
Back to top |
|
|
pietinger Moderator
Joined: 17 Oct 2006 Posts: 5136 Location: Bavaria
|
Posted: Tue Nov 15, 2022 4:36 pm Post subject: |
|
|
dsreyes1014 wrote: | I'm a bit confused. Are we just using dm-mod.create="..." to input the plaincrypt key in the efistub? |
Yes.
This parameter is read by a kernel module (so it is not a kernel parm; it is a kernel module parm ) and configures it at kernel startup time; you COULD do the same configuration later with an init-script IF you want to decrypt another partition than root ...
dsreyes1014 wrote: | I just could not get this to work and not too sure how to debug any issues. |
As I wrote in my previous post I dont recommend this solution, but if you want to try, maybe a step-by-step installation could help. Try to make an efi-stub-kernel and do an UEFI boot. If this works, make a bootable USB stick (without encryption) and check if this works (boot from there). Now try to encrypt a (empty) test partition with dmcrypt. Then try again all steps described here.
Maybe my (german) article how to encrypt a home partition with dmcrypt can help to understand dmcrypt ?
https://forums.gentoo.org/viewtopic-p-8457358.html#8457358 |
|
Back to top |
|
|
dsreyes1014 n00b
Joined: 19 Oct 2015 Posts: 23
|
Posted: Tue Nov 15, 2022 4:44 pm Post subject: |
|
|
pietinger wrote: | This parameter is read by a kernel module (so it is not a kernel parm; it is a kernel module parm ) and configures it at kernel startup time; you COULD do the same configuration later with an init-script IF you want to decrypt another partition than root ... |
So should I make it a dm-mod.create= a module instead of builtin to the kernel? I have builtin at the moment
EDIT: Nevermind it only allows as builtin to the kernel. Dumb question sorry. |
|
Back to top |
|
|
|