Closed
Bug 665967
Opened 13 years ago
Closed 13 years ago
OSError: [Errno 2] No such file or directory: 'browser_output.txt' (Android tegra talos)
Categories
(Release Engineering :: General, defect)
Release Engineering
General
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: davidb, Unassigned)
References
Details
No description provided.
Reporter | ||
Comment 1•13 years ago
|
||
Oops I guess tbpl-bot doesn't post here when you type the bug number by hand.
Android Tegra 250 mozilla-central talos remote-tp4m_nochrome
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1308677640.1308679798.27636.gz&fulltext=1
Reporter | ||
Comment 2•13 years ago
|
||
Lots of these started appearing today. See possibly related: bug 662127. Note: I think bear was doing some reconfig today that might be related.
Comment 3•13 years ago
|
||
I hid Android Talos on mozilla-central, mozilla-inbound and TraceMonkey, since they're all thoroughly busted.
Component: Talos → Release Engineering
Product: Testing → mozilla.org
QA Contact: talos → release
Version: unspecified → other
Comment 4•13 years ago
|
||
this error is inside of the test framework - bouncing this over to ateam so we can get their input
Component: Release Engineering → New Frameworks
Product: mozilla.org → Testing
QA Contact: release → new-frameworks
Version: other → unspecified
Comment 5•13 years ago
|
||
yeah, this is a quirky problem and I wish there was a better method for debugging this.
What we know is that the builds and the talos code works outside of the testing framework. I have tried a variety of tinderbox and nightly builds and verified the profiles and talos scripts are all working as expected.
In further debugging we don't see information from getInfo.html (the first step of talos) nor do we see anything in the apache access.log file. When accessing the same URL from a desktop machine, we see an entry in the access.log file, so the problem appears to be from fennec trying to access the URL.
That is an update from debugging last night and this morning
Comment 6•13 years ago
|
||
Because this is only happening on tegras that have been moved to a new controlling server and we are having zero luck so far finding out exactly why - we have decided to roll back tegras to the older controlling servers.
This will be happening all night as I can only move a tegra when it's idle.
I'll update once the move back is done.
Comment 7•13 years ago
|
||
1) from irc with bear: these same tegras pass talos tests when connected to "old" foopies / controlling masters. we believe this means the tegra itself is fine. The "old" foopies and "new" foopies are identical hardware, and (we believe) the same software. We're not sure whats different yet.
2) Moving this bug back to RelEng while we debug. The curious can follow along in bug#662400.
Component: New Frameworks → Release Engineering
Product: Testing → mozilla.org
QA Contact: new-frameworks → release
Version: unspecified → other
Comment 8•13 years ago
|
||
all of the tegras on the new foopies have been disabled and I have moved tegras 030 - 090 to the old foopies. will move 001 - 030 in the morning.
Comment 9•13 years ago
|
||
This problem is still showing up on try. It's worth announcing this kind of brokeness to dev.tree-management so that people don't waste time thinking that their changes caused it.
Comment 10•13 years ago
|
||
The tegras are not running on the new foopies so any brokeness would be just that, brokeness. Can you point me to a build that has this error so I can verify I didn't miss a tegra?
Comment 11•13 years ago
|
||
(In reply to comment #10)
> The tegras are not running on the new foopies so any brokeness would be just
> that, brokeness. Can you point me to a build that has this error so I can
> verify I didn't miss a tegra?
http://tinderbox.mozilla.org/showlog.cgi?log=Try/1308780526.1308782109.13712.gz&fulltext=1#err0
Comment 12•13 years ago
|
||
(In reply to comment #11)
> (In reply to comment #10)
> > The tegras are not running on the new foopies so any brokeness would be just
> > that, brokeness. Can you point me to a build that has this error so I can
> > verify I didn't miss a tegra?
>
> http://tinderbox.mozilla.org/showlog.cgi?log=Try/1308780526.1308782109.13712.
> gz&fulltext=1#err0
that was from the period when I was moving them back - so yes, it ran on an new foopy but that tegra is no longer on the new one.
thanks for the link and apologies for any wheel-spinning I may have caused
Comment 13•13 years ago
|
||
marking as closed - all of the tegras are moved and I haven't seen any orange related to this issue all morning.
tracking the tegra/new-foopy issue in bug 662400
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Comment 14•13 years ago
|
||
Looks like a form of this has cropped up again. Filed bug 678381.
Assignee | ||
Updated•11 years ago
|
Product: mozilla.org → Release Engineering
You need to log in
before you can comment on or make changes to this bug.
Description
•