Thanks Martin. I am not running Arch but will try to adapt
this to Slint.
Cheers,
Didier
Le 14/01/2021 à 00:10, Martin Jørgensen a écrit :
Hi,
I've done this many times, however mostly on Arch Linux. Please see:
https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#Avoiding_having_to_enter_the_passphrase_twice
I've also done it on Debian once. About your "GRUB_ENABLE_CRYPTODISK=y".
Yes, you should definately encrypt the boot-partition and then either
the home/root-partition so yes, you need GRUB to understand an encrypted
boot-partition - AFAIR you need LUKS1-encryption for the boot-partition
(due to a limitation in GRUB) but you can use LUKS2-for the encrypted
root/home, at least that's how I remember it - don't know if things
changed since last time I checked (I think LUKS2 for GRUB will be
implemented in near future if it hasn't already been)...
The basic idea is (and I quote from the link): "While GRUB asks for a
passphrase to unlock the LUKS1 encrypted partition after above
instructions, the partition unlock is not passed on to the initramfs.
Hence, you have to enter the passphrase twice at boot: once for GRUB and
once for the initramfs.
This section deals with extra configuration to let the system boot by
only entering the passphrase once, in GRUB. This is accomplished by with
a keyfile embedded in the initramfs
<https://wiki.archlinux.org/index.php/Dm-crypt/Device_encryption#With_a_keyfile_embedded_in_the_initramfs>."
So - the initramfs needs to be stored _*/inside/*_ the encrypted
boot-partition so when you unlock it, you have the decrypted keyfiles,
which are used to unlock/decrypt home/root-partition (you choose if you
wish to encrypt only home or the hole root-partition). Then use
/etc/crypttab to make the decrypted partition available to your
linux-system, as it's booting up.
If not on Arch, you'll have to figure out how to embed your keyfile in
the initramfs, but follow more or less the same steps - at least that's
how I do it every single time, I don't know any other way to accomplish
this. Took me many hours the first time, googling, testing, write down
every step you do so you can redo it again.
Good luck.
Br,
Martin
On Wed, Jan 13, 2021 at 10:43 PM Didier Spaier <didier@xxxxxxxx
<mailto:didier@xxxxxxxx>> wrote:
Hi,
I maintain the Slint distribution (Slackware derivative
internationalized and
accessible to the blind).
Our installer uses GRUB as boot manager and boot loader in both
Legacy and
EFI modes.
To help beginners I have added the 'auto' mode to the Slint installer
which in
case of a drive dedicated to Slint sets up a very simple layout of
the GPT:
_A Bios Boot partition for booting GRUB in legacy mode
_An EFI system partition
_A root (/) partition
_Optionally an additional partition (mount point suggested: /data)
_No swap partition: the installer sets up a swap file and a swap space
in zram.
I would like that the 'auto' script offer an option for encrypting
the whole
drive if dedicated to Slint, using LUKS without relying on LVM to
keep the
drive's layout as simple as possible to be easily understood by a
74y old
grand father. I do belong to this category :-)
I assume that I will have to set GRUB_ENABLE_CRYPTODISK in
/etc/default.grub.
I would like that the user type the passphrase only once. We always
use an
initrd, built after having installed the kernel at time of installation,
rebuilt at each kernel upgrade, so I can modify its set up as need be.
I have tried to find on the Internet examples of settings matching this
specification but didn't find one on the Wiki or on the Arch wiki, but
these:
https://unixsheikh.com/tutorials/real-full-disk-encryption-using-grub-on-void-linux-for-bios.html
https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html
Although they do not exactly match my specifications and/or use tools I
don't ship, if I have to I will take one of them as a basis.
However I'd glad for help on how-to provides this "type the
passphrase only
once, don't modify the drive's layout and don't use LVM" feature, be
it just
answering this message or giving me pointers to relevant documents.
Thanks in advance
Dider Spaier, Paris, France
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx <mailto:dm-crypt@xxxxxxxx>
https://www.saout.de/mailman/listinfo/dm-crypt
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
https://www.saout.de/mailman/listinfo/dm-crypt
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
https://www.saout.de/mailman/listinfo/dm-crypt
