On 05/18/2018 08:35 AM, David Wright wrote: > On Thu 17 May 2018 at 22:24:01 (-0700), Diagonal Arg wrote: >> ---- On Wed, 16 May 2018 07:42:42 -0700 David Wright >> <deb...@lionunicorn.co.uk> wrote ---- >> > On Tue 15 May 2018 at 23:05:10 (-0700), Diagonal Arg wrote: >> > > >> > > On my first tries with the Debian installer, I am struggling with the >> limited resources for installing to encrypted disks. I am using the same >> technique I have used with Ubuntu, but failing at the last step: >> > > >> > > I create my luks disk(s) before-hand, then run the installer. I find I >> have to anna-install cryptsetup-udeb, as there is no such choice in "Load >> Installer Modules". Dropping to a shell, opening the disk, and >> re-detecting hard drives allows me to carry out the installation (as long as >> there's a filesystem in the mapped device), but on reboot I'm at an >> initramfs without cryptsetup. So I use a debian-live to pivot into the >> system to create a crypttab. I find I also have to install cryptsetup. >> Then I run update-initramfs. Here is where I'm stuck. The new initramfs >> still does not include cryptsetup. Why is it not recognizing the crypttab? >> > >> > │ [ ] crypto-dm-modules-4.9.0-2-686-di: devicemapper crypto module >> ▮ │ >> >> David - thanks, but crypto-dm-modules does not include cryptsetup. >> >> And, even when I anna-install it, it doesn't help with the other issues I >> mentioned above. > > OK, well I haven't got time to check this out but here's my guess of > what's going on. I've never used anna-install to play tricks behind > the installer's back.
I understand, though it is odd that the installer installes crypto-dm-modules, but waits to install cryptsetup until such time as the partitioner is used to make an encrypted device. Why would that be? > If you take upon yourself the unlocking of > encrypted disks and then use the d-i to build a system, the d-i may > be unaware that there are any encrypted partitions in the installation. That is indeed the case with Ubuntu, so I assumed it would be the same here. What is different is that after install, when I pivot into my new system, fixing cryptab, installing cryptsetup, and updating initramfs does not end up including cryptsetup in initramfs. > I can also see from other people's comments elsewhere that you might > be within a hair's breadth of wiping your encrypted partition(s) > during this process. Well, they certainly /seem/ to be fine. I am for example, able to do an apt-get update && apt-get install after I pivot in. > However, just to get the necessary software > installed by the d-i in the final product, a workaround to try > might be to create during installation an encrypted partition on, > say, a nonce stick for a nonce mountpoint. Ok, I'm not sure what a nonce stick/mountpoint is. I'm sure this is unrelated, by I am putting /boot on a USB stick and / on the luks container which takes the the whole hard drive. > As I say, I haven't tried it out. Risks are that using the d-i's > partitioner to encrypt the stick does something simultaneously to > the original partitions you're trying to preserve, and also the > /etc/crypttab that gets written will want the stick to be present > at first boot (before you rewrite it). > > Sometime I will try this out on a scratch PC. I have run a number of experiments in a VM. That seems to be the easiest approach. > Mine all have room > for two systems, so I can install A, encrypted in the usual manner > and then try installing on the B root partition, keeping the > shared encrypted /home partition. (I haven't used LVM so can't > see how that would interact with things.) I'm not using LVM. > Cheers, > David. /D
