Debian Stretch, no password prompt for luks-encrypted home partition during boot

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Debian Stretch, no password prompt for luks-encrypted home partition during boot

Sergey Belyashov
I have system with soft raid and /home is encrypted (luks with password). When I boot it using default boot kernel options (ro quiet) systemd stops on waiting for partition, but no any password prompt. I try to boot with plymouth (ro quiet splash), but it does not help me. I may boot only using "recovery mode". In this case system asks me for password and I may enter it (but there are lot of kernel messages after prompt).
update-initramfs finishes without errors or warnings.
What I'm doing wrong?

Best regards,
Sergey Belyashov

Additional information:

mdadm.conf:
ARRAY /dev/md0 metadata=0.90 UUID=91f74976:a3538ec7:cb201669:f728008a
ARRAY /dev/md1 metadata=1.2 UUID=d68931c6:642d72fc:b7471e62:33eab4d7 name=my-server:1
ARRAY /dev/md2 metadata=1.2 UUID=c42e4696:cb876ca7:c2773edf:e9b17a82 name=my-server:2

/proc/mdstat:
md0 : active raid1 sda3[0] sdc3[1]
      1462886848 blocks [2/2] [UU]
     
md1 : active (auto-read-only) raid1 sdc2[1] sda2[0]
      1998848 blocks super 1.2 [2/2] [UU]
     
md2 : active raid1 sdc1[1] sda1[0]
      248640 blocks super 1.2 [2/2] [UU]

crypttab:
#UUID=e7a2e597-8f57-4faf-b32d-f24b5720ffe5 same as /dev/md0p3
crypto-home UUID=e7a2e597-8f57-4faf-b32d-f24b5720ffe5 none luks

fstab:
/dev/md0p1                                         /               ext4    errors=remount-ro 0       1
/dev/md0p2                                         /var            ext4    defaults        0       2
/dev/md1                                             none            swap    sw              0       0
/dev/md2                                             /boot           ext4    defaults        0       2
/dev/mapper/crypto-home                   /home           auto    defaults        0       2
...

$ egrep "^CRYPTSETUP" /etc/cryptsetup-initramfs/conf-hook
CRYPTSETUP=y

$ uname -a
Linux my-server 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u2 (2019-05-13) x86_64 GNU/Linux

systemd has version: 232-25+deb9u11
cryptsetup has version: 2:1.7.3-4
initramfs-tools has version: 0.130
Reply | Threaded
Open this post in threaded view
|

Fwd: Debian Stretch, no password prompt for luks-encrypted home partition during boot

Sergey Belyashov
I have system with soft raid and /home is encrypted (one of raid1 partitions is encrypted using luks with password). When I boot it using default boot kernel options (ro quiet) systemd stops on waiting for partition, but no any password prompt. I try to boot with plymouth (ro quiet splash), but it does not help me. I may boot only using "recovery mode". In this case system asks me for password and I may enter it (but there are lot of kernel messages after prompt).
update-initramfs finishes without errors or warnings.
What I'm doing wrong?

Best regards,
Sergey Belyashov

Additional information:

mdadm.conf:
ARRAY /dev/md0 metadata=0.90 UUID=91f74976:a3538ec7:cb201669:f728008a
ARRAY /dev/md1 metadata=1.2 UUID=d68931c6:642d72fc:b7471e62:33eab4d7 name=my-server:1
ARRAY /dev/md2 metadata=1.2 UUID=c42e4696:cb876ca7:c2773edf:e9b17a82 name=my-server:2

/proc/mdstat:
md0 : active raid1 sda3[0] sdc3[1]
      1462886848 blocks [2/2] [UU]
     
md1 : active (auto-read-only) raid1 sdc2[1] sda2[0]
      1998848 blocks super 1.2 [2/2] [UU]
     
md2 : active raid1 sdc1[1] sda1[0]
      248640 blocks super 1.2 [2/2] [UU]

