Dave Pigott <dave.pigott@linaro.org> writes:

On 16 Jan 2013, at 19:40, Michael Hudson-Doyle <michael.hudson@linaro.org> wrote:

Dave Pigott <dave.pigott@linaro.org> writes:

Hi all,

http://validation.linaro.org/lava-server/scheduler/job/45124

This is on panda-es02. First of all, it ran out of space on root when
trying to mv uInitrd to a tmp directory. It *then* reported that
deploy-linaro-android-image had failed, and proceeded to try to boot
android *anyway*. Looks like we've got a logic break there.

Yea, that doesn't sound sane.

Shall I file a bug?

Please.

Looking on the board, it has indeed run out of space on the
rootfs. Has anyone any idea why? Michael H-D this is the board you
were doing audio testing on. Is this maybe a result of that?

I did all my testing in the test image, so, no, I hope not. /me pokes.

Haha, what?  /mnt/root is 509M and has an actual rootfs in?  Did we
somehow fail to stop after mounting it failed?  /me pokes some more...

No.  Look what happens here:

https://validation.linaro.org/lava-server/scheduler/job/44661/log_file#entry12

During the writing of the test rootfs, the board spontaneously reboots.
Then our retry logic kicks in and tries to transfer the rootfs again,
but of course /mnt/root is not mounted now and so it fills up /.

Not sure exactly what to do about this, it's a pretty surprising way for
things to screw up.  One thing that comes to mind is the fact that the
master image boots with a different prompt, if the download-retry logic
was careful to wait for the correct prompt before retrying, this would
not have happened.

That sounds like a really neat fix. Shall I file a bug for this too?

If you could be so kind…