Last year I stumbled across a problem with the execution of a Docker container in a CI environment. The interesting case was that this is a container for a foreign architecture, which is supported by the --platform option and there are even official images on Docker Hub for this.
Initially, the problem presented itself like this:
$ docker run -it --rm --platform linux/arm64 [...] arm64v8/ubuntu:jammy
Error, do this: mount -t proc proc /proc
This means the ps(1) command could not run in this Docker container. At first I trusted the error message and thought that /proc might really not be mounted. However, that is usually taken care of by Docker and this following check confirmed that it is in fact mounted:
root@d6fb5c478cb6:/# mount | grep proc | head -n1
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
Well, now what is actually the problem here with running a Docker container for a foreign architecture?
I recently started to manage my passwords with the pass(1) password store. I integrated access into Firefox via passff and also found a nice GUI with QtPass. While this works nicely, in places outside the browser, it was still quite cumbersome for me to enter passwords. I was still required to open a terminal window to run pass or use the QtPass GUI to copy and paste the password.
I had seen others using passmenu together with dmenu to copy or insert a password anywhere. That seemed very elegant, as it could be used everywhere.
However, I prefer to use tools that are less minimalistic. For years, my Linux desktop has been LXDE with the Openbox window manager. I discovered that it is possible to write dynamic menu for Openbox, which seemed like a perfect fit for this task.
The result is now openbox-passmenu, a script that provides a menu for Openbox to access the passwords inside the pass(1) password store.
If you also want to use this, please head over to the GitHub project for instructions on how to install and where it has to be integrated with the Openbox configuration.
Already in September 2017 I migrated away from Sailfish OS and I am now using an Android phone. For me, this is the first time I left the niche market of alternative phone operating systems to go mainstream. Originally I used a Nokia dumb phone and then in 2009 got the Nokia N900 as my first smartphone with Maemo as OS, which was so much joy, easily extensible due to the open platform, and had a sliding keyboard. After a few years I continued with the Nokia N9 with the now abandoned Meego. The N9 was released shortly before the Nokia phone department was switched to produce Windows phones for Microsoft. However, a group of former Nokia developers formed Jolla, a company producing an alternative phone operating system called SailfishOS.
Lately, I had some problems with stalling transfers when using scp, the file transfer tool for the SSH protocol and part of the OpenSSH suite. Here is a report on what happened, how I found the cause and how I applied the solution. Actually, this is a pretty lame story, but I just wanted to write it down anyway.
After the upgrade to Linux kernel 2.6.38, the boot process for my machine hang quite long while Populating /dev with existing devices through uevents. After investigations it turns out that the cx88 driver used for my Hauppauge WinTV HVR-1300 tv card was not correctly converted to the new mutex system while removing the BKL. This is being tracked in the kernel bugzilla as bug #31962.
Fortunately, there is a patch attached to the mentioned bug report which resolves the problem:
wget -O cx88-2.6.38-fix-driver-deadlocks.patch 'https://bugzilla.kernel.org/attachment.cgi?id=53722'
patch -p1 < cx88-2.6.38-fix-driver-deadlocks.patch
[Edited on 2011-04-23: replaced patch 52902 with 53722]
After applying the patch, build and install your kernel as usual. But there are still some more problems with 2.6.38 related to tvtime. See also my next post.
I do not follow kernel development close enough to know in which git tree this has to show up to confirm if it has been merged yet. Hopefully this patch will make it into the next kernel release.