crypttab:
#UUID=e7a2e597-8f57-4faf-b32d-f24b5720ffe5 same as /dev/md0p3
crypto-home UUID=e7a2e597-8f57-4faf-b32d-f24b5720ffe5 none luks

fstab:
/dev/md0p1                                         /               ext4    errors=remount-ro 0       1
/dev/md0p2                                         /var            ext4    defaults        0       2
/dev/md1                                             none            swap    sw              0       0
/dev/md2                                             /boot           ext4    defaults        0       2
/dev/mapper/crypto-home                   /home           auto    defaults        0       2
...

$ egrep "^CRYPTSETUP" /etc/cryptsetup-initramfs/conf-hook
CRYPTSETUP=y

$ uname -a
Linux my-server 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u2 (2019-05-13) x86_64 GNU/Linux

systemd has version: 232-25+deb9u11
cryptsetup has version: 2:1.7.3-4
initramfs-tools has version: 0.130
Reply | Threaded
Open this post in threaded view
|

Re: Debian Stretch, no password prompt for luks-encrypted home partition during boot

Ross Boylan-2
For at least the last couple of weeks I've had the screen go
completely blank during bootup, after displaying initial messages (I
changed from "quiet" to "debug" for kernel startup).  This is with a
luks encrypted root.  I saw it under jessie and buster.  I blamed
failing hardware (I can't get into the BIOS on boot because the screen
goes black), though I noticed the same behavior in a VM.

I've discovered that if I type my pass-phrase (waiting long enough
that I think things have settled down), the system boots.

So, you might try typing your luks passphrase and see if it helps.

And maybe something has changed in the tools or kernel that's causing
the misbehavior, although jessie hasn't been changing much recently.

Ross

Reply | Threaded
Open this post in threaded view
|

Re: Debian Stretch, no password prompt for luks-encrypted home partition during boot

Sergey Belyashov
My problem is about than year old or more. With default options (without plymouth) only information about root partition mount or fsck. Later it replaced by partition waiting "progress" (moving red asterisks). I have try to wait about a minute and try to enter luks password, but no any changes. I think, problem is in complex setup luks on mdraid.

Best regards,
Sergey Belyashov

вт, 28 мая 2019 г., 6:26 Ross Boylan <[hidden email]>:
For at least the last couple of weeks I've had the screen go
completely blank during bootup, after displaying initial messages (I
changed from "quiet" to "debug" for kernel startup).  This is with a
luks encrypted root.  I saw it under jessie and buster.  I blamed
failing hardware (I can't get into the BIOS on boot because the screen
goes black), though I noticed the same behavior in a VM.

I've discovered that if I type my pass-phrase (waiting long enough
that I think things have settled down), the system boots.

So, you might try typing your luks passphrase and see if it helps.

And maybe something has changed in the tools or kernel that's causing
the misbehavior, although jessie hasn't been changing much recently.

Ross
Reply | Threaded
Open this post in threaded view
|

Re: Debian Stretch, no password prompt for luks-encrypted home partition during boot

deloptes-2
Sergey Belyashov wrote:

> My problem is about than year old or more. With default options (without
> plymouth) only information about root partition mount or fsck. Later it
> replaced by partition waiting "progress" (moving red asterisks). I have
> try to wait about a minute and try to enter luks password, but no any
> changes. I think, problem is in complex setup luks on mdraid.

Is the root partition on mdraid and encrypted?

What happens when you set modules to most
in /etc/initramfs-tools/initramfs.conf?

regards

Reply | Threaded
Open this post in threaded view
|

Re: Debian Stretch, no password prompt for luks-encrypted home partition during boot

deloptes-2
In reply to this post by Ross Boylan-2
Ross Boylan wrote:

> I've discovered that if I type my pass-phrase (waiting long enough
> that I think things have settled down), the system boots.
>

Have you tried setting up the display parameters properly in grub? Sometimes
on notebooks the default settings are different and do not match predefined
values in grub

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480
GRUB_GFXMODE=1280x1024
GRUB_GFXPAYLOAD_LINUX=keep


