Bug#964187: cryptsetup: takes one minute to unlock the disk with a passphrase

[Vincent Lefevre]

On 2020-07-06 02:34:56 +0200, Guilhem Moulin wrote:
> On Mon, 06 Jul 2020 at 01:48:45 +0200, Vincent Lefevre wrote:
> > If you let the user run a script that controls the timeout, that
> > would be better. For instance, a typical setting when dropbear is
> > used to unlock the disk(s) would be to set the timeout so that the
> > following conditions are *both* satisfied:
> > 
> > 1. Some lower bound has been reached (say 10 seconds).
> > 
> > 2. The passphrase has been validated.
> > 
> > This makes sense because in this case, it is useless to abort
> > wait_for_dropbear() while the passphrase has not been validated
> > yet.
> 
> wait_for_dropbear() runs at init-bottom stage, so after dm-crypt devices
> have been mapped (if cryptsetup-initramfs is installed and the crypttab
> is not empty, that is).  So you're essentially asking to set the timeout
> to 10s.

OK, so that's even simpler. A configurable timeout would be
sufficient.

> > BTW, I've just noticed that the timeout introduces a second annoying
> > regression: If there is a temporary issue with the DHCP server just
> > after the machine has been restarted, so that the timeout is reached,
> > the user will not be able to unlock the disk until he can go back in
> > front of his machine!
> 
> You mean the timeout from configure_networking() it init-premout stage?
[...]

Please forget that. I meant wait_for_dropbear(), but since it runs
after dm-crypt devices have been mapped, there is no issue.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#964187: cryptsetup: takes one minute to unlock the disk with a passphrase

[Guilhem Moulin]

On Mon, 06 Jul 2020 at 01:48:45 +0200, Vincent Lefevre wrote:
> On 2020-07-06 01:06:58 +0200, Guilhem Moulin wrote:
>> On Mon, 06 Jul 2020 at 00:54:42 +0200, Vincent Lefevre wrote:
>>> On 2020-07-05 16:34:05 +0200, Guilhem Moulin wrote:
 The raison d'être of wait_for_dropbear() is to avoid handing the
 execution over to init(1) with a running ipconfig process or unclean
 network stack.  This is what the race condition described in #943459 is
 about.  wait_for_dropbear() somewhat of a hack, but ipconfig doesn't
 seem to react to SIGTERM and I couldn't do better at the time.
>>> 
>>> How about SIGKILL, then?
>> 
>> No.
> 
> Why no?

Not gonna send SIGKILL processes not under my control.  Bad practice.
It might leave all sort crap behind, I need a documented abort
mechanism.
 
>>> The user has more knowledge than initramfs. For instance, he knows
>>> whether the link is present. And he generally knows the typical
>>> time he has to wait for the DHCP server (unless a major problem
>>> occurs with the server, in which case he may have to wait any time).
>>> So it's better to leave the control to the user.
>> 
>> I could certainly make the timeout configurable, but that's be an option
>> hardcoded in the initramfs (or the kernel command line) so probably not
>> ideal to manually flip occasionally when the users knows there is no
>> link present.
> 
> If you let the user run a script that controls the timeout, that
> would be better. For instance, a typical setting when dropbear is
> used to unlock the disk(s) would be to set the timeout so that the
> following conditions are *both* satisfied:
> 
> 1. Some lower bound has been reached (say 10 seconds).
> 
> 2. The passphrase has been validated.
> 
> This makes sense because in this case, it is useless to abort
> wait_for_dropbear() while the passphrase has not been validated
> yet.

wait_for_dropbear() runs at init-bottom stage, so after dm-crypt devices
have been mapped (if cryptsetup-initramfs is installed and the crypttab
is not empty, that is).  So you're essentially asking to set the timeout
to 10s.

> BTW, I've just noticed that the timeout introduces a second annoying
> regression: If there is a temporary issue with the DHCP server just
> after the machine has been restarted, so that the timeout is reached,
> the user will not be able to unlock the disk until he can go back in
> front of his machine!

You mean the timeout from configure_networking() it init-premout stage?
That's not a regression from 2020.79-1, didn't touch the premount script
for many years.  Yes configure_networking() might fail and leave the
system without network, however dropbear-initramfs is not the place to
fix this.  configure_networking() comes from initramfs-tools, and AFAICT
the same problem arises for NFS mounts.

