Re: encrypted boot won't work

[jnqnfe]

Another update:

Part 1.

Immediately after my last update I had a play at busybox and had some
success. It was complaining that it could not find root_crypt, so,
since cryptsetup was available in busybox, I simply opened the device
with cryptsetup, using the root_crypt label, then I used the command
`exit`, allowing it to try again, at which point it then successfully
found it. I was then prompted for the boot device password (which grub
did not pass along), and then a password for an additional volume,
before arriving at the gnome login.

This is far from ideal, mostly due to the time it takes to give up
trying to find the device (a good minute or so) before dropping to
busybox. At leat I can navigate my way through it though and use the
machine.

Regarding the en-US vs. en-GB keyboard layout issue, I have not looked
into this aspect yet.

Another issue I encountered was that after a kernel update it would
always boot the older one, with the initial grub menu (prior to
unlocking /boot) only offering the old one. I had tried an `update-
grub` to no avail, and the grub.cfg seems to have entries for the new
version...

Part 2.

Just now I happened to re-run both `update-initramfs -u` and `update-
grub` and some things have improved. Now I see no grub menu prior to
unlocking /boot, it just gives me a black screen for a short while
before displaying the password prompt. I'm not sure if that's better or
not (the blue grub menu is not the prettiest thing). Unlocking /boot
then takes me to a prompt for the root_crypt password, without dropping
to busybox, which is great. Also, the kernel version used is now the
new one.

So that's a big step in the right direction. I don't know why I had to
manually force an update of the initrd to get things straight though.

The major pain is that after unlocking /boot, it then takes a full
minute before I can unlock root_crypt because there's some sort of
problem to do with ata goning on (I did not write down the details).

(I'm mostly bothering to provide an update to help guide anyone else
who might experience similar issue to me and land here in the future).

