On Tue, Dec 18, 2018 at 09:35:59PM +0100, Alexander Tampermeier via
blfs-support wrote:
Hi!
I just built a new LFS 8.3 system and everything seemed to work well at a
first glance. But when trying to install DHCP-4.4.1 according to BLFS 8.3
stable
(/http://www.linuxfromscratch.org/blfs/view/stable/basicnet/dhcp.html/) the
build aborts due to errors (please see the output below).
First warnings appear during the build of the bind libraries ("/In file
included from entropy.c:61: ../entropy.c: In function 'entropypool_adddata':
../entropy.c:327:7: warning: this statement may fall through
[-Wimplicit-fallthrough=] len--;/" and finally the build breaks.
Warnings are very common with recent gcc versions, and almsot never
related to the error(s). In general, all that matters is the first
error.
But as Bruce said, check the current instructions - our releases are
only a snapshot of what we believed worked at that time.
I also recognized that during startup of the machine I get multiple errors
like:
/[ 5.580768] random: udevd: uninitialized urandom read (16 bytes read)/
/[ 7.752273] random: sshd: uninitialized urandom read (32 bytes read)
/and finally:/
[ 44.233105] random: crng init done
Again, these are warnings.
/
Might it be, that the broken DHCP build is due to some failure of the random
generator as the first warning seems be related to entropy? But I am not not
sure, if the random generator is broken at all. How could I figure out the
core of the build issue?
No, random initialization in the kernel has changed this year,
because of vulnerabilities (specifically, generating insufficiently
random keys in some situations). Unfortunately, this is now a pain
for some machines and VMs.
You possibly have a delay while one or more of the bootscripts are
looking for, and then using, entropoy - if the machine appears to
hang while one or more of the bootscripts is running, try thumping
the keyboard.
The problem appears more common with SSDs for some reason. A patch
was added to the 4.19 (current long-term stable) kernel, adding
CONFIG_RANDOM_TRUST_CPU and enabling that should reduce the problem.
Most recent machines have hardware rngs (but not my AMD Kaveri and
probably not some other low-end CPUs). Alternatively, build haveged
and its bootscript (I assume your are on sysv because I think that
systemd includes its own dhcp client).
My system is running on VMware and I build several other LFS/BLFS systems
before and there never was an issue with random or DHCP.
Didn't see that until I was trimming the rest : for a VM, use
haveged to provide entropy of uncertain quality and ensure a boot in
a reasonable time.
By the way: The BLFS book suggests for DHCP to use the "/missing_ipv6/"
patch if the kernel has no IPv6 support. As I could not find this patch in
/http://www.linuxfromscratch.org/patches/blfs/8.3//, I had to compile IPv6
into the kernel. Is there no such patch anymore available for BLFS 8.3?
The patch is not needed with 4.4. No doubt the lingering reference
to it was missed. Happens all the time. Hmm, I see it is still
referred to. I don't think it is needed, but I haven't tested
dhclient in ages.
-O2 -Wall -Werror -fno-strict-aliasing -I../includes
-I/j/development/dhcp-4.4.1/bind/include -MT discover.o -MD -MP -MF
.deps/discover.Tpo -c -o discover.o discover.c//
//discover.c: In function 'discover_interfaces'://
//discover.c:646:4: error: 'strncpy' output may be truncated copying 15
bytes from a string of length 15 [-Werror=stringop-truncation]//
// strncpy(tmp->name, info.name, sizeof(tmp->name) - 1);//
// ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~//
//cc1: all warnings being treated as errors//
Ah, didn't read the voluminous messages. Need to remove -Werror
from CFLAGS.
Thread at
https://www.mail-archive.com/[email protected]/msg07569.html
which I guess was after 8.3 was released.
ĸen