> My proposal would solve this issue.

Then I probably didn't understand the issue you're describing.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#964187: cryptsetup: takes one minute to unlock the disk with a passphrase

[Vincent Lefevre]

On 2020-07-06 01:06:58 +0200, Guilhem Moulin wrote:
> On Mon, 06 Jul 2020 at 00:54:42 +0200, Vincent Lefevre wrote:
> > On 2020-07-05 16:34:05 +0200, Guilhem Moulin wrote:
> >> The raison d'être of wait_for_dropbear() is to avoid handing the
> >> execution over to init(1) with a running ipconfig process or unclean
> >> network stack.  This is what the race condition described in #943459 is
> >> about.  wait_for_dropbear() somewhat of a hack, but ipconfig doesn't
> >> seem to react to SIGTERM and I couldn't do better at the time.
> > 
> > How about SIGKILL, then?
> 
> No.

Why no?

> > The user has more knowledge than initramfs. For instance, he knows
> > whether the link is present. And he generally knows the typical
> > time he has to wait for the DHCP server (unless a major problem
> > occurs with the server, in which case he may have to wait any time).
> > So it's better to leave the control to the user.
> 
> I could certainly make the timeout configurable, but that's be an option
> hardcoded in the initramfs (or the kernel command line) so probably not
> ideal to manually flip occasionally when the users knows there is no
> link present.

If you let the user run a script that controls the timeout, that
would be better. For instance, a typical setting when dropbear is
used to unlock the disk(s) would be to set the timeout so that the
following conditions are *both* satisfied:

1. Some lower bound has been reached (say 10 seconds).

2. The passphrase has been validated.

This makes sense because in this case, it is useless to abort
wait_for_dropbear() while the passphrase has not been validated
yet.

Then there are 2 cases:

1. The user is in front of his machine. He also knows whether he
should get an answer from the DHCP server. Then, depending on the
context and the messages from the DHCP client that appear on the
screen, he can validate his passphrase ASAP (e.g. because there is
no link, so that there cannot be an answer from a DHCP server) or
wait for the DHCP server to answer (the user may be the admin of
the DHCP server, e.g. for a machine at home, so that he will know
what to do).

2. The user is not in front of his machine, which may be far away.
The only solution is to unlock the disk(s) via SSH. Since the user
cannot type the passphrase, there will never be a timeout (due to
condition 2), which is exactly what the user wants.

Note that with these rules, condition 1 is even normally useless.
It may only be useful to avoid a mistake from the user, or if the
user has confidence that it will always work in practice (if the
chosen value is large enough), so that the user would validate
his passphrase ASAP.

BTW, I've just noticed that the timeout introduces a second annoying
regression: If there is a temporary issue with the DHCP server just
after the machine has been restarted, so that the timeout is reached,
the user will not be able to unlock the disk until he can go back in
front of his machine! My proposal would solve this issue.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#964187: cryptsetup: takes one minute to unlock the disk with a passphrase

[Guilhem Moulin]

On Mon, 06 Jul 2020 at 00:54:42 +0200, Vincent Lefevre wrote:
> On 2020-07-05 16:34:05 +0200, Guilhem Moulin wrote:
>> The raison d'être of wait_for_dropbear() is to avoid handing the
>> execution over to init(1) with a running ipconfig process or unclean
>> network stack.  This is what the race condition described in #943459 is
>> about.  wait_for_dropbear() somewhat of a hack, but ipconfig doesn't
>> seem to react to SIGTERM and I couldn't do better at the time.
> 
> How about SIGKILL, then?

No.
 
>> Consider a slow DHCP setup where ipconfig gets a lease after 45s or so.
> 
> With a temporary DHCP server failure, it can be more than the current
> timeout of 60 seconds.

Of course.  Like most thresholds this is at attempt at finding a
reasonable default, not something that covers all cases…
 
