Nexus 5: boot loop

I had a Nexus 5 stuck in a boot loop (Android logo/animation in a loop, not actually booting).

This is what I think I’ve done to fix the issue. It seemed that /persist partition was corrupt. I tried a factory reset, flash new stock images, and clear cache, etc before trying the following.

Note that I managed to boot Android 4.4, but nothing else; it did throw a shit load of errors though (Google Play crashes, etc).

First of all, get ADB & Fastboot here. You’ll also need an hex editor (mac).

This will unlock your phone’s OEM mode; and thus potentially voiding warranty and erasing all data (!).

Edit file paths as needed, this is a copy paste of what I can still see on my terminal.

If you know your device’s WiFi MAC & Bluetooth address that’ll be useful for later, as apparently that gets wiped.

Boot into recovery boot by turning off your device and then holding the power + volume down button.

$ ./fastboot-mac oem unlock
... OKAY

Flash openrecovery (TWRP):

./fastboot flash recovery ../openrecovery-twrp-2.8.5.2-hammerhead.img
sending 'recovery' (13918 KB)... OKAY
writing 'recovery'... OKAY

Boot into recovery mode (using volume buttons) from the recovery boot. ADB should work now. This will find a bunch of errors and destroy the partition.

nazgul ~/Android $ ./adb-mac shell

~ # e2fsck /dev/block/platform/msm_sdcc.1/by-name/persist
e2fsck 1.42.9 (28-Dec-2013)
Superblock has an invalid journal (inode 8).
Clear<y>? y
yes
*** ext3 journal has been deleted - filesystem is now ext2 only ***
Superblock has_journal flag is clear, but a journal inode is present.
Clear<y>? yes
/dev/block/platform/msm_sdcc.1/by-name/persist was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Journal inode is not in use, but contains data. Clear<y>?
yes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: -(75--1098)
Fix<y>?
yes
Free blocks count wrong for group #0 (2972, counted=3996).
Fix<y>?
yes
Free blocks count wrong (2972, counted=3996).
Fix<y>?
yes
Recreate journal<y>?
yes
Creating journal (1024 blocks): Done.
*** journal has been re-created - filesystem is now ext3 again ***
/dev/block/platform/msm_sdcc.1/by-name/persist: ***** FILE SYSTEM WAS MODIFIED *****
/dev/block/platform/msm_sdcc.1/by-name/persist: 30/1024 files (3.3% non-contiguous), 1124/4096 blocks

~ # e2fsck /dev/block/platform/msm_sdcc.1/by-name/persist
e2fsck 1.42.9 (28-Dec-2013)
/dev/block/platform/msm_sdcc.1/by-name/persist: clean, 30/1024 files, 1124/4096 blocks

~ # make_ext4fs /dev/block/platform/msm_sdcc.1/by-name/persist
Creating filesystem with parameters:
Size: 16777216
Block size: 4096
Blocks per group: 32768
Inodes per group: 1024
Inode size: 256
Journal blocks: 1024
Label:
Blocks: 4096
Block groups: 1
Reserved block group size: 7
Created filesystem with 11/1024 inodes and 1102/4096 blocks
Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done

So far, so good. Persist partition was corrupt and recreated.

The original howto (see below) said root (su) was needed here; however it worked without root for me (?).

Download this file (kudos to whoever made it) and unrar it. Use your hex editor to edit last 6 digits (“00 00 00”) to a valid hex value, or even better, your actual MAC address if you can remember/find it.

Now upload these two (hidden) files to /sdcard/:

nazgul ~/Android $ ./adb-mac push .bdaddr /sdcard/.bdaddr
0 KB/s (6 bytes in 0.078s)
nazgul ~/Android $ ./adb-mac push .macaddr /sdcard/.macaddr
1 KB/s (6 bytes in 0.004s)

And run these commands:

nazgul ~/Android $ ./adb-mac shell
~ # su
/sbin/sh: su: not found
~ # cd /persist
/persist # ls
/persist # mkdir bluetooth wifi
/persist # chown bluetooth:system ./bluetooth
/persist # chmod 770 ./bluetooth
/persist # ls
bluetooth
wifi
/persist # cp /sdcard/.bdaddr /persist/bluetooth
/persist # chown bluetooth:system ./bluetooth/.bdaddr
/persist # chmod 660 ./bluetooth/.bdaddr
/persist # chown wifi:system ./wifi
/persist # chmod 770 ./wifi
/persist # cp /sdcard/.macaddr /persist/wifi
/persist # chown wifi:system ./wifi/.macaddr
/persist # chmod 660 ./wifi/.macaddr
/persist # rm /sdcard/.bdaddr
/persist # rm /sdcard/.macaddr
/persist # reboot

Go back into recovery boot and flash Android (I flashed 4.4 first, made sure it worked, and then flashed 6.0.1 (latest at this time); but you can probably flash latest version right away. Also unzip the zip file with all the images inside the .tar.gz — we’ll need the files later:

nazgul ~/Downloads/hammerhead-mmb29k.6 $ ./flash-all.sh
sending 'bootloader' (3120 KB)... OKAY
writing 'bootloader'... OKAY
rebooting into bootloader... OKAY
sending 'radio' (45425 KB)... OKAY
writing 'radio'... OKAY
rebooting into bootloader... OKAY
archive does not contain 'boot.sig'
archive does not contain 'recovery.sig'
archive does not contain 'system.sig'
--------------------------------------------
Bootloader Version...: HHZ12k
Baseband Version.....: M8974A-2.0.50.2.28
Serial Number........: 0644c9920b105eb5
--------------------------------------------
checking product... OKAY
checking version-bootloader... OKAY
checking version-baseband... OKAY
sending 'boot' (9154 KB)... OKAY
writing 'boot'... OKAY
sending 'recovery' (10012 KB)... OKAY
writing 'recovery'... OKAY
sending 'system' (1020405 KB)... OKAY
writing 'system'... OKAY
erasing 'userdata'... OKAY
erasing 'cache'... OKAY
rebooting...

Note that it won’t actually boot yet, so go back into recovery boot, and flash userdata and cache (not sure why they go missing or get entirely erased):

nazgul ~/Downloads/hammerhead-mmb29k.6 $ ./fastboot flash userdata image-hammerhead-mmb29k/userdata.img
sending 'userdata' (137318 KB)... OKAY
writing 'userdata'... OKAY
nazgul ~/Downloads/hammerhead-mmb29k.6 $ ./fastboot flash cache image-hammerhead-mmb29k/cache.img
sending 'cache' (13348 KB)... OKAY
writing 'cache'... OKAY

Execute a normal boot now, and wait 5 to 10 minutes.

Android should boot up normally now.

You can also OEM lock your phone again, if you wish (but a sticky bit has been set).

I’ve followed these forum posts.

Waze not getting a GPS fix

TL;DR: recalibrate your compass.

I’ve come across an issue for the past 10 days that Waze kept losing its GPS fix. This meant:

  • constantly switching between 0 and 120 (or whatever) km/h
  • constantly zooming in & out on maps (dynamic zoom level depending on speed)
  • being in a field/not on the road for most of the time, or stuck to a location of many minutes ago
  • often & randomly losing GPS fix (ie middle of the highway without any buildings blocking the line of sight)
  • I could do a 45 minute trip with Waze never getting a GPS fix
  • not knowing road issues (accidents, traffic jams ahead, speed traps, etc)

Things I tried:

  • nothing changed (no new car window, didn’t move my phone location in the car, etc)
  • not moving (ie parked car) didn’t really improve the GPS fix
  • even left my phone with Waze on in the car for 30 minutes parked (got a fix, but later that evening when driving home it started to lose its GPS fix again)
  • clear Waze cache
  • uninstall Waze completely
  • GPS Essentials showed a fix with 3 or more GPS satellites when Waze couldn’t get a fix
  • I was about to find a way to reset my GPS and/or clear its cache (???)

PS: I have had this issue in the past (I believe with the same phone, a Nexus 5), but it went away after several days.

What I did notice, however, is that in Google Maps the arrow (clicking the pin point button twice or something) was pretty much showing the opposite direction of how the car was moving (thus driving backwards at ~120km/h). This made me think, as I know the GPSes in smartphones are quite cheap and aren’t always on (to save battery — my phone is always being charged in the car though) and the phone uses the accelerometer and other sensors to “guess” current path (or rather, path changes, ie taking a turn or slowing down/accelerating).

I then recalibrate my compass using this method with the free app GPS Essentials (compass tab). I noticed two things

  • my compass was showing south as north
  • calibrating it in my room (no known magnets here) gave a mixed result (it sometimes pointed north, and sometimes stopped doing so)
  • moving around gave me a better calibration (more accurately pointing north)
  • question? Is the compass chip fucked? broken? cheap ass crap?

Trying now again driving around with Waze:

  • Waze almost instantly has a GPS fix
  • Waze doesn’t lose its GPS fix most of the time but …
  • Waze still occasionally loses its fix (but regain it after a second or two, three)

So it’s not always a GPS issue, but rather an issue with one of the other sensors (what here seems to be the compass).

Edit: the problem comes back after ~1 day. Compass often stuck and doesn’t really point north. Ever. Calibrating sometimes helps, but it ends to get stuck again after a while. Nexus 5 chipset issue? Google Navigation works (way) better (it doesn’t remain at the same location for ~10 minutes), but it’s not very precise either (always lagging behind a a street or cross road or something). Perhaps Google Navigation is better at using GSM localisation and doesn’t use the compass to figure out so much?

Edit 2: It works “fairly ok” if I calibrate my compass just before driving. It still loses its fix a few times, but all in all it was acceptable.

I’ve seen in tools like GPS Status that north always points to the bottom right (“south east”) unless it finds a GPS fix. When it’s stuck “finding GPS location” my compass is entirely off and Waze is seeking a fix. When it has a GPS location Waze is fine.

Note that while it cannot find a GPS location, it does have a fix with 3+ GPS satellites.

So I’m not sure if it’s a compass issue, or a GPS issue, and what the definite difference is between both (a smartphone compass not being a magnetic compass if I understand correctly).

Courier IMAP and auto deleting trash after 7 days

E-mails that had been deleted for over 7 days were automatically removed from the IMAP server. E-mail date was ignored (ie the mail could have been from 2010; the actual time in “Trash” counted). This didn’t happen to other folders (Sent, Archive, Spam). This recently happened and hadn’t happened before.

I had to restore my trash folder from backups every 7 days (yay for rdiff-backup).

It took me a while to figure it out… The problem first appeared in October, right after several big changes:

  • Yosemite update
  • Airmail to Airmail 2 update (I was convinced this was the root cause, looking at my clients instead of the server)
  • Android 5.0.x
  • Android Email app sunset, changes to GMail app
  • IPv6 working decently at home after updating my RPi to Fritzbox devices.
  • Random connection errors in GMail app (this was due to misconfigured DNS in the GMail app and causing IPv6 catch all to redirect to the webserver instead of the mailserver. It didn’t happen consistently because over mobile (4G & lower) there is no IPv6 and at home is randomly falls back to IPv4 as well. IPv4 DNS was well configured.
  • Moving my ~100.000 deleted e-mails from “Deleted Items” (OS X Mail default) to “Trash” (Android & Courier default) to stop having to move them manually from one folder to the other every so often. => this was eventually the cause but I didn’t realize.

Being convinced it was most likely Airmail 2 and very maybe Android I had been looking in that direction.

Debugging was also extremely slow as I had to wait 7 days before being able to check if the changes I made helped anything.

I eventually figured out that it was not Airmail when I rebuild my whole mail database and it defaulted back to putting my deleted mails into the Archive folder instead of Trash. Archive mails were kept over 7 days, but items in Trash still removed.

That’s when I started looking at Courier IMAP config: /etc/courier/imapd (and not imapd-ssl).

There’s an option that says:

##NAME: IMAP_EMPTYTRASH:0
#
# The following setting is optional, and causes messages from the given
# folder to be automatically deleted after the given number of days.
# IMAP_EMPTYTRASH is a comma-separated list of folder:days.  The default
# setting, below, purges 7 day old messages from the Trash folder.
# Another useful setting would be:
#  
# IMAP_EMPTYTRASH=Trash:7,Sent:30
#
# This would also delete messages from the Sent folder (presumably copies
# of sent mail) after 30 days.  This is a global setting that is applied to
# every mail account, and is probably useful in a controlled, corporate
# environment.
#
# Important: the purging is controlled by CTIME, not MTIME (the file time
# as shown by ls).  It is perfectly ordinary to see stuff in Trash that's
# a year old.  That's the file modification time, MTIME, that's displayed.
# This is generally when the message was originally delivered to this
# mailbox.  Purging is controlled by a different timestamp, CTIME, which is
# changed when the file is moved to the Trash folder (and at other times too).
#
# You might want to disable this setting in certain situations - it results
# in a stat() of every file in each folder, at login and logout.
#
IMAP_EMPTYTRASH=Trash:7

Comment out that last line, and restart courier-imap(-ssl)… Simple as that.

This solved my issue.

I’m not sure when that config change happened (Debian update?) and I do not know who at Courier thought it was a good idea …. But sheesh.

Mac OS X Mavericks + VLC top bar

Mavericks, and its new “multi display support” adds a grey-ish bar to the top of VLC when watching anything full screen.

VLC-fullscreen-header

I never found a way to get rid of it, and it has annoyed me ever since. Until yesterday…

This is how to get rid of it:

  1. play movie
  2. drag to 2nd screen
  3. click Video > Float on Top
  4. go full screen (cmd+F or Video > Fullscreen)

float-that-shit

Keep in mind, that once you get out of full screen, and get back in it, the bar will be back. Enabling and disabling the above mentioned option won’t change it anymore. The only solution I’ve found was to quit VLC entirely, reopen it, go back the where the movie was, click the option, and go full screen…

plxthx for buggy releases.

Edit: Today I am unable to apply my above mentioned ‘fix’. I have however found another option under VLC preferences: “Interface > Use the native fullscreen mode”. Deselect that option, and it seems to be working.