Tag: troubleshooting

Moto G6 Plus without GPS Lock

I’ve been a quite happy owner of the Moto G6 Plus for some years now. Since the beginning, I always had a “minor” issue: sometimes the GPS started to suddenly stopped getting a lock. Which was especially cumbersome, if I was using the phone as navigation system while driving. Today, the GPS lost it’s locking mid-drive and I’ve not been able to reestablish it, not even by power-cycling the device. Also various attempts of changing battery saving options and changing location accuracy settings did not result in any improvements (normally it did). The internal diagnostics of the device (*#*#2486#*#*) just said it didn’t get a lock.

My assumption was that it somehow might be related to the A-GPS data. Therefore I looked if there was any tool in the Play Store that might help me clear the A-GPS data, and luckily I stumbled upon “GPS Status & Toolbox“. Even in the free version it allowed to clear the A-GPS data and from this “cold start” mode the device got a lock rather quickly. To support the devs, I decided to upgrade to the PRO version for less than €2,00.

I’m now curious if this is a long-term fix or if it was just lucky coincidence. I’m hoping for the first.

Quick Checklist

  • Disable battery optimizations on Google Maps (and any navigational map you might be using)
  • Disable battery optimization for the “LocationService”
  • Turn off WiFi- and Bluetooth-Background Scans since they might clash with Improved Google Location Accuracy setting
  • Use a tool (like GPS Status & Toolbox) to reset A-GPS data of the GPS receiver

Update 2020-01-06

Since I’ve installed “GPS Status & Toolbox“, the problem has been fixed. Never had the problem of not getting a GPS fix any more.

OCZ Vertex2, Linux, and ancient nForce 430 chipset

Today I finally received my brand-new Ocz Vertex2 OCZSSD2-2VTXE120G 120GB and eagerly wanted to install it in my 4-year-old HP workstation which currently is running Ubuntu 10.10 exclusively.

After setting up the alignment according to some tutorials I found online, I started the setup process. Shortly after starting the copy step of the installation, the whole process came to a grinding halt with filesystem errors. Looking into the kernel debug messages it seemed like SATA commands were causing errors. After checking hardware, cables and switching SATA ports, I began researching the issue and soon found that the issue might be fixed in the next firmware version of the drive. So I wanted to upgrade from 1.23 to 1.24, which could only be done in Windows…

After installing a trial of Windows 7, I finally wanted to upgrade the firmware, but the drive was not detected, but was accessible. The release notes indicated that I would need to switch to AHCI mode. After several attempts, includig a BIOS update, I realized that there was no way to do this with my old hardware, as my nForce 430 chipset simply doesn’t support it.

So my only remaining option was to simply try the kernel arguments I read to be the fix for 1.24 with the 1.23 hardware.

So, if you add the following kernel option during installation and afterwards for every boot, the disk seems to work quite well (source):

libata.force=norst

Actually, this forces the ATA driver in Linux to not issue any reset commands on the bus. I really don’t understand why this improves/fixes the problem, but it seems the device has issues when being reset on my chipset. I can also notice this that in 2 out of 3 attempts if I reboot the PC the disk is not recognized any more before I reboot again.

Despite these issues, the SSD now runs with astonishing performance with the suggested 32 head / 32 sector alignment, and a 512kB partition alignment scheme. After an initial TRIM with hdparm‘s wiper.sh I enabled -o discard for my ext4 partition and could also verify using hdparm that this results in the sectors being trimmed. Please note, that you need to manually compile and install the latest hdparm version on Ubuntu 10.10, as the included version fails with the very long free block list and doesn’t handle splitting the sectors in multiple requests. The latest version doesn’t have this issue any more.

How to force Git to consider a file as binary

If you are using Git on Windows and follow my advise on how to get past the problem with the “suspicious patch lines”, you might run into problems if you are using Encapsulated PostScript (.eps) files in your repository.

PostScript files are almost plain-text files, and if you set core.autocrlf and core.safecrlf, they might cause problems with the EPS binary encoded parts, as they might be detected as text-files and therefore remove any CRLF and replace it with single LF, which can mess up the whole image.

To force Git to consider a file binary which it would consider as text-file otherwise, the easiest way is to add a .gitattributes file to the directory containing the file or to any parent directory. In my case, I normally add a .gitattributes file in the root of the repository, containing

*.eps -text -diff
*.jpg -text -diff
*.png -text -diff

In the file you set attributes to a path (or a pattern), or unset them (with the minus sign).  The text attribute is the attribute which tells that end-of-line normalization should be applied to a file. If you unset it, Git won’t mess with the line endings in the file and consider it binary.

More details can be found on the gitattributes man page.

Missing dictionaries on OpenOffice.org 3

I just upgraded to OpenOffice.org 3 and I really like it. But there was a small, but very anoying problem: OO.org seemed to be unable to find any dictionaries. I found out rather quicky, that starting with OO.org 3 dictionaries are only available as extensions. Well, basically this is no problem, but the English (at least the US and GB variante) are supposed to be bundled with the installer and are not available as seperate extension.

It seems there is a little bug with the installation on Vista under certain circumstances which causes the extensions not being registered properly with OO.org.

To solve the problem, follow the same following steps:

  • Locate your OO.org “install” directory of your installation, usually it is C:\Program Files\OpenOffice.org 3\share\extensions\install” [Updated 2008-12-21 to include “extensions”, thanks to the anonymous commenter!]
  • Manuylla install the appropriate dictionary extension (“dict-en.oxt”, “dict-de.oxt”, “dict-fr.oxt”, “dict-it.oxt”) by either launching the oxt directly or by chosing Tools -> Extension Manager.

For me this worked after restarting OO.org totally (i.e. closing down all Writer, Calc, …).

git-svn fails with fatal error: unable to remap

Git‘s nice Subversion (SVN) integration is one of the reasons I switched to using it within our company for my own revision control besides our official repository. Unfortunately, upgrading cygwin broke my system once again:

$ git svn dcommit
6 [main] perl 4760 C:\cygwin\bin\perl.exe: *** fatal error - unable to remap C:\cygwin\lib\perl5\site_perl\5.8\cygwin\auto\SVN\_Core\_ Core.dll to same address as parent(0x260000) != 0x990000 84 [main] perl 3224 fork: child 4760 - died waiting for dll loading, errno 11 panic: MUTEX_LOCK (45) [util.c:2331] at /usr/bin/git-svn line 787. panic: MUTEX_LOCK (45) [op.c:352].

The reason behind this behavior is a huge difference in the way processes and threads and libraries are created/handled on Windows and Linux. git-svn relies on perl within cygwin and several perl libraries that use the same base-address for libraries internally. Of course, no two libraries can be loaded to the same base-address at the same time.

Long explanation, short way to fix the problem:

  1. Quit all cygwin processes
  2. Start ash (<cygroot>\bin\ash.exe) (<edit>Use “Run as Administrator…”</edit>)
  3. Execute /usr/bin/rebaseall

Voilla, that’s all. git-svn should work again.

Vista UAC: Firefox (and other Mozilla apps) automatic updates

If you disable the automatic installer detection of User Account Control (UAC), for instance because it interferes with your every-day operations (like in my “Git and Windows Vista” article), you will notice that the Mozilla updaters don’t work as expected. Automatic updates will fail. This is due to the fact that the updater will not be automatically elevated any longer.

As the easiest workaround, you should perform the following steps:

  • Once you get notified about the update and you are asked if you want to install it, say “No”.
  • Close the Mozilla application in question.
  • Search for the application in your “Start” menu.
  • Right-click the entry and choose “Run as Administrator…”
  • Choose “Check for Updates…” in the “Help” menu
  • Confirm you want to install the update and walk through the update process.

The installation will now work. For security reasons you should close the application once installation is finished, because it will still be running with elevated privileges. Now start the application again normally.

The same principle works for any application that is not Vista-aware and fails on automatic update. For security reasons make sure you keep the time you run with elevated privileges as short as possible.

git-svn on Windows (cygwin)

Update 2008-10-10: Often perl will not work due to memory-remapping problems. A solution can be found in my article about the issue.

What I really love about Git is the fact that it nicely integrates with existing Subversion repositories. At our company, we are using Subversion as our SCM, but I personally like Git more and I want to use it as a side tool for more flexible branching, merging, and for checking in versions I wouldn’t check in the shared repository.

Git is supplied with git-svn, which can import an existing SVN repository and also commit back to it. Under cygwin, you need to perform two additional steps for getting git-svn to work, otherwise it is likely to fail with “failed to include Error.pm”.

You need to download Error.pm from CPAN. You have to save it to <cygwin-dir>\lib\perl5\Error.pm

Voila! git-svn should work now.

Git on Windows: “You have some suspicious patch lines”

Update 2008-04-24: as commenter Jakub Narebski correctly points out, it should be better to use core.autocrlf and crlf attribute for resolving this issue, but I have had no chance to test this up to now. The solution below is still valid, but more of the sort of an ugly hack.
Update 2008-06-11: I have stopped using this solution and only use “git-config core.autocrlf true” and “git-config core.safecrlf true” any more. It works reliably and is exactly what I need and not such an ugly hack.
Update 2008-06-22: Well, of course you can still get “You have some suspicious patch lines” if you follow the core.autocrlf approach… but this time it really means you have trailing whitespace, not just line-breaks. If you really don’t care about trailing white-space at all, my initial solution is still valid, as it simply disables this check.

If you are using Git under Windows using cygwin, and you got through the initial problems, you will soon realize that Git likes to fail with “You have some suspicious patch lines” when committing.

The cause for this problem is the carriage-return/line-feed problem of Git under Windows/cygwin: The patches contain a trailing line-feed if you edited them with a Windows editor and not strictly inside cygwin. This will trigger the pre-commit hook to fail on patches where the last line of a file has been changed.

To solve the problem, you need to edit .git/hooks/pre-commit and comment out the following lines:

if (/\s$/) {
bad_line("trailing whitespace", $_);
}

Now committing should work.

Git and Windows Vista

I recently started using Git, the version control system now used for developing the Linux Kernel. While there is no native support for Windows at the moment, you can install it using cygwin. While this works reasonably well in Windows XP, I got into severe troubles when trying the same in Windows Vista.

First, I ran into troubles installing cygwin. I figured out, that it seems to work well if you run both the installer and bash in “Windows XP SP2 compatibility mode”. I needed to adjust the file system permissions of the cygwin folder to give me write permissions, though. (Note: you have to manually install the TK-libs if you want the GUI elements of git to work.)

But Git kept failing with “access denied” messages when trying to commit from command line. The failure message said it was denied access to git-update-index. I soon found out this is due to the “User Account Control” (UAC) default behavior of auto-detecting installers and prompting if you want to execute them with raised privileges. You can see if this is the case by running git-update-index manually from bash; if you get the UAC confirmation dialog you have this problem. It seems the substring “update” triggers this behavior. As the git-update-index is launched by git commit, it won’t display the confirmation dialog of Vista, so the execution will be denied.

There are two possible workarounds:

  • Run bash with administrative privileges (not recommended!)
  • Disable the auto-detection of installers by UAC.

I used the latter way. You can disable the auto-detection by following these instructions. Brief summary:

  • Open the Local Security Policies
  • Disable “User Account Control: Detect application installations and prompt for elevation”
  • Reboot (the security policy will not be updated before!)

It should work now. You can confirm this by running git-update-index manually again. If you do not get the UAC confirmation dialog now, it worked. Try git commit now, and verify it is working. Of course, you will from now on have to right-click and “Run as Administrator” every installer you want to install, as most installers will require administrative privileges.

Update 2007-08-22: Reader EGarcia posted an interesting comment below: using the Microsoft Manifest Tool you can add an according manifest to the git-update-index.exe and git-update-ref.exe

Update 2009-02-12: Reader Kevin Broadey points out the best solution so far: create a seperate .manifest file for the affected files. He has provided an example for git-update.exe.manifest.

OpenVPN and Tap-Win32-Adapter Problem

OpenVPN on Microsoft Windows has a problem with the TAP-Win32-Adapter driver used for the tunnel. The device needs to be deactivated/reactivated after a Windows restart before any connection can be established. In this article I present a very simple script and solution for automating this process.

Continue reading “OpenVPN and Tap-Win32-Adapter Problem”