Opened 18 years ago
Closed 18 years ago
#81 closed defect (fixed)
Failures in Perl test suite
Reported by: | gomoko | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | CLFS Standard 1.0.0 |
Component: | BOOK | Version: | CLFS Standard 1.0.0 |
Keywords: | Perl check failure IPRoute2 network | Cc: |
Description
Problem: In CLFS x86_64 multilib, there's some tests failure in the Perl test suite (chapter 10.22).
Solution: As suggested by the command:
echo "127.0.0.1 localhost $(hostname)" > /etc/hosts
in the book, Perl test suite needs local network for some tests. But in CLFS, after a reboot, the script /etc/rc.d/init.d/localnet is not started, because IPRoute2 isn't yet installed.
To have a perfect Perl test suite, the following operations must be done:
- install IPRoute2 in /tools (in fact, only the 'ip' program is needed in /tools/bin)
or move the installation of IPRoute2 before Perl's one (no more dependances required)
- launch the commands to start the local network (as in localnet bootscript):
hostname <clfs> ip link set lo up
before the echo in /etc/hosts.
After that, all tests were successfully passed.
Change History (8)
comment:2 by , 18 years ago
About moving iproute: iproute requires bison and flex. Bison isn't a problem since it is already installed early in the final-system, but flex would need to be moved up - should just be able to put it right after bison.
comment:3 by , 18 years ago
Thanks for that feedback, Chris. The problem apparently only happens in 'if you boot' (I haven't, yet, seen it myself) so it's probably best to just add 'ip' to chapter 7 (looking at my buildscript where I add iproute2 as an extra after chapter 7, I seem to have some issues with the full install, so only building 'ip' sounds cleaner). This can go into the zlib-through-udev part of chapter 7, as I see it (build necessary extras, then files, then kernel, then arch-specifics, then stuff done as root) but what is the order ? I think the zlib-through-udev part could be alphabetical because it is all packages for the target which are not on the PATH, but I don't want to rearrange this now that we are in -rc.
First, I need to confirm that I can see the problem (all my sources and buildscripts are on nfs, which is why I build with eth0 up), Will try that when I have time.
comment:4 by , 18 years ago
I'm confused. I restored my boot system, with added iproute and network, went forward to perl, then took the interfaces down.
First, I stopped the network and localnet, which I thought should bring me close to the book. The test suite reported FAILED for ext/IO/t/io_multihomed and ext/IO/t/io_sock but then hung (machine inactive for more than 30 minutes) in ext/IO/tio_udp.
Retried with localnet started, but I got a FAIL in lib/Net/t/hostname.
Summary - it looks as if setting a hostname is indeed required, but I can't even get the tests to complete without the localnet commands. This is odd, I don't think I'm setting a hostname in my local builds, it shows as (none) but passes all the tests with the network up.
So, ignoring the minutiae of the details, I think we'll have to add both the hostname and ip commands, for people who boot. I'll hold off until I've got time to do a fresh build with a minimal 'ip' somewhere in chapter 7.
comment:5 by , 18 years ago
Ken,
What's even more wierd under my netboot builds this is not an issue because I configure the interface face without iproute2. I'm curious if you add in kernel autoconfig support for networks and add this line to the boot up if it would fix the problem.
ip={ip address}:{nfs server ip or blank}:{gateway ip}:{subnet mask}:{hostname}:{interface}:off
Curious if this will be an option to fix the issue.
comment:6 by , 18 years ago
I won't be able to look at this before September. I'd suggest a stop-gap of mentioning the failures in the text, but even that needs someone to confirm what fails.
comment:7 by , 18 years ago
Version: | unstable → 1.0.0 |
---|
comment:8 by , 18 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |