Restore /system/etc/hosts on testing tegras

RESOLVED FIXED

Status

RESOLVED FIXED
7 years ago
5 years ago

People

(Reporter: jchen, Assigned: bear)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [android][tegra][talos][android_tier_1])

Attachments

(1 attachment)

Bug 687367 fixes the underlying cause for the getaddrinfo crash, and to test for it, the workaround from Bug 678992 should be reverted.
hmm, I hope we can just copy a file there.
(In reply to Joel Maher (:jmaher) from comment #1)
> hmm, I hope we can just copy a file there.

yeah I think that'll work. Or do the equivalent of |echo '127.0.0.1 localhost' > /system/etc/hosts|, instead of |rm /system/etc/hosts|
Depends on: 694325
we should get this resolve in the short term.  A simple fix and we need the hosts file for accurate testing.
adding tier1 so we don't lose this again.
Whiteboard: [android][tegra][talos] → [android][tegra][talos][android_tier_1]

Updated

7 years ago
Assignee: nobody → armenzg
Created attachment 596102 [details] [diff] [review]
tools/sut_tools/cleanup.py patch to add hosts file (1.0)

we will need to land, and reconfig.
Assignee: armenzg → jmaher
Status: NEW → ASSIGNED
Attachment #596102 - Flags: review?(armenzg)

Comment 6

7 years ago
Comment on attachment 596102 [details] [diff] [review]
tools/sut_tools/cleanup.py patch to add hosts file (1.0)

FTR this patch does not handle the case when the file already exists and it is different than we expect.

This could be a problem after re-imaging a tegra and placing file we do not wish in there.
Before we land this I would like to figure this out with bear and see what needs to be done to verify that we won't have such problem.

Does this get deployed by updating the foopies?

jmaher, in the list of priorities: where does this bug fit? what other work does this block?
Attachment #596102 - Flags: review?(armenzg) → review+
I did a fresh image on my tegra using the one and only image we have and that is where I got the:
127.0.0.1 localhost



This bug should get rolled in when we have a chance.  I don't think it needs to be done today, but waiting a few weeks wouldn't be wise either.  If we could get it into staging or a reconfig this week that would be great, otherwise an eta for the following week?
(Assignee)

Comment 8

7 years ago
(In reply to Armen Zambrano G. [:armenzg] - Release Engineer from comment #6)
> Comment on attachment 596102 [details] [diff] [review]
> tools/sut_tools/cleanup.py patch to add hosts file (1.0)
> 
> FTR this patch does not handle the case when the file already exists and it
> is different than we expect.
> 
> This could be a problem after re-imaging a tegra and placing file we do not
> wish in there.
> Before we land this I would like to figure this out with bear and see what
> needs to be done to verify that we won't have such problem.

this won't be a problem if a tegra is reimaged because their code is replacing any existing hosts file.

> 
> Does this get deployed by updating the foopies?

yes, all of the foopies will need to have their tools repo updated

> 
> jmaher, in the list of priorities: where does this bug fit? what other work
> does this block?
(Assignee)

Comment 9

7 years ago
I applied the patch to foopy05 and 06 and they are now running it for staging
(Assignee)

Comment 10

7 years ago
please assign this to me when you are happy with the staging run and i'll land this and roll it out to production
this looks great in staging.
Assignee: jmaher → bear
(Assignee)

Comment 12

7 years ago
Comment on attachment 596102 [details] [diff] [review]
tools/sut_tools/cleanup.py patch to add hosts file (1.0)

committed changeset 2231:71f25c728965
(Assignee)

Comment 13

7 years ago
deployed
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED

Updated

5 years ago
Component: Infrastructure → General
You need to log in before you can comment on or make changes to this bug.