>> While it's running you unlock drives so the boot process can proceed.
>> If the execution is handed over to init(1) right away, without waiting
>> for ipconfig to settle or give up (nor for dropbear to start), then
>> ipconfig and dropbear will race with the network stack resp. SSHd of the
>> main system.  This might yield a static IP being overwritten by DHCP,
>> like in #943459, and/or OpenSSH failing to start because dropbear
>> listens on 22/tcp already.
> 
> The user has more knowledge than initramfs. For instance, he knows
> whether the link is present. And he generally knows the typical
> time he has to wait for the DHCP server (unless a major problem
> occurs with the server, in which case he may have to wait any time).
> So it's better to leave the control to the user.

I could certainly make the timeout configurable, but that's be an option
hardcoded in the initramfs (or the kernel command line) so probably not
ideal to manually flip occasionally when the users knows there is no
link present.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#964187: cryptsetup: takes one minute to unlock the disk with a passphrase

[Vincent Lefevre]

On 2020-07-05 16:34:05 +0200, Guilhem Moulin wrote:
> On Sun, 05 Jul 2020 at 12:08:41 +0200, Vincent Lefevre wrote:
> > On 2020-07-04 01:07:15 +0200, Guilhem Moulin wrote:
> >> That would introduce back the race condition described in #943459.
> > 
> > I don't think so, as this would be equivalent to the current code when
> > it reaches the 60-second timeout, except that the wait_for_dropbear()
> > function will return earlier (with return value 1).
> 
> The raison d'être of wait_for_dropbear() is to avoid handing the
> execution over to init(1) with a running ipconfig process or unclean
> network stack.  This is what the race condition described in #943459 is
> about.  wait_for_dropbear() somewhat of a hack, but ipconfig doesn't
> seem to react to SIGTERM and I couldn't do better at the time.

How about SIGKILL, then?

> If wait_for_dropbear() were to have an abort mechanism that didn't wait
> for ipconfig to settle or give up, then we would reintroduce the race
> condition.
> 
> > Thus this would be no worse than the current code.
> 
> Consider a slow DHCP setup where ipconfig gets a lease after 45s or so.

With a temporary DHCP server failure, it can be more than the current
timeout of 60 seconds.

> While it's running you unlock drives so the boot process can proceed.
> If the execution is handed over to init(1) right away, without waiting
> for ipconfig to settle or give up (nor for dropbear to start), then
> ipconfig and dropbear will race with the network stack resp. SSHd of the
> main system.  This might yield a static IP being overwritten by DHCP,
> like in #943459, and/or OpenSSH failing to start because dropbear
> listens on 22/tcp already.

The user has more knowledge than initramfs. For instance, he knows
whether the link is present. And he generally knows the typical
time he has to wait for the DHCP server (unless a major problem
occurs with the server, in which case he may have to wait any time).
So it's better to leave the control to the user.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#964187: cryptsetup: takes one minute to unlock the disk with a passphrase

[Guilhem Moulin]

On Sun, 05 Jul 2020 at 12:08:41 +0200, Vincent Lefevre wrote:
> On 2020-07-04 01:07:15 +0200, Guilhem Moulin wrote:
>> That would introduce back the race condition described in #943459.
> 
> I don't think so, as this would be equivalent to the current code when
> it reaches the 60-second timeout, except that the wait_for_dropbear()
> function will return earlier (with return value 1).

The raison d'être of wait_for_dropbear() is to avoid handing the
execution over to init(1) with a running ipconfig process or unclean
network stack.  This is what the race condition described in #943459 is
about.  wait_for_dropbear() somewhat of a hack, but ipconfig doesn't
seem to react to SIGTERM and I couldn't do better at the time.

If wait_for_dropbear() were to have an abort mechanism that didn't wait
for ipconfig to settle or give up, then we would reintroduce the race
condition.

> Thus this would be no worse than the current code.

Consider a slow DHCP setup where ipconfig gets a lease after 45s or so.
While it's running you unlock drives so the boot process can proceed.
If the execution is handed over to init(1) right away, without waiting
for ipconfig to settle or give up (nor for dropbear to start), then
ipconfig and dropbear will race with the network stack resp. SSHd of the
main system.  This might yield a static IP being overwritten by DHCP,
like in #943459, and/or OpenSSH failing to start because dropbear
listens on 22/tcp already.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#964187: cryptsetup: takes one minute to unlock the disk with a passphrase

[Vincent Lefevre]

