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

@Maxime - thanks. I didn't make clear that Devuan is not a systemd OS 
and therefore that systemd-bootchart programme is not available to me. 
Thanks for the pointer on rng-tools, I will experiment with that in both 
chroot and server and see if it helps.

@Alkis - Yes, the fact that it was the server kernel not the chroot 
kernel (and chroot on 4.19 works fine if server is on 4.9) makes for a 
lot of head-scratching. And the fact that it makes the subsequent 
session all run sluggish suggests wider forces are at work(!); it's not 
just the initial random number entropy generation.

I suspect it's a fairly small group of those running Devuan *and* LTSP 
and given that my skills don't extend to contributing init code then I 
accept I might not be supported forever. That said, if you could fork or 
freeze at the appropriate point and maintain that (old) version in the 
repository then it does at least give a working baseline for non-systemd 
folk.

Nick.



On 23/04/2019 07:03, Alkis Georgopoulos wrote:
> 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


_____________________________________________________________________
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