Recently I had a bad memory module in my main storage system which is also the backup target of many of my systems. To be on the safe side, I validated all backed up files against their origin via checksums. Interestingly, multiple systems showed differing checksums for all DejaVu font files, i.e. the files in the backup did not match those in the system. Clearly, this was not caused by the bad memory module. It looked very much like a systematic issue.Read More
Tinkering with the StarFive VisionFive 2
With RISC-V getting more and more attention, I was curious and got myself a StarFive VisionFive 2, a single board computer equipped with a SiFive JH7110 SoC which implements the RV64GC ISA. While the performance is not on par with ARM SBCs yet, the overall experience has been quite good so far. In this article, I share some of my experiences with it.Read More
Stuck UART on the ZedBoard
Recently I grabbed my trusted old Avnet / Digilent ZedBoard to test how well the current Xilinx tools work with this now a decade old platform. However, I was facing a weird issue: The serial output by the Zynq PL was only received via USB on my computer when I was sending characters via UART from my computer to the PL as well. As soon as there was a pause in communication, any further serial output by the PL was silently dropped.Read More
Making Touchpads with Builtin Windows Gestures Less Annoying on Raspberry Pi OS
I use a Bluetooth keyboard with included touchpad to control a Raspberry Pi 4. To be specific, I use the Keysonic KSK-5220BT by RaidSonic. One thing that annoys me for some time now is: Whenever I touch the touchpad at the very edge, the LXDE menu will open and the cursor won’t move.
The reason is that the touchpad supports Windows swipe gestures. For whatever reason these gestures are (at least with this touchpad) not recognized in software but in hardware and are translated as follows:
- Swipe from right edge > Windows + A
- Swipe from bottom edge > Windows + B
- Swipe from left edge > Windows + Tab
- Swipe from top edge > Windows + Down
Raspberry Pi OS (formerly Raspbian) has a large set of key binding preconfigured in /etc/xdg/openbox/lxde-pi-rc.xml. In particular, every press of the Windows / Super key will open the application menu. So each of these swipe gestures will open the menu and issue an additional key press (A / B / Tab / Down).
A workaround is to edit that file and replace
<keybind key="Super_L"> <action name="Execute"> <command>lxpanelctl menu</command> </action> </keybind>
<keybind key="W-a"> <action name="Execute"> <command>true</command> </action> </keybind> <keybind key="W-b"> <action name="Execute"> <command>true</command> </action> </keybind> <keybind key="W-Down"> <action name="Execute"> <command>true</command> </action> </keybind> <keybind key="W-Tab"> <action name="Execute"> <command>true</command> </action> </keybind>
With this modification, the cursor still won’t move when touching the edge of the touchpad. But at least no action is triggered and no key press is issued. But be aware that an update of the raspberrypi-ui-mods package might overwrite these changes.
Update Mar 11, 2023:
In 2021 Raspberry Pi OS updated to Debian Bullseye as a foundation. Additionally, they changed the default window manager from Openbox to Mutter on all devices with more than 2 GiB of memory. For Mutter, the procedure for disabling the annoying key bindings is slightly different:
- Disable Mutters key binding for the Windows / Super key:
gsettings set org.gnome.mutter.keybindings lxpanel-menu ""
- Install xbindkeys:
apt install xbindkeys
- Create a file called .xbindkeysrc in your home directory with the following content:
"true" Super_L a "true" Super_L b "true" Super_L Tab "true" Super_L Down
- Manually start xbindkeys or logout and login again.
Figuring out the used space_cache version of a btrfs file system
Btrfs contains different implementations of a free space cache. The default currently is
space_cache=v1. A newer tree-based cache can be activated by the mount option
space_cache=v2. As soon as the new version has been used once, it will automatically be used for any future mount. But how do you figure out which version your file system is actually using?
There are multiple ways to determine the used space cache version. The easiest one is to just mount the file system and look into the kernel log. If the default space cache v1 is used, it will say something like
BTRFS info (device yourdevice): disk space caching is enabled
However, if it already has been configured to use the new space cache v2, it will say something like
BTRFS info (device yourdevice): using free space tree
One can also determine the used space cache version without mounting the file system by peeking into the superblock:
btrfs inspect-internal dump-super /dev/yourdev
If the file system already uses
compat_ro_flags will contain the flag
For completeness: When playing with
space_cache=v2, be aware of the risks (see the remarks on the space_cache mount option in btrfs(5)).
Risks of nginx fastcgi buffering or, how iTunes can mess with your Nextcloud server
As suggested by the title, this post consists of two parts. The first part will explain how nginx fastcgi buffering can be exploited relatively easily to fill up a servers hard drive. The second part will tell you how I had to learn this the hard way…Read More
Prevent autostart of Android File Transfer on macOS
Android File Transfer (let’s call it AFT) is a handy tool to transfer files from and to an Android device when using a Mac. This software has an annoying habit though: It automatically starts when an Android device is plugged in. Since on most modern Android devices, the user has to give permission to access files after connecting it to a PC, it opens up just to confront the user with an error message.
Debugging a flaky cpu steal time counter on a paravirtualized Xen guest
I recently noticed a strange phenomenon on a Debian Stretch server running as a paravirtualized guest on a Xen host: top showed the CPU either be 100% idle or 100% stolen. User, system, nice and waiting times were stuck at 0%. I cross-checked with vmstat and it showed 0% for all cpu time counters. Both tools are getting their information from /proc/stat which looked like the following:
cpu 5322 0 4376 12720669 37879 0 59 1198368772563 0 0 cpu0 5322 0 4376 12720669 37879 0 59 1198368772563 0 0 ...
The third to last value is the steal time, denoting “stolen time, which is the time spent in other operating systems when running in a virtualized environment” [procfs(5)]. This value looked way too high and, in particular, it was counting backwards. So, if I wanted to put this system into production, some debugging was required before…
Pitfalls when running a mail server
When running a mail server, some basic rules have to be followed, e.g. ensuring that the server does not operate as an open relay. These rules are nowadays well known and the default configuration provided with MTA software typically avoids these “big no-nos”. Still, there are many pitfalls when configuring a mail server. In this post I want to share some of those pitfalls that I stumbled across in the last years myself.
Migrating from ownCloud 9.1.6 to Nextcloud 10
If you are stuck with PHP 5.4 (e.g. because you are still running Debian Wheezy) and want to migrate from ownCloud to Nextcloud, you are probably facing a minor issue. Nextcloud 11 and newer require PHP 5.6 so you have to stick to version 10 instead. Nextcloud 10 reached its end-of-life with version 10.0.5, which internally corresponds to ownCloud version 9.1.5. The most recent version of ownCloud 9 is version 9.1.6 though, so when trying to migrate to Nextcloud you will face the following error:
Downgrading is not supported and is likely to cause unpredictable issues (from 126.96.36.199 to 188.8.131.52)
Looking at the git commits between ownCloud 9.1.5 and 9.1.6 shows that there were no changes to the database layout. So, as a workaround, you can just edit your config/config.php and set version to 184.108.40.206 or lower. Afterwards, you should be able to run the normal upgrade procedure.