Reply | Threaded
Open this post in threaded view
|

Re: Debian Stretch, no password prompt for luks-encrypted home partition during boot

Sergey Belyashov
In reply to this post by deloptes-2
Root partition is on mdraid but is not encrypted. Home is encrypted only. Modules are set to most already.

вт, 28 мая 2019 г., 9:06 deloptes <[hidden email]>:
Sergey Belyashov wrote:

> My problem is about than year old or more. With default options (without
> plymouth) only information about root partition mount or fsck. Later it
> replaced by partition waiting "progress" (moving red asterisks). I have
> try to wait about a minute and try to enter luks password, but no any
> changes. I think, problem is in complex setup luks on mdraid.

Is the root partition on mdraid and encrypted?

What happens when you set modules to most
in /etc/initramfs-tools/initramfs.conf?

regards

Reply | Threaded
Open this post in threaded view
|

Re: Debian Stretch, no password prompt for luks-encrypted home partition during boot

deloptes-2
Sergey Belyashov wrote:

> Root partition is on mdraid but is not encrypted. Home is encrypted only.
> Modules are set to most already.
>

I have this setup on my server, but I removed all crypted entries from fstab
because obviously I can not sit infront of the server to type the password
when booting. So I can not help in this case much. I put all of this in a
script that I execute after I ssh to the server.

On the clients I have root encrypted. I had issues in the beginning after
transfering the system from dbootstrap to the disk. In that case the UUIDs
were not correct. I always did set the init=/bin/sh on the command line in
grub to get the shell and debugged. Sometimes it is useful to add
a "rootdelay" to wait for the root device to get available, but in your
setup it looks like it is not exactly what you would need.

When the system boots it would read whatever you have in your initrd. It
would load the drivers and perform the boot process. Then it will pass
control to init and run the rest from the root system. IMO mounting home
comes in this second stage, but I am not 100% sure. What do you see when
you enable debug or verbose - what does it say when booting.

Also you have the fs type in fstab set to auto for your home - what happens
if you set the exact fs type like ext4 or xfs?

Do a change at a time and test after this.

regards





Reply | Threaded
Open this post in threaded view
|

Re: Debian Stretch, no password prompt for luks-encrypted home partition during boot

Sergey Belyashov
I'll try your suggestion. But I think problem is not here. Password ask is after mounting all other filesystems, swapon and flush of journald:

[    9.986320] intel_rapl: Found RAPL domain uncore
[   10.203636] EXT4-fs (md0p2): mounted filesystem with ordered data mode. Opts: (null)
[   10.203981] Adding 1998844k swap on /dev/md1.  Priority:-1 extents:1 across:1998844k FS
[   10.284033] systemd-journald[314]: Received request to flush runtime journal from PID 1
[   10.677656] EXT4-fs (md2): mounted filesystem with ordered data mode. Opts: (null)
[   21.735417] NET: Registered protocol family 38
[   22.029828] XFS (dm-0): Mounting V4 Filesystem
[   22.188883] XFS (dm-0): Ending clean mount
[   22.892609] r8169 0000:05:01.0 eth1: link down
[   22.892644] r8169 0000:05:01.0 eth1: link down
[   22.895138] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[   24.472245] r8169 0000:05:01.0 eth1: link up

вт, 28 мая 2019 г., 9:38 deloptes <[hidden email]>:
Sergey Belyashov wrote:

> Root partition is on mdraid but is not encrypted. Home is encrypted only.
> Modules are set to most already.
>

I have this setup on my server, but I removed all crypted entries from fstab
because obviously I can not sit infront of the server to type the password
when booting. So I can not help in this case much. I put all of this in a
script that I execute after I ssh to the server.

