boot delay in buster clients

[Teddy Hogeborn]

Jesse Norell <jesse at kci.net> writes:

>   I have finished migrating all our older clients to debian 10/buster
> and I find that there is a delay (several minutes) when booting that
> didn't exist prior to upgrading.  They do boot eventually.  Running
> mandos-client manually once booted returns a key very quickly.  Any
> ideas what might be going on?  Watching network traffic on the mandos
> server shows that some icmp6 traffic is present right away when the
> prompt shows requesting a password to boot (ie. I presume right when
> mandos' systemd password agent runs).

What would help is the output, or at least your description of output,
from mandos-client running with the --debug flag at boot.

If you’re using dracut, edit the
/lib/dracut/modules.d/90mandos/ask-password-mandos.service and add
"--debug" to the end of the ExecStart= line.  Rebuild the initramfs
image using "dpkg-reconfigure dracut".

If you’re using initramfs-tools,
edit the /etc/mandos/plugin-runner.conf file and uncomment the last line
with the --options-for=mandos on it.  Rebuild the intramfs image using
"update-initramfs -k all -u".

However, what I *suspect* is the case is that the clients are not
getting an IPv6 address using Router Advertisement from their local
router, but that the local Mandos Servers are announcing their ZeroConf
services as having a globally-reachable IPv6 address.  This, if this is
what is happening, would result in the clients first failing to connect
to the server (taking some time to time out the connection), and then
adding an explicit local route to that IPv6 address in order to reach it
on the local network.  This presumably succeeds, which is why booting
works.  This case is slightly unusual, and we only expected this to
happen when the Mandos client is the actual router providing RA to the
local network.

If you are using DHCP, it might help if you let the clients acquire an
IP address from DHCP using the ip=dhcp kernel command line option (see
/usr/share/doc/linux-doc-*/Documentation/filesystems/nfs/nfsroot.txt).

It might also be the case that some Mandos server is announcing a Mandos
ZeroConf service using an IP address which for some reason is not at all
reachable by clients.  This will, if the clients tend to try that server
first, induce a timeout of about one minute per server which does this.

/Teddy Hogeborn

-- 
The Mandos Project
https://www.recompile.se/mandos
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://mail.recompile.se/pipermail/mandos-dev/attachments/20191212/26822227/attachment.sig>