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.
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?
Thanks
Dave
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.
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#entry...
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.
Cheers, mwh
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?
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#entry...
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?
Dave
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#entry...
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...
Cheers, mwh
On 21 Jan 2013, at 19:50, Michael Hudson-Doyle michael.hudson@linaro.org wrote:
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.
https://bugs.launchpad.net/lava-dispatcher/+bug/1102904
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#entry...
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…
https://bugs.launchpad.net/lava-dispatcher/+bug/1102907
Dave
linaro-validation@lists.linaro.org
-
Dave Pigott -
Michael Hudson-Doyle