1122292 - b2g-28.1 ANDROID_SERIAL doesn't match reported serial number from device

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Infrastructure, defect)

Description

[Geo Mealer [:geo] -- This account is inactive after 2015-07-07]

b2g-28.1 has been failing all builds for a week or so now.

ANDROID_SERIAL was set to e479daa8.

adb devices shows that the device that was that (I assume) is now 0123456789ABCDEF, which I think is a generic serial used by either Android or ADB for unserialized devices.

Net result is any adb -s $ANDROID_SERIAL command was failing, blocking all the jobs.

I did change ANDROID_SERIAL in the Jenkins slave config, but it didn't take. I assume the slave needs to be restarted to take the new config, but since I'm not familiar with our infrastructure I opted not to touch it further.

If we need to reflash the device with something to get a real serial number back, let me know and I can take that route. Otherwise, the slave needs to be kicked to take the new config.

In the meantime, 28.1 is offline.

Comment 1

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

I'm not sure, but there might be a chance of getting the adb serial number via reflashing the device via images ( ie fastboot ).  I think the serial numeration (if that's even a term) is done in the kernel?  I haven't dug into it; though I do know we requested a vendor who had to change something in the gonk layer to accommodate our request.  So I think it's in the boot.img

Also to note, fastboot may give you a different serial number than adb depending on the device.  If it's a flame it should be the same though.

Comment 2

[Dave Hunt [:davehunt] [he/him] ⌚BST]

(In reply to Geo Mealer [:geo] from comment #0)
> adb devices shows that the device that was that (I assume) is now
> 0123456789ABCDEF, which I think is a generic serial used by either Android
> or ADB for unserialized devices.

We need the devices to be uniquely identifiable. I've not seen this serial before but it would be better to somehow restore the unique serial rather than modify the environment variable.

> I did change ANDROID_SERIAL in the Jenkins slave config, but it didn't take.
> I assume the slave needs to be restarted to take the new config, but since
> I'm not familiar with our infrastructure I opted not to touch it further.

Yes, the slave would need restarting. This can typically be done by disconnecting and reconnecting via the Jenkins UI. The environment variables can be checked here: http://jenkins1.qa.scl3.mozilla.com/computer/b2g-28.1/systemInfo

Comment 3

[Geo Mealer [:geo] -- This account is inactive after 2015-07-07]

(In reply to Dave Hunt (:davehunt) from comment #2)
> (In reply to Geo Mealer [:geo] from comment #0)
> > adb devices shows that the device that was that (I assume) is now
> > 0123456789ABCDEF, which I think is a generic serial used by either Android
> > or ADB for unserialized devices.
> 
> We need the devices to be uniquely identifiable. I've not seen this serial
> before but it would be better to somehow restore the unique serial rather
> than modify the environment variable.

Agreed. It was a band-aid to get the machine back online, since it is unique in the context of that one host.

Since I wasn't able to get things reset, though, I'll look into Naoki's suggestion of reflashing to base first. Failing that working, I'll do the env change and we can continue to discuss options for getting a serial assigned.

Comment 4

[Geo Mealer [:geo] -- This account is inactive after 2015-07-07]

Reflashing the device fixed it.

webqa@b2g-28:~$ adb devices
List of devices attached
e47cd84d	device
e479daa8	device

Comment 5

[Geo Mealer [:geo] -- This account is inactive after 2015-07-07]

(I also restored the config variable and brought the node back online)