Pierre Labastie wrote:
On 06/09/2016 19:14, Bruce Dubbs wrote:
Last night I did a jhalfs run of LFS to get timing data fo 7.10 (and to check
gcc failures (they were OK)).
What I got was a hang in coreutils. The specific test was
tests/misc/seq-precision.sh where it does:
seq 999999 inf | head -n2 > out || fail=1
seq 1 .1 inf | head -n2 > out || fail=1
seq inf inf | head -n2 | uniq > out || fail=1
If you run these from the command line, there is no problem. Something
happens when running jhalfs that seems to be intercepting the sigpipe signal
when head exits and seg runs forever making the script hang.
Running the build/test from the command line seems OK.
When running jhalfs, I'd suggest editing lfs-commands/chapter06/116-coreutils
and adding
rm tests/misc/seq-precision.sh
I've not tested this. What I did was a 'ps -ef |grep nobody' and saw the seq
command running. I killed that and then did it twice more for the other two
calls and then the test completed.
---
In a second minor issue, when running jhalfs the tar extraction of packages
writes a sequence like:
Building target 133-man-db
tar: write error
The actual extraction seems to be OK. It does not happen on every file but
does for most.
Upon reflection it may be due to my disk setup. My drive is an SSD and I have
noatime as a part of the mount options. That may be the reason for the
message. However I don't get that message from the command line when working
from the SSD drive.
I've just rebuilt 7.10-rc1 on real hardware, and have none of those issues.
For the coreutils test:
PASS: tests/misc/seq-precision.sh
The SBU is rather long (13.8), but binutils was run at -j5, while coreutils is
run at -j1, so I do not think the test hanged for me.
What I know is that some test results are different in coreutils depending
whether the terminal is an X terminal or a linux console (the test
ssty-pairs.sh for example, does not pass on linux console). I have built in an
X terminal (LXTerminal).
Yes. For some reason the 'seq inf' problem seems intermittent. To me,
that points to a race condition, possibly in the kernel. My system is
pretty fast, but I don't know why that would cause a signal to be lost.
Thinking about it, we do intercept some signals in jhalfs, that might be the
reason. I am almost sure I have seen something similar to what you report in
the past. But now, what I usually do is to first configure jhalfs whithout
ticking "Run the Makefile", then manually type: make -C /mnt/lfs/jhalfs. This
way, no signals are intercepted... Maybe it'd be better to remove the
capability to automatically run the Makefile, and just have an informational
message "Configuration is now finished. Type "make -C /mnt/lfs/jhalfs" to
begin the build".
Right. I never have jhalfs run the makefile automatically. I always
cd /mnt/lfs/jhalfs
make
I do run over ssh though.
For the second issue, I am almost sure I do not see that, but since this part
is not logged, I cannot be totally affirmative. I have seen that on old debian
(6 maybe) versions, though.
In this case, the host was 7.10-rc1. I'll note that this never happens to
me from the terminal. Only in a script.
I posted to get it in the mailing lists. I'm not asking for changes.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