On 2020-07-04 01:07:15 +0200, Guilhem Moulin wrote:
> On Sat, 04 Jul 2020 at 00:54:53 +0200, Vincent Lefevre wrote:
> > I suppose that's
> > 
> > wait_for_dropbear() {
> > […]
> > }
> > 
> > Couldn't it also check whether the user has typed the passphrase,
> > and quit in this case?
> 
> That would introduce back the race condition described in #943459.

I don't think so, as this would be equivalent to the current code when
it reaches the 60-second timeout, except that the wait_for_dropbear()
function will return earlier (with return value 1). Thus this would be
no worse than the current code.

> configure_networking() runs in the background and might still be running
> at init-bottom stage, after the user has unlocked all drives from the
> console.  Also dropbear-initramfs isn't only used for remote unlocking
> and I don't want to tie the two with adhoc hacks.

It could be a generic abort condition for all init-bottom cases.
For instance, if a file /run/initramfs/init-bottom-terminate is
created, then all the init-bottom scripts should terminate ASAP.
Alternatively, wait_for_dropbear() could run a user-provided
script (if it exists) as an additional "while" condition.

And for that, cryptsetup-initramfs should have a way to signal
that the disks have been unlocked.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#964187: cryptsetup: takes one minute to unlock the disk with a passphrase

[Guilhem Moulin]

On Sat, 04 Jul 2020 at 00:54:53 +0200, Vincent Lefevre wrote:
> I suppose that's
> 
> wait_for_dropbear() {
> […]
> }
> 
> Couldn't it also check whether the user has typed the passphrase,
> and quit in this case?

That would introduce back the race condition described in #943459.
configure_networking() runs in the background and might still be running
at init-bottom stage, after the user has unlocked all drives from the
console.  Also dropbear-initramfs isn't only used for remote unlocking
and I don't want to tie the two with adhoc hacks.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#964187: cryptsetup: takes one minute to unlock the disk with a passphrase

[Vincent Lefevre]

On 2020-07-04 00:30:04 +0200, Guilhem Moulin wrote:
> On Sat, 04 Jul 2020 at 00:18:59 +0200, Vincent Lefevre wrote:
> > Note that /usr/share/doc/dropbear-initramfs/README.initramfs
> > says at the end:
> > 
> >  This is non-blocking for the startup process, so when you are at the
> >  console you won't have to wait for the SSHd to complete its startup.
> 
> I happen to maintain dropbear-initramfs and wrote that :-)
> 
> While the init-premount script is non-blocking, the init-bottom is
> blocking.  This is a side effect of the #943459, but I'm not sure it's
> possible to have it both ways.  Need to do some tests to see where the
> link is detected.

I suppose that's

wait_for_dropbear() {
local pid exe timer=60
pid="$(cat "$PIDFILE" 2>/dev/null)" || return 1

# when configure_networking() is run asynchronously dropbear might
# not have started yet; ipconfig doesn't react to SIGTERM so we wait
# for the network stack to be configured (and dropbear to start)
# rather than terminating the shell and its children
while [ $timer -gt 0 ] && exe="$(readlink -f "/proc/$pid/exe" 
2>/dev/null)"; do
if [ "$exe" = "$EXE" ]; then
echo "$pid"
return 0
fi
sleep 1
timer=$(( timer - 1))
done
return 1
}

Couldn't it also check whether the user has typed the passphrase,
and quit in this case? (I assume that the information is available
somewhere or can be made available.)

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#964187: cryptsetup: takes one minute to unlock the disk with a passphrase

[Guilhem Moulin]

Control: reassign -1 dropbear-initramfs 2020.79-1
Control: retitle -1 dropbear-initramfs: init-bottom blocks for 1 minute when 
there is no link
Control: severity -1 normal

On Sat, 04 Jul 2020 at 00:18:59 +0200, Vincent Lefevre wrote:
> Note that /usr/share/doc/dropbear-initramfs/README.initramfs
> says at the end:
> 
>  This is non-blocking for the startup process, so when you are at the
>  console you won't have to wait for the SSHd to complete its startup.

I happen to maintain dropbear-initramfs and wrote that :-)

