...or that's my best guess at least, based on what we saw at the connect. Somewhere, there was an image floating around at the connect with a new hwpack that had a bug where the kernel would not recognize eth0. This is causing *big* problems when it tries to send back the results and doesn't see an eth0. Did these change??? If not, then something is changing the master image kernel, which is really bad.
root@master:/tmp/lava/results# ifconfig -a
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
sit0 Link encap:IPv6-in-IPv4
NOARP MTU:1480 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
root@master:/tmp/lava/results# uname -a
Linux master 3.0.0-1002-linaro-omap #3~ppa~natty-Ubuntu SMP PREEMPT Fri Jul 29 01:18:40 UTC 2011 armv7l armv7l armv7l GNU/Linux
This particular example was on panda03
Ok, I know what's happening now. First, here's the known list of affected boards:
panda01
panda02
panda03
[panda04 is down still, so I can't check]
beaglexm01
beaglexm03
We have a new test running now, bootchart, which calls flash_kernel, installing a new kernel on the default partition for this board regardless of the fact that we ran it in chroot. I'm working on a workaround for this, and have disabled bootchart in the daily runs for now. In the meantime, we need to get the boards fixed, starting with the panda boards, because we currently have *no* panda boards available for testing.