On the clients I have root encrypted. I had issues in the beginning after
transfering the system from dbootstrap to the disk. In that case the UUIDs
were not correct. I always did set the init=/bin/sh on the command line in
grub to get the shell and debugged. Sometimes it is useful to add
a "rootdelay" to wait for the root device to get available, but in your
setup it looks like it is not exactly what you would need.

When the system boots it would read whatever you have in your initrd. It
would load the drivers and perform the boot process. Then it will pass
control to init and run the rest from the root system. IMO mounting home
comes in this second stage, but I am not 100% sure. What do you see when
you enable debug or verbose - what does it say when booting.

Also you have the fs type in fstab set to auto for your home - what happens
if you set the exact fs type like ext4 or xfs?

Do a change at a time and test after this.

regards





Reply | Threaded
Open this post in threaded view
|

Fwd: Debian Stretch, no password prompt for luks-encrypted home partition during boot

Sergey Belyashov
In reply to this post by deloptes-2
As expected nothing is changed. I did not forget to run update-initramfs after change of fstab.
Attached 3 photos: normal boot, recovery boot before pasword enter, recovery boot after password and Ctrl-D in recovery shell.

Best regards,
Sergey Belyashov

вт, 28 мая 2019 г., 9:38 deloptes <[hidden email]>:
Sergey Belyashov wrote:

> Root partition is on mdraid but is not encrypted. Home is encrypted only.
> Modules are set to most already.
>

I have this setup on my server, but I removed all crypted entries from fstab
because obviously I can not sit infront of the server to type the password
when booting. So I can not help in this case much. I put all of this in a
script that I execute after I ssh to the server.

On the clients I have root encrypted. I had issues in the beginning after
transfering the system from dbootstrap to the disk. In that case the UUIDs
were not correct. I always did set the init=/bin/sh on the command line in
grub to get the shell and debugged. Sometimes it is useful to add
a "rootdelay" to wait for the root device to get available, but in your
setup it looks like it is not exactly what you would need.

When the system boots it would read whatever you have in your initrd. It
would load the drivers and perform the boot process. Then it will pass
control to init and run the rest from the root system. IMO mounting home
comes in this second stage, but I am not 100% sure. What do you see when
you enable debug or verbose - what does it say when booting.

Also you have the fs type in fstab set to auto for your home - what happens
if you set the exact fs type like ext4 or xfs?

Do a change at a time and test after this.

regards





Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Debian Stretch, no password prompt for luks-encrypted home partition during boot

deloptes-2
Sergey Belyashov wrote:

> As expected nothing is changed. I did not forget to run update-initramfs
> after change of fstab.
> Attached 3 photos: normal boot, recovery boot before pasword enter,
> recovery boot after password and Ctrl-D in recovery shell.

I am not a systemd expert. The images does not speak to me. You could try as
suggested adding init=/bin/sh and see what is in the initrd and what works
and does not work.

You could extract the initrd to investigate what is in there - or to
remaster and test updated version.

https://wiki.debian.org/initramfs

In my case following works (microcode size here is 4712) as I do not have
unmakeinitramfs.

dd if=/boot/initrd.img-4.19.25eko4 bs=512 skip=4712 | zcat - |cpio -i

Finally you can try installing sysvinit-core & Co and see if it makes a
difference or someone else can help you better

regards

Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Debian Stretch, no password prompt for luks-encrypted home partition during boot

Sergey Belyashov
I have examine initramfs image and found that it is not tries to mount encrypted partitions other than root. Moreover, it is confirmed by dmesg output: systemd starts before mounting of /var and /home So it is not initrd problem. Problem somethere in system.

Best regards,
Sergey Belyashov

вт, 28 мая 2019 г. в 23:14, deloptes <[hidden email]>:
Sergey Belyashov wrote:

> As expected nothing is changed. I did not forget to run update-initramfs
> after change of fstab.
> Attached 3 photos: normal boot, recovery boot before pasword enter,
> recovery boot after password and Ctrl-D in recovery shell.

