Re: Very slow boot and sluggish when SERVER changes 4.9 to 4.19

It sounds like a Devuan problem, not an LTSP one.

https://wiki.archlinux.org/index.php/Random_number_generation#/dev/urandom

You don't have the following bits of a normal boot; I'd assume that 
Devuan doesn't run the correct init script there:
[    7.022171] random: fast init done
[   12.916705] random: crng init done

This still doesn't explain why a server kernel change introduces this 
though.

Anyways, what I wanted to ask the list is if many LTSP users are using 
non-systemd based distributions,
and if any of them are interested in contributing code for the init 
systems that they're using,
as currently I was planning that the next LTSP will only have 
systemd-specific code for init scripts, screen sessions etc...




On 4/23/19 9:51 AM, Maxime Accadia wrote:
> Hi,
> 
> Maybe you can try systemd-bootchart to identify what is taking time in your boot process.
> 
> For random number generation, you can try rng-tools package to see if there is any difference.
> 
> Maxime
> 
> ----- Mail original -----
> De: "Nick Rickard" <[email protected]>
> À: "ltsp-discuss" <[email protected]>
> Envoyé: Dimanche 21 Avril 2019 16:58:01
> Objet: [Ltsp-discuss] Very slow boot and sluggish when SERVER changes 4.9 to 4.19
> 
> 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