Opened 16 years ago

Closed 16 years ago

#81 closed defect (fixed)

Failures in Perl test suite

Reported by: gomoko Owned by: clfs-commits@…
Priority: minor Milestone: CLFS Standard 1.0.0
Component: BOOK Version: CLFS Standard 1.0.0
Keywords: Perl check failure IPRoute2 network Cc:


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 " 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:1 Changed 16 years ago by ken

Actually, the hostname command is icing on the cake.

I'd like somebody with experience of the alphabetical changes to comment on moving iproute ahead of perl, vs adding it to what we build for the temp system (it builds ok there, akthough it is weird enough to use the host's compiler for one of its directories).

On the subject of tests, maybe we should comment that these will scrawl over another console if you have one open ? I'm assuming that in chroot this output goes to the log.

comment:2 Changed 16 years ago by chris@…

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 Changed 16 years ago by ken

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 Changed 16 years ago by ken

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 Changed 16 years ago by Jim Gifford


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 Changed 16 years ago by ken

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 Changed 16 years ago by Jim Gifford

Version: unstable1.0.0

comment:8 Changed 16 years ago by Jim Gifford

Resolution: fixed
Status: newclosed

Fixed applied r2591 and updated in r2632.

Note: See TracTickets for help on using tickets.