Bug#920664: unable to decrypt drive from grub after alpha4 setup)
The debian package cryptsetup-initramfs does not seem present on the main system, judging from its absence from /usr/share/doc/. I'm not sure I've understood the question, however. I'm using this somewhat indirect indicator of the package because of the difficulty of getting into the system live. /var/cache/apt/archives/ has no packages with "crypt" in the name. /sbin/cryptsetup is present on the main system and the initrd I did create the encrypted partition through the installer's partition manager, so the installer should be aware of the encryption. I am using the standard kernel. But if the initrd doesn't have all the modules it needs, that might explain the problem. Ross On Sun, Feb 3, 2019 at 5:24 AM Ben Hutchings wrote: > On Sat, 2019-02-02 at 22:56 -0800, Ross Boylan wrote: > > I am able to decrypt the partition outside of a VM without the rescue > > "CD". Since I can also decrypt using the installer CD as rescue, this > > means the failure is specific to booting via grub and initrd. > > > > This seems to indicate the installer created the encrypted partition > > properly but the boot environment it created is either handling the > > pass-phrase incorrectly (e.g., include \n) or is missing some other part > of > > the machinery necessary. The most obvious candidate is from the error > > message > > > Check that kernel supports aes-xts-plain64 cipher > > > > I don't know how to check that, but looking in config-4.19.0-1-amd64 on > the > > boot partition, I see some partial matches that might be relevant: > > CONFIG_CRYPTO_AES=y > > # CONFIG_CRYPTO_AES_TI is not set > > CONFIG_CRYPTO_AES_X86_64=m > > CONFIG_CRYPTO_AES_NI_INTEL=m > > > > CONFIG_CRYPTO_XTS=m > > > > I don't see anything that looks like plain. > > You can't easily map crypto modes to config options like this. But if > you are using the standard kernel, I can assure that it supports full > disk encryption. > > > The buster system created by the installer includes aesni-intel.ko, but > the > > initrd does not. > > cryptsetup-initramfs should have been installed, and it would add the > crypto modules (and other necessary files) to the initramfs. Is it > installed? > > Ben. > > -- > Ben Hutchings > Horngren's Observation: > Among economists, the real world is often a special case. > > >
Bug#920664: unable to decrypt drive from grub after alpha4 setup)
On Sat, 2019-02-02 at 22:56 -0800, Ross Boylan wrote: > I am able to decrypt the partition outside of a VM without the rescue > "CD". Since I can also decrypt using the installer CD as rescue, this > means the failure is specific to booting via grub and initrd. > > This seems to indicate the installer created the encrypted partition > properly but the boot environment it created is either handling the > pass-phrase incorrectly (e.g., include \n) or is missing some other part of > the machinery necessary. The most obvious candidate is from the error > message > > Check that kernel supports aes-xts-plain64 cipher > > I don't know how to check that, but looking in config-4.19.0-1-amd64 on the > boot partition, I see some partial matches that might be relevant: > CONFIG_CRYPTO_AES=y > # CONFIG_CRYPTO_AES_TI is not set > CONFIG_CRYPTO_AES_X86_64=m > CONFIG_CRYPTO_AES_NI_INTEL=m > > CONFIG_CRYPTO_XTS=m > > I don't see anything that looks like plain. You can't easily map crypto modes to config options like this. But if you are using the standard kernel, I can assure that it supports full disk encryption. > The buster system created by the installer includes aesni-intel.ko, but the > initrd does not. cryptsetup-initramfs should have been installed, and it would add the crypto modules (and other necessary files) to the initramfs. Is it installed? Ben. -- Ben Hutchings Horngren's Observation: Among economists, the real world is often a special case. signature.asc Description: This is a digitally signed message part
Bug#920664: unable to decrypt drive from grub after alpha4 setup)
I am able to decrypt the partition outside of a VM without the rescue "CD". Since I can also decrypt using the installer CD as rescue, this means the failure is specific to booting via grub and initrd. This seems to indicate the installer created the encrypted partition properly but the boot environment it created is either handling the pass-phrase incorrectly (e.g., include \n) or is missing some other part of the machinery necessary. The most obvious candidate is from the error message > Check that kernel supports aes-xts-plain64 cipher I don't know how to check that, but looking in config-4.19.0-1-amd64 on the boot partition, I see some partial matches that might be relevant: CONFIG_CRYPTO_AES=y # CONFIG_CRYPTO_AES_TI is not set CONFIG_CRYPTO_AES_X86_64=m CONFIG_CRYPTO_AES_NI_INTEL=m CONFIG_CRYPTO_XTS=m I don't see anything that looks like plain. The buster system created by the installer includes aesni-intel.ko, but the initrd does not. Ross
