[Clfs-dev] Weirdness.

[Ken Moffat]

 Well, this has been a *strange* day as far as the ppc I'm using is
concerned.  Finished a build of trunk several hours ago, added my
essentials (particularly nfs), then failed to boot - looked as if
eth0 didn't exist, the process hung trying to bring up ntp.

 Back to the host system, somehow managed to fill its '/' totally,
and somehow I've lost X even after I restored from a backup - the
host now has plenty of space but gdm just hangs with a black screen.
If I telinit 3, log in and startx I get no errors except for one
'end of block range < beginning' message which I always get (I'm on
a third system on the same box, and that has this same error in gdm's
log). Strange.

 Anyway, now that I'd lost 2.6.23.12 from the host system I was
originally using, I figured I might as well copy the kernel and
modules from the new system - they worked perfectly.

 Took a look at the udev rules - the host (running udev-113) had a
70-persistent-net.rules file which associated the mac address with
eth0.  To my knowledge, I never deliberately created that, and the
timestamp suggests it was generated around the time I had first
booted the host.  Copied it over to the new system, almost booted -
got a dhcp lease, ntp came up, but then mount.nfs failed 'no such
device'.  And the keyboard was now inoperative.  This is my first
experience with udev-118, maybe I've missed a change (I got the
change in the make and install commands, but maybe there is
something else I should have changed ?)

 Any useful suggestions to help me understand WTF is going wrong
would be much appreciated.

 Oh, and I had some failures in the testsuites.  Some were fine,
some had the same sort of failures I've seen recently, e2fsprogs
suite seemed to fall apart after failing the regression test for the
ss library.  Gcc reported catastrophic failures - 30340 for gcc
itself, 11951 for g++, 520 in libmudflap, 198 in libgomp.  I suppose
some of that _might_ be down to changes in the branch_update which
will require changes to the testsuite.  Dunno.  I can't now check
what was in /usr when I entered chroot, but my script normally
manages to create the symlinks for libgcc_s without any problems.
Glibc (without the troublesome part of the branch update) only had 5
failures which looks good.  Binutils had 4 in the binutils tests
themselves, which is almost certainly the branch update changing
things, and doesn't worry me.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce