5

After discovering the hard way that rooting modifying /system looking at /system the wrong way breaks updates, I've decided to drop all of the power-user stuff and just go the sanctioned route—no custom recovery system or rooting or anything; just pure, stock Android. To that end, I set about performing a factory reset [unrooting], so to speak.

These are the steps I've followed:

  1. Acquire the platform-tools for your computer's operating system. Extract them and add the resulting directory to your $PATH.
  2. Download a stock-Android image, making sure that the model identifier matches that of your device, but that the version is not the latest (this is necessary for step 8). Verify the image using the hash included in the table, then extract it. Fire up a shell if you haven't already, and change to the extracted directory.
  3. Unlock the bootloader (fastboot oem unlock).
  4. Reinstall Android (./flash-all.sh). Be sure to catch the device before the last reboot by holding down the boot-to-recovery key combination as soon as the script prints rebooting... after writing the cache image (this saves you having to reboot again for the next step).
  5. Lock the bootloader (fastboot oem lock).
  6. Reboot. Wait for Android to…do whatever it does when you boot a new version for the first time.
  7. Go through the initial device setup. (I personally connect to a Wi-Fi network, and then skip everything else to save a bit more time).
  8. Check for, download, and install an Android OS update. Wait some more while that happens.
  9. Observe the following on the device's screen, with the text Error! in white beneath it:

Pictured: the Android robot on its back, with an exclamation mark inside a red triangle.

  1. Bring up the recovery menu and choose View recovery logs, then /cache/recovery/last_log. Scroll to the bottom and look for an indication of why the update failed. Transcribe the most relevant lines, along with the version and build ID of the image from step 2.

My device is a Nexus 5, purchased in November of 2013 from the Play Store. So far, I've tried this using Android 6.0.0/MRA58K and Android 5.1.1/LMY48M, which produced the following in the recovery logs:

6.0.0/MRA58K:

failed to stat "/cache/saved.file": No such file or directory
script aborted: "/system/priv-app/SetupWizard/oat/arm/SetupWizard.odex" has unexpected contents.

5.1.1/LMY48M:

Remounting and verifying system partition files...
script aborted: assert failed: sha1_check(read_file("/system/fonts/NotoSansTC-Regular.otf"), some_hash)

In both cases, the problem seems to be a file under /system with contents that aren't equal to the ones the update installer is expecting. This is exceptionally frustrating, given that my procedure specifically calls for official stock-Android images, retrieved from none other than Google's website and verified using the hashes they publish (and yes, I make sure to use TLS).

Did I miss a step? What's going wrong here? And how do I get back onto the blessed path and be once again deemed worthy to receive the long-sought-after over-the-air updates?

Blacklight Shining
  • 161
  • 7
  • What was the vague error? Downloads from the Google android themselves factory images: https://developers.google.com/android/nexus/images?hl=en android current android SDK: http://developer.android.com/sdk/installing/index.html – Bo Lawson Jan 09 '16 at 22:09
  • @BoLawson The error is the linked picture of the Android mascot, with the literal text Error! below it. And yes, I got the image from the page you linked. – Blacklight Shining Jan 09 '16 at 22:12
  • Well…okay. Any insights as to why OTA updates still aren't working? – Blacklight Shining Jan 09 '16 at 23:28
  • It just happens sometimes but it could just be a corrupted download. You could check the recovery logs in recovery. It should be the last option to see what they state. It might have the last_log within it. /cache/recovery/last_log – Bo Lawson Jan 10 '16 at 00:36
  • @BoLawson Hmmmm…two different things jump out at me: failed to stat "/cache/saved.file": No such file or directory and script aborted: "/system/priv-app/SetupWizard/oat/arm/SetupWizard.odex" has unexpected contents.. – Blacklight Shining Jan 10 '16 at 00:42
  • Your still not stock flash the factory image from Google again. – Bo Lawson Jan 10 '16 at 01:32
  • @BoLawson No? What am I flashing, then, and where do I get the factory image? – Blacklight Shining Jan 10 '16 at 02:03
  • Can you adb sideload the OTA update package in recovery? What are the OTA updates for (which version to which version)? You can search for xxx OTA zip on Google to get the zip file to sideload, as long as the xxx represents the correct corresponding OTA. It could indeed be a bad download of the OTA package itself, and this should help clarify the problem. – Tamoghna Chowdhury Jan 10 '16 at 06:11

2 Answers2

1

Reverting back to original rom requires a full format as partitions as well as their attributes are usually different on different ROMs. This will solve your problem with the advent of a possible change in the device's info such as IMEI or similar. Another setback is the reduction in memory from formatting, especially if your partitions contained a lot of user data during the format.

Suggestion: repeat your steps again, but this time make sure to mount your /system partition and format it as well, unmount it after (it should automatically unmount).

Now. Let the flashing begin...

VisqoDaGrammar
  • 46
  • 2
  • 1
    I really don't think this is it, given that each script indicated every time I ran them that they were erasing 'system', then downloading 'system' and writing 'system'. – Blacklight Shining Jan 10 '16 at 11:35
  • Also…what? I've never heard of trying to format a partition while it was mounted. And why would I lose storage space if there was a lot of user data before a format? – Blacklight Shining Jan 10 '16 at 11:37
0

I don't have an explanation for you, but try more versions in general, and build MRA58N in particular.

Blacklight Shining
  • 161
  • 7
  • I have absolutely no idea why this worked. If I had to guess, I'd guess that the two images I originally tried installing from had bad /system files, but a mistake like that seems extraordinarily unlikely. – Blacklight Shining Jan 10 '16 at 11:31