While the init-premount script is non-blocking, the init-bottom is
blocking.  This is a side effect of the #943459, but I'm not sure it's
possible to have it both ways.  Need to do some tests to see where the
link is detected.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#964187: cryptsetup: takes one minute to unlock the disk with a passphrase

[Vincent Lefevre]

On 2020-07-03 16:12:49 +0200, Guilhem Moulin wrote:
> On Fri, 03 Jul 2020 at 12:53:17 +0200, Vincent Lefevre wrote:
> > I don't know really where the problem comes from, but it now takes
> > one minute to unlock the disk of my laptop with a passphrase. Well,
> > I'm not sure whether this comes from cryptsetup or something that
> > comes just after it, but at least the fact that cryptsetup doesn't
> > output any confirmation message doesn't help.
> 
> See https://wiki.debian.org/InitramfsDebug#Saving_debug_information to
> get debug output.  For further detailed debug output you can append `-x`
> to the shebang line of the boot script causing the delay.  See e.g.,
> https://cryptsetup-team.pages.debian.net/cryptsetup/README.debug.html .

I've attached the initramfs.debug file. But I don't know what
is blocking. The unlocking should have been completed before
the following lines appear (since at this time I had entered
the passphrase on the console).

IP-Config: eth0 hardware address 30:8d:99:25:ad:3f mtu 1500 DHCP RARP
IP-Config: no response after 6 secs - giving up
IP-Config: eth0 hardware address 30:8d:99:25:ad:3f mtu 1500 DHCP RARP
IP-Config: no response after 9 secs - giving up
IP-Config: eth0 hardware address 30:8d:99:25:ad:3f mtu 1500 DHCP RARP
IP-Config: no response after 16 secs - giving up
IP-Config: eth0 hardware address 30:8d:99:25:ad:3f mtu 1500 DHCP RARP
IP-Config: no response after 25 secs - giving up

Note that /usr/share/doc/dropbear-initramfs/README.initramfs
says at the end:

  This is non-blocking for the startup process, so when you are at the
  console you won't have to wait for the SSHd to complete its startup.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
+ unset log_output
+ maybe_break top
+ run_scripts /scripts/init-top
+ initdir=/scripts/init-top
+ '[' '!' -d /scripts/init-top ]
+ shift
+ . /scripts/init-top/ORDER
+ /scripts/init-top/all_generic_ide
+ '[' -e /conf/param.conf ]
+ /scripts/init-top/blacklist
+ '[' -e /conf/param.conf ]
+ /scripts/init-top/keymap
+ '[' -e /conf/param.conf ]
+ /scripts/init-top/udev
+ '[' -e /conf/param.conf ]
+ maybe_break modules
+ '[' n '!=' y ]
+ log_begin_msg 'Loading essential drivers'
+ _log_msg 'Begin: %s ... ' 'Loading essential drivers'
+ '[' n '=' y ]
+ printf 'Begin: %s ... ' 'Loading essential drivers'
Begin: Loading essential drivers ... + '[' -n  ]
+ load_modules
+ '[' -e /conf/modules ]
+ read -r m
+ '[' -z e1000e ]
+ printf '%.1s' e1000e
+ com=e
+ '[' e '=' '#' ]
+ modprobe e1000e
+ read -r m
+ '[' n '!=' y ]
+ log_end_msg
+ _log_msg 'done.\n'
+ '[' n '=' y ]
+ printf 'done.\n'
done.
+ '['  ]
+ maybe_break premount
+ '[' n '!=' y ]
+ log_begin_msg 'Running /scripts/init-premount'
+ _log_msg 'Begin: %s ... ' 'Running /scripts/init-premount'
+ '[' n '=' y ]
+ printf 'Begin: %s ... ' 'Running /scripts/init-premount'
Begin: Running /scripts/init-premount ... + run_scripts /scripts/init-premount
+ initdir=/scripts/init-premount
+ '[' '!' -d /scripts/init-premount ]
+ shift
+ . /scripts/init-premount/ORDER
+ /scripts/init-premount/dropbear
+ '[' -e /conf/param.conf ]
+ '[' n '!=' y ]
+ log_end_msg
+ _log_msg 'done.\n'
+ '[' n '=' y ]
+ printf 'done.\n'
done.
+ maybe_break mount
+ log_begin_msg 'Mounting root file system'
+ _log_msg 'Begin: %s ... ' 'Mounting root file system'
+ '[' n '=' y ]
+ printf 'Begin: %s ... ' 'Mounting root file system'
Begin: Mounting root file system ... + . /scripts/local
+ . /scripts/nfs
+ . /scripts/local
+ parse_numeric /dev/mapper/zira--vg-root
+ return
+ maybe_break mountroot
+ mount_top
+ local_top
+ '['  '!=' yes ]
+ '[' n '!=' y ]
+ log_begin_msg 'Running /scripts/local-top'
+ _log_msg 'Begin: %s ... ' 'Running /scripts/local-top'
+ '[' n '=' y ]
+ printf 'Begin: %s ... ' 'Running /scripts/local-top'
Begin: Running /scripts/local-top ... + run_scripts /scripts/local-top
+ initdir=/scripts/local-top
+ '[' '!' -d /scripts/local-top ]
+ shift
+ . /scripts/local-top/ORDER
+ /scripts/local-top/cryptopensc
+ '[' -e /conf/param.conf ]
+ /scripts/local-top/lvm2
  Volume group "zira-vg" not found
  Cannot process volume group zira-vg
  Volume group "zira-vg" not found
  Cannot process volume group zira-vg
