Errors Hardware Misc Software Windows

Screen going black with AutoCAD (LT)

I am not sure what is the problem — I’ve upgraded Shan’s 27″ 2k monitor to a 32″ 4k monitor and AutoCAD LT recently updated from 2021 to 2022. Shan‘s been using a 2017 i5 NUC (NUC7i5BNB) with 32Gb RAM using the onboard GPU. Something that should be plenty for a bit of Windows, Chrome, Photoshop and AutoCAD LT.

For the past few weeks, several times a day her screen would black out for half a second or so and then everything should go back to normal. Sometimes it would happen several times in a row, sometimes it wouldn’t for hours on end.

I tried several things, including getting a 8k 120hz HDMI cable, using a usb-c to DP cable, changing the GPU vRAM minimum from 128Mb to 2048Mb (quite the hack, as it can’t be set in the bios — requires messing around in the registry. Wow.), updating all the drivers, updating the bios, making sure the NUC was properly ventilated and keeping cool (every full moon the NUC shuts down due to overheating in Singapore if I set the fan to ‘balanced’ instead of ‘cool’), and probably more. And because it happened so sporadically it was quite hard to debug (to the point I sometimes didn’t want to believe her as I couldn’t see it blacken out).

Shan was getting frustrated (which in turn means I get frustrated)… and I started looking at getting either an eGPU (I can get a free Nividia M6000, just need the enclosure, but the enclosure would be $$), an AMD Ryzen 5 or 7 NUC (no more Intel in this house, but also $$$), or some other refurb (massive) desktop some friend had lying around (HP z240 or something, zero $, but Shan would kill me for having this massive thing on her desk).

Turns out, the quick fix, was to simply disable hardware acceleration.

Run GRAPHICSCONFIG and uncheck hardware acceleration.

This is probably not ideal in the long run (hopefully it’s an issue with AutoCAD 2022 that is getting fixed, as opposed to the onboard Intel GPU getting messed up with AutoCAD).

When in doubt… Turn off hardware acceleration.

Apple Errors Software

Apple Watch OS7 stopped showing the date

I’ve been running the Apple WatchOS 7 beta for a while now, and when updating, my watch face lost the “date”: it was no longer showing the date and day of the week (i.e. Fri).

Quite annoying — but it’s a beta after all. I shouldn’t complain. I did what every good beta tester would do: I filed a bug (it’s still unanswered from what I can see).

Beta updates came and went but the date did not come back. Would I be unable to use my watch to figure out the date?! It’s when you lose a feature that you see how often a day you use it.

And then, out of the blue, the big stable release. Apple Watch OS 7 is released to the general public. Surely, I thought, they must’ve fixed it now.

But alas, I was to be disappointed.

I updated Shan‘s watch (that never ran the beta) to see if she had the same issue — but her watch was fine. Sooooo… What was I doing wrong? Why me, Apple Overlord?

I started fiddling around with my language and regional settings (nope, not it), and was contemplating a factory reset (argh, re-adding all my cards to Apple Pay)…

And then…

An epiphany.

They wouldn’t?!?! Would they??

Something only Apple would dare to do.

I deleted the Apple Calendar app (on my iPhone) — as I use the Google Calendar app. Would that somehow be related?

And guess what… Installing the Apple Calendar app via the App Store resolved it:

Check Apple Watch and the option is back!

That’s one way of forcing people to use your apps.

Errors Google Hardware

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-
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
*** 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>?
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)
Free blocks count wrong for group #0 (2972, counted=3996).
Free blocks count wrong (2972, counted=3996).
Recreate journal<y>?
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
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
/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 $ ./
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-
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

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.

Errors Google Hardware Software

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).

Apple Errors Linux Networking Software

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:

# 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.

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.