Month: September 2020

Laggy mouse on a Raspberry Pi?

If you have a Raspberry Pi and find the mouse to be laggy (as if it’s under water) here’s two things you can try:

  1. Open /boot/cmdline.txt and see if the line in there has many mention of usbhid.mousepoll. If it has then try changing its value to 8 (or 2, 4, or 8). Then reboot.
    1. This key controls how often the mouse is polled. You can read about it in this wiki page. This made a huge difference to me. I’d suggest starting with 8 and reducing if you are not happy with the result. The lower the number the more often the mouse is polled, which results in higher CPU usage. If 8 works well then why stress the system further.
  2. Reduce the screen resolution. Since the Raspberry Pi 4B can drive 2x 4k monitors that’s what I started off with initially. Sure it can drive ’em but there is a lag. Then I switched to a single 4k display but it was still meh. Finally I reduced the resolution from the default 3840×2160 to 2560×1440 to 1920×1080. The last one made a noticeable difference to the mouse performance and also generally to the display. (I even went with 1600×900 but didn’t stick with it as I wanted a slightly higher resolution).

[TIL] WMI filtering has separate precedence with GPOs

I knew that when it comes to a bunch of GPOs linked to an OU the one with the lowest number (highest in the list) has the highest priority.

What I learnt today is that if in this list you have a GPO that’s got a higher number (i.e. low priority and would typically be over-ridden by another one higher in the list) if it is scoped to a WMI filter then it is in a separate queue of its own and processed after all the other GPOs are processed. Thus, this GPO which would typically be over-ridden will apply above all others in the specific WMI filter scope it is applied to.

Wireguard Search Domain

It’s not obvious but in the Wireguard config file one can also specify the DNS search domains. From the man-page:

DNS — a comma-separated list of IP (v4 or v6) addresses to be set as the interface’s DNS servers, or non-IP hostnames to be set as the interface’s DNS search domains. May be specified multiple times. Upon bringing the interface up, this runs ‘resolvconf -a tun.INTERFACE -m 0 -x‘ and upon bringing it down, this runs ‘resolvconf -d tun.INTERFACE‘. If these particular invocations of resolvconf(8) are undesirable, the PostUp and PostDown keys below may be used instead.

Thus you could have the following line:

On an unrelated note (but related in terms of what I was doing, so I might as well put it here) the excellent NextDNS CLI when it activates only changes the nameserver to localhost in /etc/resolv.conf but leaves the search domains as it is. So typically you’d set your /etc/resolv.conf the way you want, then activate NextDNS and it will replace the nameserver. In my edge case however, I had both Wireguard and NextDNS CLI running, and Wireguard was by default only setting the nameserver and not search domain (until I fixed it as above). This resulted in NextDNS not adding any search domain in /etc/resolv.conf and I spent a heck of a lotta time trying to figure out why. 

[TIL] Docker –dns may not behave like you expect

I always thought the --dns option in docker run or docker start etc. always set the DNS servers to what you specify there. It does, but there is a caveat. If you are using a custom network (e.g. a macvlan network like I tend to do) then this option is ignored when you attach the VM to that network. In such cases the DNS server within the VM is set to 127.0.0.11 which is Docker’s embedded DNS that forwards requests to the external servers on the host. Bit me in the a$$ yesterday and thanks to this gitHub issue I am now the wiser. 

Failed to Shellify error in cloud-init

Had the following code in a cloud-init config:

During cloud-init it gave me a “Failed to Shellify” error in /var/log/cloud-init.log and one of the messages just above it was the following:

runcmd.9: {‘RUNNERTOKEN=$(curl -s -XPOST -H “authorization’: ‘token _REPLACETOKEN_” https://api.github.com/repos/_REPLACEREPO_/actions/runners/registration-token | jq -r .token)’} is not valid under any of the given schemas

Thanks to a StackOverflow post I realised my error. I was typing in commands under the runcmd section as if it were a Bash script or something like a Dockerfile but obviously that’s not the case. From the docs you can see the following:

So it either expects something along the line of the ENTRYPOINT  and CMD lines in a Dockerfile – a list of an executable and its arguments – or just a string that it can pass to the shell for execution. All I had to thus do was put the erroneous line in single quotes and the next time cloud-init had no complaints. Yay!

Also, it’s not so obvious from the docs but you can use shell variables in a cloud-init file as all the commands run in a single shell instance that keeps variables between each command. Consider the following:

I am able to assign a shell variable RUNNERTOKEN in the first line and use it in the second line.