On Thu, 2020-03-12 at 22:45 +0000, address@hidden wrote:
> Update: So I've just taken another look at this system. Wanting to
> eliminate password problems just to be absolutely certain, I used a
> live disc to change the password to something very simple.
> 
> Rebooting and trying this it successfully moves further forward than
> before. What I am thinking is that grub perhaps is using an en-US
> keyboard layout whilst I had en-UK enabled in the environment in
> which
> I had set things up. This would explain why it was telling me that
> the
> password entered was wrong, despite certainty that I had entered it
> correctly, and despite things working fine in an en-UK live disc
> environment. I guess I expected grub to just work correctly with my
> configured locale just as cryptsetup does for opening the encrypted
> root, but that was perhaps naive.
> 
> Is it possible to configure grub to use a different keyboard layout?
> 
> So now with the simple password it manages to get further than
> before,
> but ends up at a busybox shell.
> ```
> Gave up waiting for root file system device. Common problems:
>  - Boot args (cat /proc/cmdline)
>     - Check rootdelay= (did the system wait long enough?)
>  - Missing modules (cat /proc/modules: ls /dev)
> ALERT!  /dev/mapper/root_crypt does not exist. Dropping to shell!
> ```
> 
> Note that the below instructions missed mentioning that I had indeed
> done the `GRUB_ENABLE_CRYPTODISK="y"` step.
> 
> On Fri, 2020-02-28 at 07:35 +0000, address@hidden wrote:
> > I decided to play with having an encrypted /boot on an old system
> > but
> > I
> > cannot boot with it and I don't know why. Please advise.
> > 
> > The system has UEFI. The disk uses GPT. Grub version is 2.04-5
> > (debian).
> > 
> > Procedure followed:
> >  - The system already had encrypted root (luks v2)
> >  - I am aware that grub currently only supports luks v1 for
> > encrypted
> > /boot
> >  1) made a backup of all contents of /boot (excluding /boot/efi)
> >  2) unmounted /boot/efi and /boot
> >  3) overwrote /dev/sda2 (/boot) with cryptsetup as a new luks v1
> > volume
> >  4) opened the new encrypted /dev/sda2
> >  5) created an ext4 filesystem inside it
> >  6) copied all of the backed up files into it
> >  7) ensured that all of the ownership and permissions for them was
> > correct (comparing with another system)
> >  8) remounted as /boot
> >  9) remounted /dev/sda1 as /boot/efi
> >  10) added an entry to /etc/crypttab
> >  11) adjusted /etc/fstab
> >  12) ran `update-initramfs -u` and `update-grub` (not sure which
> > order
> > if it matter, pretty sure I've run them each multiple times now
> > anyway)
> >  13) rebooted
> > 
> > note, below i've replaced the real UUID's with simple replacements
> > like
> > 'aaa'...
> > 
> > the partition table looks like this:
> > 
> > NAME                    FS     UUID  MOUNT
> > /dev/sda1               fat32  aaa   /boot/efi
> > /dev/sda2               -      bbb   -
> > /dev/sda3               -      ccc   -
> > /dev/mapper/sda2_crypt  ext4   ddd   /boot
> > /dev/mapper/sda3_crypt  ext4   eee   /
> > 
> > when I boot, I get a prompt like this:
> > attempting to decrypt master key...
> > enter passphrase for hd0,gpt2 (bbb):
> > 
> > but several moments after entering the password I get:
> > error:access denied
> > error: no such cryptodisk found
> > error: no such device: ddd
> > Loading Linux 5.4.0-3-amd64 ...
> > error: no server specified
> > Loading initial ramdisk ...
> > error: you need to load the kernel first
> > 
> > crypttab:
> > ```
> > boot_crypt UUID=bbb none luks
> > root_crypt UUID=ccc none luks
> > ```
> > 
> > fstab:
> > ```
> > # <file system>  <mount point>  <type>  <options>  <dump>  <pass>
> > /dev/mapper/root_crypt  /  ext4  errors=remount-ro  0  1
> > /dev/mapper/boot_crypt  /boot  ext4  errors=remount-ro  0  2
> > UUID=aaa                /boot/efi  vfat  umask=0077  0  2
> > /dev/sr1                /media/cdrom0  udf,iso9660  user,noauto  0 
> >  0
> > /dev/sr0                /media/cdrom1  udf,iso9660  user,noauto  0 
> >  0
> > /swapfile               none  swap  defaults  0  0
> > ```
> > 
> > /boot/grub.cfg (autogenerated) looks like this (stripped down):
> > ```
> > insmod luks
> > insmod cryptodisk
> > ...
> > if [ x$feature_default_font_path = xy ] ; then
> >     font=unicode
> > else
> >     insmod ext2
> >     set root='hd0'
> >     if [ x$feature_platform_search_hint = xy ]; then
> >         search --no-floppy --fs-uuid --set=root --hint-bios=hd0 --
> > hint-
> > efi=hd0 --hint-baremetal=ahci0  eee
> >     else
> >         search --no-floppy --fs-uuid --set=root eee
> >     fi
> >     font="/usr/share/grub/unicode.pf2"
> > fi
> > ...
> > insmod ext2
> > set root='hd0'
> > if [ x$feature_platform_search_hint = xy ]; then
> >     search --no-floppy --fs-uuid --set=root --hint-bios=hd0 --hint-
> > efi=hd0 --hint-baremetal=ahci0  eee
> > else
> >     search --no-floppy --fs-uuid --set=root eee
> > fi
> > ...
> > menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --
> > class
> > gnu --class os $menuentry_id_option 'gnulinux-simple-eee' {
> >     ...
> >     insmod cryptodisk
> >     insmod luks
> >     insmod gcry_rijndael
> >     insmod gcry_rijndael
> >     insmod gcry_sha256
> >     insmod ext2
> >     cryptomount -u bbb
> >     set root='cryptouuid/bbb'
> >     if [ x$feature_platform_search_hint = xy ]; then
> >       search --no-floppy --fs-uuid --set=root --hint-bios=hd0 --
> > hint-efi=hd0 --hint-baremetal=ahci0 --hint='cryptouuid/bbb'  ddd
> >     else
> >       search --no-floppy --fs-uuid --set=root ddd
> >     fi
> >     echo    'Loading Linux 5.4.0-3-amd64 ...'
> >     linux   /vmlinuz-5.4.0-3-amd64 root=UUID=eee ro
> > cryptdevice=/dev/sda3:root root=/dev/mapper/root_crypt quiet
> >     echo    'Loading initial ramdisk ...'
> >     initrd  /initrd.img-5.4.0-3-amd64
> > }
> > submenu 'Advanced options for Debian GNU/Linux'
> > $menuentry_id_option
> > 'gnulinux-advanced-eee' {
> >     ...
> > }
> > ...
> > ```
> > 
> > I can unlock /dev/sda2 fine with cryptsetup in a live environment
> > (as
> > well as /dev/sda3), so it surely cannot be as simple as entering
> > the
> > wrong password...
> >