Very slow boot and sluggish when SERVER changes 4.9 to 4.19
Nick Rickard <ltsp-6wBexXPKtwSGHxnzd0C9Llpr/1R2p/[email protected]> Sun, 21 Apr 2019 14:58:01 +0000
| Newsgroups | gmane.linux.terminal-server.general |
|---|---|
| Organization | NickRickard |
| Message-ID | <[email protected]> |
I'm running a Devuan LTSP server and chroot. Chroot is Devuan Beowulf
(Debian Buster) fully up to date and works fine with kernel v4.19. I've
recently updated the server from Ascii (Stretch) to Beowulf. I updated
all the elements *except* the kernel on the server (with reboots
inbetween) and LTSP clients were fine. When I update the server kernel
from 4.9 to 4.19 I get a very slow client boot and sluggish clients. The
only difference is the server kernel as I can rollback / forward and see
the difference.
(Hopefully) relevant extract from dmesg on the client:
[ 6.277875] FS-Cache: Netfs 'nfs' registered for caching
[ 6.977754] random: fast init done
[ 13.343880] urandom_read: 1 callbacks suppressed
[ 13.343882] random: mktemp: uninitialized urandom read (10 bytes read)
[ 73.909618] udevd[561]: starting version 3.2.7
[ 74.052792] random: udevd: uninitialized urandom read (16 bytes read)
[ 74.058644] random: udevd: uninitialized urandom read (16 bytes read)
[ 74.058668] random: udevd: uninitialized urandom read (16 bytes read)
[ 74.079290] udevd[561]: specified group 'kvm' unknown
[ 74.241951] udevd[561]: starting eudev-3.2.7
Whereas the previous one would take about 8secs and then all progress fine.
I guess my first question/confusion is why a change of the *server*
kernel has an impact when I'm running a chroot that has not changed it's
kernel?
And turning to the problem itself. It looks likes random generation is
taking a long time - which I think occurred somewhere about kernel 4.14
from a quick look on searching for non-LTSP but similar-ish embedded errors.
Is there a way I can fake / preload the random generation? Given it's
for a home setup then I would probably be happy to trade local security
on the internal network of my LTSP clients unless someone tells me why
that's a bad idea.
And I'm not sure why this then persists into a sluggish LTSP client
session. Possibly a second issue?
Thanks,
Nick.
_____________________________________________________________________
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp channel on irc.freenode.net