Subject: Re: Qube doesn't respond after a few minutes (current)
To: None <>
From: None <>
List: port-cobalt
Date: 03/01/2007 21:35:31
 -------------- Original message ----------------------
From: Dennis <>
> 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  root@taz:/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, 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  
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...