[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Encrypted containers & the Debian installer.

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 <deblis@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 installs
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.


Reply to: