Re: Qube doesn't respond after a few minutes (current)

 -------------- Original message ----------------------
From: Dennis <mips128gmx.net>
> I have updated the qube (with the binary package to
current):
> # uname -a
> NetBSD  4.99.11 NetBSD 4.99.11 (GENERIC) #0: Tue Feb 20
01:22:15 UTC 
> 2007  
> 
[...]
> Unfortunately, the qube froze after around 10 to 15
minutes while 
> compiling. I couldn't ping the qube, nor I got
something from the serial 
> console :( This error is "reproducable" ...
> 
> /var/crash is empty. So I have no information what
happens.
> 
> Does anybody know where I can start looking. Or if this
current version 
> is buggy?
> 
> I really would love to get bulk build running ...
> 


I grabbed the Feb 8 kernel binary  that Andy built as a test
while he still had it around 
qube# uname -a
NetBSD qube 4.99.9 NetBSD 4.99.9 (INSTALL) #0: Thu Feb  8
08:02:51 MST 2007  roottaz:/usr/obj-current/sys/arch/cobalt/compile/INSTALL
cobalt

and booted to it; for some reason it wants to netboot at
each restart, but I can go in from console and redirect
things where they should be.  It looks like the INSTALL
config was last touched Nov 8 2006.

Anyway it seems to be running fine, I'm 1.5 days into
building distribution with build.sh, after doing the tools
earlier.

I did have a strange issue that I don't understand yet:

I also got the binaries that he built at the same time;
unpacked them, put them in /binnew for short-term, and left
my /bin in place.

To test a little before properly placing them and rebooting
I tried a  
/binnew/ls
 
but it breaks.  Same with a couple other commands:

qube# /binnew/ls
/binnew/ls: Undefined PLT symbol "__fts_open32"
(symnum = 87)
qube# /binnew/mv
usage: mv [-fiv] source target
      mv [-fiv] source ... directory
qube# pwd
 /
 qube# mkdir testdir
 qube# /binnew/mv /testdir /testdir2
 /binnew/mv: Undefined PLT symbol "__stat30"
(symnum = 43)
> qube#

I thought I could just take the new binaries and drop them
in, and go (if I did the whole base and userland at once,
plus etcupdate and whatnot).  The kernel is built from the
same snapshot as these binaries.  Likely I'm missing
something obvious.
 
Anyway I decided this wasn't saving me much time and I'm
doing OK with the build with no crashes so far.
Using the Feb 8 kernel and src from Feb 16th.

I had tried to build the toolchain using a July 2005
-current kernel and the system crashed.  It took me about
45min at reboot to step through the mangled files from
console.  I should be working in /tmp so I can just wipe the
whole thing if need be, if it happens again.  But Andy had
just built the whole thing from 3.1 stable...

Brian

This almost sounds like it's picking up the wrong libs.

If you take the new binaries and put them all in their own
tree and
chroot into that, do you see the same issue?

-=erik.


On 3/1/07, bmcewencomcast.net <bmcewencomcast.net> wrote:
>
>  -------------- Original message
----------------------
> From: Dennis <mips128gmx.net>
> > I have updated the qube (with the binary package
to current):
> > # uname -a
> > NetBSD  4.99.11 NetBSD 4.99.11 (GENERIC) #0: Tue
Feb 20 01:22:15 UTC
> > 2007
> >
> [...]
> > Unfortunately, the qube froze after around 10 to
15 minutes while
> > compiling. I couldn't ping the qube, nor I got
something from the serial
> > console :( This error is "reproducable"
...
> >
> > /var/crash is empty. So I have no information what
happens.
> >
> > Does anybody know where I can start looking. Or if
this current version
> > is buggy?
> >
> > I really would love to get bulk build running ...
> >
>
>
> I grabbed the Feb 8 kernel binary  that Andy built as a
test while he still had it around
> qube# uname -a
> NetBSD qube 4.99.9 NetBSD 4.99.9 (INSTALL) #0: Thu Feb 
8 08:02:51 MST 2007  roottaz:/usr/obj-current/sys/arch/cobalt/compile/INSTALL
cobalt
>
> and booted to it; for some reason it wants to netboot
at each restart, but I can go in from console and redirect
things where they should be.  It looks like the INSTALL
config was last touched Nov 8 2006.
>
> Anyway it seems to be running fine, I'm 1.5 days into
building distribution with build.sh, after doing the tools
earlier.
>
> I did have a strange issue that I don't understand
yet:
>
> I also got the binaries that he built at the same time;
unpacked them, put them in /binnew for short-term, and left
my /bin in place.
>
> To test a little before properly placing them and
rebooting I tried a
> /binnew/ls
>
> but it breaks.  Same with a couple other commands:
>
> qube# /binnew/ls
> /binnew/ls: Undefined PLT symbol
"__fts_open32" (symnum = 87)
> qube# /binnew/mv
> usage: mv [-fiv] source target
>       mv [-fiv] source ... directory
> qube# pwd
>  /
>  qube# mkdir testdir
>  qube# /binnew/mv /testdir /testdir2
>  /binnew/mv: Undefined PLT symbol "__stat30"
(symnum = 43)
> > qube#
>
> I thought I could just take the new binaries and drop
them in, and go (if I did the whole base and userland at
once, plus etcupdate and whatnot).  The kernel is built from
the same snapshot as these binaries.  Likely I'm missing
something obvious.
>
> Anyway I decided this wasn't saving me much time and
I'm doing OK with the build with no crashes so far.
> Using the Feb 8 kernel and src from Feb 16th.
>
> I had tried to build the toolchain using a July 2005
-current kernel and the system crashed.  It took me about
45min at reboot to step through the mangled files from
console.  I should be working in /tmp so I can just wipe the
whole thing if need be, if it happens again.  But Andy had
just built the whole thing from 3.1 stable...
>
> Brian
>