+ '[' -e /conf/param.conf ]
+ /scripts/local-top/cryptroot
Please unlock disk sda5_crypt: IP-Config: eth0 hardware address 
30:8d:99:25:ad:3f mtu 1500 DHCP RARP
IP-Config: no response after 2 secs - giving up
IP-Config: eth0 hardware address 30:8d:99:25:ad:3f mtu 1500 DHCP RARP
IP-Config: no response after 3 secs - giving up
IP-Config: eth0 hardware address 30:8d:99:25:ad:3f mtu 1500 DHCP RARP
IP-Config: no response after 4 secs - giving up

cryptsetup: sda5_crypt: set up successfully
+ '[' -e /conf/param.conf ]
+ '[' n '!=' y ]
+ log_end_msg
+ _log_msg 'done.\n'
+ '[' n '=' y ]
+ printf 'done.\n'
done.
+ local_top_used=yes
+ '[' -z  ]
+ cat /proc/uptime
+ 

Bug#964187: cryptsetup: takes one minute to unlock the disk with a passphrase

[Guilhem Moulin]

Control: reassign -1 cryptsetup-initramfs 2:2.3.3-1
Control: tag -1 + moreinfo

On Fri, 03 Jul 2020 at 12:53:17 +0200, Vincent Lefevre wrote:
> I don't know really where the problem comes from, but it now takes
> one minute to unlock the disk of my laptop with a passphrase. Well,
> I'm not sure whether this comes from cryptsetup or something that
> comes just after it, but at least the fact that cryptsetup doesn't
> output any confirmation message doesn't help.

See https://wiki.debian.org/InitramfsDebug#Saving_debug_information to
get debug output.  For further detailed debug output you can append `-x`
to the shebang line of the boot script causing the delay.  See e.g.,
https://cryptsetup-team.pages.debian.net/cryptsetup/README.debug.html .

> Until June 30, this was always immediate, and nothing changed
> on my system.

2:2.3.3-1 landed into sid resp. testing on June 04 resp. June 09.

> My laptop no longer has an Ethernet cable plugged in, so that this
> might make the difference. […] Note that I've always had
>
> e1000e
>
> in /etc/initramfs-tools/modules.

This is irrelevant as far as the cryptsetup-initramfs boot scripts are
concerned.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#964187: cryptsetup: takes one minute to unlock the disk with a passphrase

[Vincent Lefevre]

Package: cryptsetup
Version: 2:2.3.3-1
Severity: important

I don't know really where the problem comes from, but it now takes
one minute to unlock the disk of my laptop with a passphrase. Well,
I'm not sure whether this comes from cryptsetup or something that
comes just after it, but at least the fact that cryptsetup doesn't
output any confirmation message doesn't help.

Until June 30, this was always immediate, and nothing changed
on my system. My laptop no longer has an Ethernet cable plugged
in, so that this might make the difference (but this was working
fine several months ago). Note that I've always had

e1000e

in /etc/initramfs-tools/modules.

-- Package-specific info:
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-5.7.0-1-amd64 root=/dev/mapper/zira--vg-root ro quiet

-- /etc/crypttab
sda5_crypt UUID=ef627f6a-4469-42c8-9b15-f26477969e7b none luks

-- /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
#
/dev/mapper/zira--vg-root /   ext4errors=remount-ro 0   1
# /boot was on /dev/sda1 during installation
UUID=7b3de7fd-236a-47f6-bb85-64831a06ca1f /boot   ext2defaults  
  0   2
/dev/mapper/zira--vg-swap_1 noneswapsw  0   0
/dev/sr0/media/cdrom0   udf,iso9660 user,noauto 0   0
/dev/sdb/media/mem  auto user,noauto,noatime0   0
/dev/sdb1   /media/mem  auto user,noauto,noatime0   0

-- lsmod
Module  Size  Used by
ctr16384  2
ccm20480  6
rfcomm 90112  4
ipt_REJECT 16384  3679
nf_reject_ipv4 16384  1 ipt_REJECT
xt_multiport   20480  2
nft_compat 20480  3681
nft_counter16384  3683
nf_tables 229376  11047 nft_compat,nft_counter
nfnetlink  16384  2 nft_compat,nf_tables
psnap  16384  0
cpufreq_conservative16384  0
llc16384  1 psnap
cmac   16384  1
cpufreq_userspace  20480  0
cpufreq_powersave  20480  0
bnep   28672  2
intel_rapl_msr 20480  0
intel_rapl_common  32768  1 intel_rapl_msr
iwlmvm319488  0
btusb  57344  0
btrtl  24576  1 btusb
btbcm  20480  1 btusb
mac80211  905216  1 iwlmvm
btintel32768  1 btusb
mei_wdt16384  0
binfmt_misc24576  1
libarc416384  1 mac80211
snd_hda_codec_realtek   131072  1
bluetooth 688128  31 btrtl,btintel,btbcm,bnep,btusb,rfcomm
snd_hda_codec_hdmi 73728  1
snd_hda_codec_generic94208  1 snd_hda_codec_realtek
x86_pkg_temp_thermal20480  0
intel_powerclamp   20480  0
ledtrig_audio  16384  2 snd_hda_codec_generic,snd_hda_codec_realtek
iwlwifi   274432  1 iwlmvm
coretemp   20480  0
uvcvideo  114688  0
snd_hda_intel  57344  5
snd_intel_dspcfg   24576  1 snd_hda_intel
snd_hda_codec 163840  4 
snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec_realtek
videobuf2_vmalloc  20480  1 uvcvideo
videobuf2_memops   20480  1 videobuf2_vmalloc
snd_hda_core  106496  5 
snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek
intel_cstate   16384  0
drbg   28672  1
videobuf2_v4l2 28672  1 uvcvideo
cfg80211  872448  3 iwlmvm,iwlwifi,mac80211
snd_hwdep  16384  1 snd_hda_codec
ansi_cprng 16384  0
intel_uncore  163840  0
videobuf2_common   57344  2 videobuf2_v4l2,uvcvideo
hp_wmi 16384  0
intel_rapl_perf16384  0
snd_pcm   131072  4 
snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_core
videodev  266240  3 videobuf2_v4l2,uvcvideo,videobuf2_common
joydev 28672  0
snd_timer  45056  1 snd_pcm
iTCO_wdt   16384  0
mei_me 45056  1
serio_raw  20480  0
iTCO_vendor_support16384  1 iTCO_wdt
snd   106496  18 
snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek,snd_timer,snd_pcm
sparse_keymap  16384  1 hp_wmi
tpm_infineon   20480  0
ecdh_generic   16384  2 bluetooth
ecc36864  1 ecdh_generic
mxm_wmi16384  0
pcspkr 16384  0
wmi_bmof   16384  0
sg 36864  0
mc 57344  4 
videodev,videobuf2_v4l2,uvcvideo,videobuf2_common
watchdog   28672  2 iTCO_wdt,mei_wdt
rfkill 28672  6 hp_wmi,bluetooth,cfg80211
mei   122880  3 mei_wdt,mei_me