I am not a systemd expert. The images does not speak to me. You could try as
suggested adding init=/bin/sh and see what is in the initrd and what works
and does not work.

You could extract the initrd to investigate what is in there - or to
remaster and test updated version.

https://wiki.debian.org/initramfs

In my case following works (microcode size here is 4712) as I do not have
unmakeinitramfs.

dd if=/boot/initrd.img-4.19.25eko4 bs=512 skip=4712 | zcat - |cpio -i

Finally you can try installing sysvinit-core & Co and see if it makes a
difference or someone else can help you better

regards

Reply | Threaded
Open this post in threaded view
|

Re: Debian Stretch, no password prompt for luks-encrypted home partition during boot

Sergey Belyashov
In reply to this post by Sergey Belyashov
I have found related bug in the Debian bug system: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868164

пн, 27 мая 2019 г. в 13:09, Sergey Belyashov <[hidden email]>:
I have system with soft raid and /home is encrypted (luks with password). When I boot it using default boot kernel options (ro quiet) systemd stops on waiting for partition, but no any password prompt. I try to boot with plymouth (ro quiet splash), but it does not help me. I may boot only using "recovery mode". In this case system asks me for password and I may enter it (but there are lot of kernel messages after prompt).
update-initramfs finishes without errors or warnings.
What I'm doing wrong?

Best regards,
Sergey Belyashov

Additional information:

mdadm.conf:
ARRAY /dev/md0 metadata=0.90 UUID=91f74976:a3538ec7:cb201669:f728008a
ARRAY /dev/md1 metadata=1.2 UUID=d68931c6:642d72fc:b7471e62:33eab4d7 name=my-server:1
ARRAY /dev/md2 metadata=1.2 UUID=c42e4696:cb876ca7:c2773edf:e9b17a82 name=my-server:2

/proc/mdstat:
md0 : active raid1 sda3[0] sdc3[1]
      1462886848 blocks [2/2] [UU]
     
md1 : active (auto-read-only) raid1 sdc2[1] sda2[0]
      1998848 blocks super 1.2 [2/2] [UU]
     
md2 : active raid1 sdc1[1] sda1[0]
      248640 blocks super 1.2 [2/2] [UU]

crypttab:
#UUID=e7a2e597-8f57-4faf-b32d-f24b5720ffe5 same as /dev/md0p3
crypto-home UUID=e7a2e597-8f57-4faf-b32d-f24b5720ffe5 none luks

fstab:
/dev/md0p1                                         /               ext4    errors=remount-ro 0       1
/dev/md0p2                                         /var            ext4    defaults        0       2
/dev/md1                                             none            swap    sw              0       0
/dev/md2                                             /boot           ext4    defaults        0       2
/dev/mapper/crypto-home                   /home           auto    defaults        0       2
...

$ egrep "^CRYPTSETUP" /etc/cryptsetup-initramfs/conf-hook
CRYPTSETUP=y

$ uname -a
Linux my-server 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u2 (2019-05-13) x86_64 GNU/Linux

systemd has version: 232-25+deb9u11
cryptsetup has version: 2:1.7.3-4
initramfs-tools has version: 0.130
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Debian Stretch, no password prompt for luks-encrypted home partition during boot

David Wright-3
In reply to this post by Sergey Belyashov
On Tue 28 May 2019 at 14:13:42 (+0300), Sergey Belyashov wrote:
> As expected nothing is changed. I did not forget to run update-initramfs
> after change of fstab.
> Attached 3 photos: normal boot, recovery boot before pasword enter,
> recovery boot after password and Ctrl-D in recovery shell.

[I don't see any photos attached. (The entire email is only 4.3kB)]

But I have struggled to find out what program is expected to issue
the prompt and collect the passphrase under various circumstances
(eg unlocking at boot, or unlocking later).

> вт, 28 мая 2019 г., 9:38 deloptes <[hidden email]>:
> > Sergey Belyashov wrote:
> >
> > > Root partition is on mdraid but is not encrypted. Home is encrypted only.
> > > Modules are set to most already.
> >
> > I have this setup on my server, but I removed all crypted entries from fstab
> > because obviously I can not sit infront of the server to type the password
> > when booting. So I can not help in this case much. I put all of this in a
> > script that I execute after I ssh to the server.

Most of my machines are set up rather like this. I have a pseudo-user
called unlock whose /var/local/home/unlock/.bash_profile runs
  sudo udisksctl unlock --block-device /dev/disk/by-id/…
  mount /home
and then logs out.

However, this is unsuitable for this laptop, as explained below.

> > On the clients I have root encrypted. I had issues in the beginning after
> > transfering the system from dbootstrap to the disk. In that case the UUIDs
> > were not correct. I always did set the init=/bin/sh on the command line in
> > grub to get the shell and debugged. Sometimes it is useful to add
> > a "rootdelay" to wait for the root device to get available, but in your
> > setup it looks like it is not exactly what you would need.

I haven't had that problem, but that might be just because I don't
encrypt root, only /home.

> > When the system boots it would read whatever you have in your initrd. It
> > would load the drivers and perform the boot process. Then it will pass
> > control to init and run the rest from the root system. IMO mounting home
> > comes in this second stage, but I am not 100% sure. What do you see when
> > you enable debug or verbose - what does it say when booting.

On my servers (unlocking later), I get the prompt "Passphrase: ".
When I type the passphrase, there is no reflection at all. And this
would be a big problem for me, were I to do this on this laptop.

So on this laptop, I use /etc/crypttab and /etc/fstab to mount /home
at boot. The passphrase entry obviously gets called in a different
manner as the prompt is more detailed (presumably because one might be
unlocking several different partitions at the same time but in an
unknown order):
  Please enter passphrase for disk Linux-Home (swanhome) on /home!
where "swanhome" is the crypttab target and "Linux-Home" is the GPT
Partition name. When I type the passphrase, an asterisk is reflected
for each character.

I've tried to figure out what programs are actually requesting the
passphrase and whether they have any arguments/options/environment
variables that can affect them. Things like, what's the prompt,
where is it printed, and what's reflected (if anything) when the
passphrase characters are being typed.

With unlocking later, the processes I see running are:

root    1026   808   ?      sshd: unlock [priv]
unlock  1028     1   ?      /lib/systemd/systemd --user
unlock  1029  1028   ?      (sd-pam)
unlock  1035  1026   ?      sshd: unlock@pts/0
unlock  1036  1035   pts/0  -bash
root    1043  1036   pts/0  sudo udisksctl unlock --block-device /dev/disk/by-id/…
root    1044  1043   pts/0  udisksctl unlock --block-device /dev/disk/by-id/…

root    1047     1   ?      /usr/lib/udisks2/udisksd --no-debug
root    1051     1   ?      /usr/lib/policykit-1/polkitd --no-debug
root    1065     1   ?      /lib/systemd/systemd --user
root    1066  1065   ?      (sd-pam)
root    1069   538   tty1   -bash
root    1575  1069   tty1   ps -ef

Once the passphrase has been entered, the processes before the empty
line all disappear.

It might be helpful for the OP to ascertain the answers for working on
their problem.

> > Also you have the fs type in fstab set to auto for your home - what happens
> > if you set the exact fs type like ext4 or xfs?
> >
> > Do a change at a time and test after this.

My problem: because of the keyboard's phantom typing, reported¹ at
https://lists.debian.org/debian-user/2018/03/msg01030.html
I have to know when spurious characters are being typed, by seeing
the asterisks. Therefore I unlock at boot. But to prevent locking
myself out with a bad passphrase, I've added nofail to /home's
fstab entry. I can then unlock /home in the same way as I use with
my servers. All this works, apart from some odd messages that I
don't fully understand, and may report sometime.

¹ I need to rereport this, with new information, but that too is
for another time.

Cheers,
David.