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.
Thanks,
/D
Reply to: