I wanted to prevent clients to see my home server's list of NFS shares, so I disabled its nfs-mountd.service because it is only needed for NFSv3:
- rpc.mountd
- This process is used by an NFS server to process MOUNT requests from NFSv3 clients. It checks that the requested NFS share is currently exported by the NFS server, and that the client is allowed to access it. If the mount request is allowed, the nfs-mountd service replies with a Success status and provides the File-Handle for this NFS share back to the NFS client.
And indeed, no share list was visible anymore:
$ showmount -e dojo
clnt_create: RPC: Program not registered
But this had consequences, although I tried to use NFSv4 only:
$ cat /etc/fstab | grep media-dojo
dojo:/data/media /mnt/media-dojo nfs noauto,user,nolock,nfsvers=4
$ mount -v /mnt/media-dojo/
mount.nfs: timeout set for Thu Dec 21 21:20:46 2023
mount.nfs: trying text-based options 'nolock,vers=4.2,addr=fdc3:e153::3,clientaddr=fdc3:e153::dcbb:9cea:9873:1f10'
mount.nfs: mount(2): Connection refused
mount.nfs: trying text-based options 'nolock,vers=4.2,addr=192.168.3.3,clientaddr=192.168.3.5'
mount.nfs: mount(2): Connection refused
mount.nfs: trying text-based options 'nolock,vers=4.2,addr=fdc3:e153::3,clientaddr=fdc3:e153::dcbb:9cea:9873:1f10'
mount.nfs: mount(2): Connection refused
mount.nfs: trying text-based options 'nolock,vers=4.2,addr=192.168.3.3,clientaddr=192.168.3.5'
mount.nfs: mount(2): Connection refused
I could not mount the shares from my Debian experimental (trixie) laptop anymore! After re-enabling nfs-mountd on the home server I could mount again:
$ mount -v /mnt/media-dojo/
mount.nfs: timeout set for Thu Dec 21 21:20:54 2023
mount.nfs: trying text-based options 'nolock,vers=4.2,addr=fdc3:e153::3,clientaddr=fdc3:e153::dcbb:9cea:9873:1f10'
mount.nfs: mount(2): Permission denied
mount.nfs: trying text-based options 'nolock,vers=4.2,addr=192.168.3.3,clientaddr=192.168.3.5'
$
A comment on severfault.com explains it:
According to rpc.mountd(1),
"The rpc.mountd daemon implements the server side of the NFS MOUNT protocol, [...] It also responds to requests from the Linux kernel to authenticate clients and provides details of access permissions."
... so it's not needed on an NFSv4 client, but an NFSv4 server still needs it, even though there's no direct communication between clients and rpc.mountd.
Sam Morris, 2023-12-16
So I have to keep nfs-mountd running on the server, but I can deny access from the outside:
mountd: ALL
Listing mounts is not possible anymore, but mounting is:
$ showmount -e dojo rpc mount export: RPC: Authentication error; why = Failed (unspecified error)
My new home server mounts some NFS shares from the NAS. When electricity is restored after an outage, both NAS and home server boot up at the same time. The new home server is much faster than my rusty NAS, and so services depending on NFS mount data would start too early, possibly removing data from their database (e.g. Gerbera or paperless-ngx).
To not run into that problem I added a systemd service that waits for the NAS to be available before trying to mount the NFS shares.
At first a service that waits for the NAS ("disa", short for DiskStation) to be reachable ping:
[Unit]
Description=Blocks until it successfully pings disa 192.168.3.96
After=network-online.target
[Service]
ExecStartPre=/usr/bin/bash -c "while ! ping -c1 192.168.3.96; do sleep 1; done"
ExecStart=/usr/bin/sh -c "echo good to go"
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
This has to be enabled with
$ systemctl daemon-reload
$ systemctl enable wait-for-disa
Now the NFS mounts are configured to wait for that service to become available:
disa:/volume2/media /mnt/media-disa nfs x-systemd.after=wait-for-disa.service,timeo=50
A systemctl daemon-reload and all is set.
When moving to a new home server I also needed to connect my Brother ADS-1700W document scanner to the new Debian 12-based machine, which turned out to be harder than I expected.
Upon pressing a button on the UI, the scanner shall upload the PDFs to the paperless-ngx instance on my home server. The ADS-1700W supports SFTP uploads that can be configured via the web interface.
Until all problems were solved, the "connection test" showed the following (German) error message:
Profil 1 (SFTP)
Test: Fehler
Authentifizierungsfehler.
Diese Meldung wird angezeigt, wenn Ihre Authentifizierungseinstellungen nicht ordnungsgemäß konfiguriert sind.
Prüfen Sie Folgendes:
* Benutzername ist korrekt.
* Kennwort ist korrekt. (Wenn Kennwort als Auth.-Methode ausgewählt ist.)
* Ausgewähltes Client-Schlüsselpaar ist korrekt. (Wenn Client-Schlüssel als Auth.-Methode ausgewählt ist.)
* Ausgewählter öffentlicher Serverschlüssel ist korrekt.
Each SFTP Profile has a Server Public Key which needs to be uploaded at first. I used the following file from my server: /etc/ssh/ssh_rsa_host_key.pub.
Using ssh_host_ed25519_key.pub did not work; the scanner firmware did not accept the key file. (The RSA file gave an error at first, but was accepted when uploading it a second time.)
The scanner was not able to connect to my server with that host key though. journalctl showed:
sshd[6275]: Unable to negotiate with 192.168.3.53 port 59954: no matching host key type found. Their offer: ssh-rsa [preauth]
Debian 12 by default does not like RSA keys anymore and prefers different key types, so I had to allow RSA:
HostKeyAlgorithms +ssh-rsa
Test connections from my laptop to the restricted "scanner-upload" account with scp did not work at first:
$ scp -v empty.ini scanner-upload@paperless.home.cweiske.de:/ Executing: program /usr/bin/ssh host paperless.home.cweiske.de, user scanner-upload, command sftp [...] debug1: Sending subsystem: sftp [...] Transferred: sent 4336, received 3568 bytes, in 0.3 seconds Bytes per second: sent 13255.8, received 10907.9 debug1: Exit status 1 scp: Connection closed
There was no indication in the server logs, even when setting LogLevel VERBOSE.
A CentOS forum post by edwardsmarkf gave me a solution: Change the SFTP subsystem from /usr/libexec/openssh/sftp-server to internal-sftp.
Subsystem sftp internal-sftp
With this two configuration changes the scanner could upload files!
On my Debian 12 based home server I wanted to set the CPU frequency scaling governor to "powersave" upon boot. The cpupower package does not have a default configuration that is applied on startup, so I had to do this myself.
With systemd 252.17-1~deb12u1 I had to do the following:
[Unit]
Description=Configure kernel to use "powersave" cpu scaling governor
[Service]
Type=oneshot
ExecStart=cpupower frequency-set -g powersave
[Install]
WantedBy=multi-user.target
Then I only had to enable it:
$ systemctl enable cpupower-config.service
Ich habe Bankkonten bei der Volksbank, und die von der Fiducia generierten elektronischen Kontoauszüge (PDF-Dateien) waren unter Linux (Debian+Ubuntu) absolut unleserlich:
Das ist 2013 schon anderen Leuten aufgefallen. 2021 war es aber immer noch so, und ich wollte das Problem endgültig lösen.
Unter Linux mit dem PDF-Anzeiger Evince und Atril kam es zu dem Problem - unter Android mit mupdf allerdings nicht. Das legte den Verdacht nah, daß es sich hier um einen Bug oder ein fehlendes Feature in der Software handelt.
Die Texte in den PDF-Dateien nutzen mehrere Schriftarten mit den Namen "RFont0" bis "RFont6", die allerdings nicht eingebettet sind. Einige davon sind "normale" Schriften und andere haben eine feste Breite - aber in jeder PDF-Datei ist das anders. In einer Datei ist RFont1 die Festbreitenschriftart, in der nächsten ist es RFont2. Eine feste Schriftkonfiguration ist deshalb nicht möglich.
Warum funktioniert es aber mit anderen PDF-Anzeigeprogrammen?
Ich habe mir eine Kontoauszugsdatei mal mit qpdf -decrypt -qdf 2021-90003.pdf -|less genauer angeschaut:
> endobj]]>
Das ist die Schriftdefinition für einen Text, der mit fester Schriftbreite
dargestellt werden sollte.
Die
PDF-Spezifikation 1.7
listet in Abschnitt 9.8.2 Font Descriptor Flags
die Table 123 – Font flags
auf.
Das erste Bit ist FixedPitch
.
Wenn es gesetzt ist, dann hat die Schriftart eine feste Breite.
Hier bei /Flags 33 ist das erste Bit gesetzt. Das bedeutet, daß der PDF-Anzeiger auch bei einer nicht vorhandenen Schriftart wie RFont0 eine monospace-Ersatzschriftart nutzen könnte - es aber nicht tut.
Sowohl Evince als auch Atril nutzen die Bibliothek Poppler zur Darstellung. Ich vermutete, daß dort das Problem liegen würde.
poppler stellt das Kommandozeilenprogramm pdffonts bereit, mit dem man sehen kann, welche Schriften im PDF gefordert, und vor allem welche dann wirklich auf dem System genutzt werden:
$ pdffonts -subst 2021-90003.pdf name object ID substitute font substitute font file ------------ --------- ----------------- ------------------------------------ RFont0 12 0 DejaVu Sans /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf RFont1 13 0 DejaVu Sans /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf RFont2,Bold 14 0 DejaVu Sans Bold /usr/share/fonts/truetype/dejavu/DejaVuSans-Bold.ttf RFont3 15 0 DejaVu Sans /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf RFont4 19 0 DejaVu Sans /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
Hier wird für RFont0 also eine nicht-festbreitenschrift genutzt.
Die Auswahl der Schriftarten wird unter Linux generell von fontconfig gemacht. Ein Programm fragt fontconfig nach einer Schrift ("Comic Sans"), oder sagt grob was es haben möchte ("fette Serifenschrift mit kyrillischen Buchstaben"), und fontconfig gibt die passende Schriftart zurück.
poppler fragt also nicht nach einer Monospace-Font, sondern nach einer normalen - obwohl die Unterstützung für das fixed-width-Flag schon 2012 eingebaut wurde.
Ich habe also einen Bug aufgemacht und 5 Stunden später war er behoben!
poppler Version 21.11.0 hat damit keinen Fehler mehr, allerdings kam jetzt ein zweiter zum Vorschein.
poppler fragt fontconfig nach der Schrift RFont0 und weist gleich mit darauf hin, daß es eine Festbreitenschrift ist. fontconfig ignoriert den Hinweis aber und gibt die Standardschrift zurück:
$ fc-match RFont3:spacing=mono DejaVuSans.ttf: "DejaVu Sans" "Book"
Glücklicherweise kann man das konfigurieren:
100
monospace
]]>
Ein Leser schrieb, daß er den Dateinamen auf 01-cweiske-monospace.conf ändern musste, damit das ganze funktioniert.
Jetzt noch den Cache aktualisieren und es kommt die richtige Schrift zurück:
$ fc-cache -f -v
$ fc-match RFont3:spacing=mono
VeraMono.ttf: "Bitstream Vera Sans Mono" "Roman"
Ich hatte mehrere Male auf der Mailingliste nach diesem Problem gefragt, wurde aber größtenteils ignoriert. Deshalb öffnete ich einen Fehlerreport und es stellte sich heraus, daß genau dieses Problem schon vor einem halben Jahr mit Version 2.13.95 gelöst worden war.
Mit poppler 21.11.0 und fontconfig 2.13.95 werden die Kontoauszüge endlich korrekt angezeigt.
In Debian ist poppler 21.11.0 aktuell nur in der "experimental"-Distribution, bei Ubuntu in "jammy" (22.04 LTS).
fontconfig 2.13.95 ist aktuell weder in Debian experimental noch Ubuntu 22.04 (jammy) zu finden. Da bleibt nur das manuelle Anlegen der Konfigurationsdatei.
I have some old Playstation 1 controllers that I'd like to use on my OUYA gaming console. Using them on the PC works via an PSX-to-USB adapter.
Plugging them into the OUYA unfortunately did not work; they were not detected as controllers - or at all, as it seemed. A Microsoft Sidewinder DualStrike did also not work.
Attaching the PSX adapter with controllers to a PC shows the following lsusb output:
ID 0810:0001 Personal Communication Systems, Inc. Dual PSX Adaptor
dmesg shows:
usb 2-1.2: new low-speed USB device number 120 using ehci-pci usb 2-1.2: New USB device found, idVendor=0810, idProduct=0001 usb 2-1.2: New USB device strings: Mfr=0, Product=2, SerialNumber=0 usb 2-1.2: Product: Twin USB Joystick input: Twin USB Joystick as /devices/pci0000:00/0000:00:1d.7/usb2/2-1/2-1.2/2-1.2:1.0/input/input1460 input: Twin USB Joystick as /devices/pci0000:00/0000:00:1d.7/usb2/2-1/2-1.2/2-1.2:1.0/input/input1461 pantherlord 0003:0810:0001.05AC: input,hidraw2: USB HID v1.10 Joystick [Twin USB Joystick] on usb-0000:00:1d.7-1.2/input0 pantherlord 0003:0810:0001.05AC: Force feedback for PantherLord/GreenAsia devices by Anssi Hannula <anssi.hannula@gmail.com>
Input device files in /dev/input/ get created for both joysticks; /dev/input/js0 and /dev/input/js1.
I can then use jstest or jstest-gtk to test the controllers and see all the buttons and axes working.
Using adb to open a shell on the OUYA gives the following dmesg output:
[ 331.002934] usb 2-1: new low speed USB device number 13 using tegra-ehci <6>[ 331.039183] usb 2-1: New USB device found, idVendor=0810, idProduct=0001 <6>[ 331.046013] usb 2-1: New USB device strings: Mfr=0, Product=2, SerialNumber=0 <6>[ 331.053437] usb 2-1: Product: Twin USB Joystick]]>
That was all. Nothing more - no more dmesg output, no input files in /dev/.
On the internet, many people used apps like usb/bt joystick center or tincore keymapper. The first has been removed from the google play store (I did not find an explanation why; the author did not respond to my e-mail), the second is still available.
But I did not want to use any of these tools. I can't look into them and do not know what they do. There just had to be a way to make it work properly.
After some detours, I had the idea that Linux drivers could be missing.
The PC's dmesg output gave a hint which ones were used:
pantherlord 0003:0810:0001.05AC: input,hidraw2: USB HID v1.10 Joystick
The keywords are pantherlord, input and hidraw2.
input is a standard kernel module that is always enabled; otherwise no mouse/keyboard/joystick/touchpad would work.
pantherlord turned out to be the driver for the PSX adapter. The kernel sources tell us in drivers/hid/Kconfig:
config HID_PANTHERLORD tristate "Pantherlord/GreenAsia game controller" depends on USB_HID ---help--- Say Y here if you have a PantherLord/GreenAsia based game controller or adapter.
There is also a HIDRAW driver, which supports
HID devices (from the USB specification standpoint) that aren't strictly user interface devices
One can access the current kernel configuration at /proc/config.gz by copying from the OUYA:
$ adb pull /proc/config.gz $ zless config.gz
And there I saw it:
# CONFIG_HIDRAW is not set # CONFIG_HID_PANTHERLORD is not set # CONFIG_HID_MICROSOFT is not set
The OUYA's Linux kernel had been built without support for my game controllers.
So it turned out that the only way to get my arcade joystick and gamepad working was to compile support for them into the kernel.
While HID_PANTHERLORD could be compiled as a module (tristate in the Kconfig files), HIDRAW could not - I had to re-build the whole kernel, and not only compile & copy a single module.
The internet contained a single, but very helpful OUYA kernel compilation howto: Builing your own Ouya Kernel by Leonardo Pires, written mid of 2014. The original announcement of this HowTo seems to be Recompilando Kernel do OUYA - Por Leonardo Pires which links to a HowTo on Google Drive. The XDA forum post seems to be a low-quality and translated version of it.
I had to adjust it to the current OUYA firmware version and fix some errors in it. Here is the updated one that worked 2015-06-02:
You have to enable ADB via the OUYA System / Debugging menu.
For the last step you have to be connected via USB to the device; uploading the kernel via network does not work.
Create a udev rules file for the OUYA so that you are able to communicate with the device over USB. Put the following into /etc/udev/rules.d/051-android.rules:
# ouya SUBSYSTEM=="usb", ATTRS{idVendor}=="2836", MODE="0666" # fastboot ouya SUBSYSTEM=="usb", ATTRS{idVendor}=="0955", MODE="0666"
Install the Android debug bridge (adb) and make it recognize the OUYA as Android device:
$ sudo apt-get install android-tools-adb
$ echo "0x2836" >> ~/.android/adb_usb.ini
$ adb kill-server
$ adb devices
List of devices attached
012d3a4efac56789 device
In your home directory, create a directory ouya-kernel:
$ cd
$ mkdir ouya-kernel
$ cd ouya-kernel
Flashing the OUYA with a new kernel requires a ramdisk file, and we can get it from the current firmware. At the time of writing this was 1.2.1427-r1.
$ wget http://devs-ouya-tv-prod.s3.amazonaws.com/ota/RC-OUYA-1.2.1427-r1_ota.zip
$ unzip RC-OUYA-1.2.1427-r1_ota.zip boot.img
$ wget http://www.enck.org/tools/split_bootimg_pl.txt -O split_bootimg.pl
$ perl split_bootimg.pl boot.img
$ gunzip boot.img-ramdisk.gz
$ mv boot.img-ramdisk ramdisk
split_bootimg.pl's homepage is http://www.enck.org/tools.html#split_bootimg.
We have to cross-compile the kernel for the ARM platform; and the NDK contains the correct tools for that.
android-ndk-r10e did not work for me; I got a unknown CPU architecture error during kernel compilation. android-ndk-r9d did work:
$ wget https://dl.google.com/android/ndk/android-ndk-r9d-linux-x86_64.tar.bz2
$ tar xjvf android-ndk-r9d-linux-x86_64.tar.bz2
OUYA's kernel is on github, and we fetch it from there:
$ git clone git@github.com:ouya/ouya_1_1-kernel.git
Now we have to fetch the OUYA's kernel configuration file, which can be found at /proc/config.gz:
$ adb pull /proc/config.gz
$ gunzip -kc config.gz > ouya_1_1-kernel/.config
Now adjust the kernel configuration file in ouya_1_1-kernel/.config:
CONFIG_HIDRAW=y CONFIG_HID_MICROSOFT=y CONFIG_HID_PANTHERLORD=y
The kernel can be compiled now:
$ export CROSS_COMPILE=/home/cweiske/ouya-kernel/android-ndk-r9d/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86_64/bin/arm-linux-androideabi-
$ export ARCH=arm
$ cd ouya_1_1-kernel
$ make
.. wait an hour ..
$ cp arch/arm/boot/zImage ../
Install the fastboot command:
$ apt-get install android-tools-fastboot
$ adb reboot-bootloader
$ fastboot devices -l
012d3a4efac56789 fastboot usb:2-1.2
If fastboot gives you a no permissions warning, make sure that /etc/udev/rules.d/51-android.rules contains settings for vendor 0955 - the USB IDs change when rebooting into bootloader mode!
Now it's time to install the new kernel:
$ fastboot flash:raw boot ./zImage ./ramdisk
creating boot image...
creating boot image - 5742592 bytes
sending 'boot' (5608 KB)...
OKAY [ 1.125s]
writing 'boot'...
OKAY [ 1.854s]
finished. total time: 2.980s
$ fastboot reboot
If all went well, the OUYA boots up with the fresh kernel.
dmesg on the OUYA shows us that the joysticks are recognized now:
[ 113.056632] usb 2-1: new low speed USB device number 2 using tegra-ehci
<6>[ 113.104851] usb 2-1: New USB device found, idVendor=0810, idProduct=0001
<6>[ 113.116743] usb 2-1: New USB device strings: Mfr=0, Product=2, SerialNumber=0
<6>[ 113.124579] usb 2-1: Product: Twin USB Joystick
<6>[ 113.145452] input: Twin USB Joystick as /devices/platform/tegra-ehci.2/usb2/2-1/2-1:1.0/input/input1
<6>[ 113.156314] input: Twin USB Joystick as /devices/platform/tegra-ehci.2/usb2/2-1/2-1:1.0/input/input2
<6>[ 113.167024] pantherlord 0003:0810:0001.0001: input,hidraw0: USB HID v1.10 Joystick [Twin USB Joystick] on usb-tegra-ehci.2-1/input0
<6>[ 113.179213] pantherlord 0003:0810:0001.0001: Force feedback for PantherLord/GreenAsia devices by Anssi Hannula ]]>
The Playstation controllers did not work immediately. The axes (up/down, left/right) did work, but the keys did not. I had to provide my own key layout file for the joysticks.
Creating it was easy; I installed the KeyTest Android application (link is dead) which could be downloaded as pre-compiled .apk file (archived version).
Then I clicked all the buttons on the OUYA controller and wrote down the scan codes. Afterwards, I wrote down the scan codes of the Playstation controllers.
The resulting key layout file has to get the name Vendor_0810_Product_0001.kl.
# PSX controller mapping # Dual PSX Adaptor / Twin USB Joystick # idVendor=0810, idProduct=0001 # Linux HID_PANTHERLORD driver # X cross key 290 BUTTON_A # O circle key 289 BUTTON_B # [] square key 291 BUTTON_X # /\ triangle key 288 BUTTON_Y key 294 BUTTON_L1 key 292 BUTTON_L2 key 295 BUTTON_R1 key 293 BUTTON_R2 key 296 BUTTON_SELECT key 297 BUTTON_START key 298 BUTTON_THUMBL key 299 BUTTON_THUMBR axis 0x00 X axis 0x01 Y axis 0x02 HAT_X axis 0x03 HAT_Y axis 0x04 RZ axis 0x05 Z
Push it onto your OUYA into /system/usr/keylayout/:
$ adb push Vendor_0810_Product_0001.kl /sdcard/
$ adb shell
$ su
$ mount -o remount,rw /system
$ mv /sdcard/Vendor_0810_Product_0001.kl /system/usr/keylayout/
Now unplug and replug the USB controller - and it works!
root
users on mariadb-server
10.4+ no longer have a password because
they authenticate via a unix socket instead of a TCP network connection.
On our new server, someone accidentially dropped that user and when running mysql as root on the shell, we had to enter the username and password. This is not nice when migrating databases.
The Debian README for mariadb-server says:
You may never ever delete the mysql user "root".
The solution is to restore that user:
GRANT ALL PRIVILEGES ON *.* TO root@localhost IDENTIFIED VIA unix_socket WITH GRANT OPTION;
FLUSH PRIVILEGES;
My laptop's disk space was running low, and one of the large directories the Disk Usage Analyzer showed me was /var/log/journal/3a53c17cd7e5413c89e602ca479f5c6d/. It is the storage of the systemd journal.
You can configure systemd-journald to keep them below a certain size by setting SystemMaxUse in /etc/systemd/journald.conf to e.g. 100M.
Restarting the journal daemon with systemctl restart systemd-journald already causes older entries to be removed.
I've always wanted to play the game Horizon Zero Dawn since it was released for the PlayStation 4 in 2017. In 2020-07 it was released for PC, but since it was DRM-ridden, I did not buy it then.
In 2022-12 I found it on gog.com for a reasonable price of 17€ and bought it. After downloading the 74 GiB with the command-line tool LGOGDownloader and installing it with Wine 8.0-rc2, I started it and got a crash:
Unhandled exception: illegal instruction in 64-bit code (0x00000140118cb7).
It turned out that HorizonZeroDawn.exe uses CPU instructions that my processor (AMD Phenom II X4 945 from 2009) does not support. The minimum system requirements say that an AMD FX 6300 is needed, which was released in 2012.
It is possible to see which opcodes are used in an executable.
Combining objdump with some grep will give you the list of CPU instructions. I used cpu_features.py to get the list, and it showed me that AVX and SSE4 instructions are used:
$ python2 cpu_features.py HorizonZeroDawn.exe [...] x64: sse4.1: pextrw pextrq sse4.2: crc32 [...] sandybridge: avx: vcvtss2sd vpmuludq vpsrlq vpcmpgtd vcvtsd2ss vaesenc vsqrtss [...]
Just listing the instructions does not mean that they are actually used, because the programs can have checks that use certain opcodes only when the CPU supports it.
Many players complained about Horizon requiring AVX, and so version 1.08 was released that removed that requirement:
Fixed a start-up crash for CPUs that do not support AVX instructions
This leaves the SSE4 opcodes that are also not supported by my processor :-/ I will have buy a new CPU + mainboard until I am able to play the game.
Someone on the internet provides binaries for processors without SSE4.x support but those executables are for the Steam and Epic versions only, and not for the GOG one :(
On the train to work I opened my Purism Librem 13 v3 laptop, and the screen did not wake up. Normally I have to hold the power key for 2-3 seconds to enable it in such a case, but this time that did not work. ( I decided to reboot.
The boot logo appeared, grub flashed, and then I saw:
cryptsetup: Waiting for encrypted source device UUID=d21486a-2088-4949-9e9f-deadbeefcafe
cryptsetup: Waiting for encrypted source device UUID=d21486a-2088-4949-9e9f-deadbeefcafe
[...]
Gave up waiting for suspend/resume device
cryptsetup: Waiting for encrypted source device UUID=d21486a-2088-4949-9e9f-deadbeefcafe
Gave up waiting for root file system device. Common problems:
- Boot args (cat /proc/cmdline)
- Check rootdelay= (did the system wait long enough?)
- Missing modules (cat /proc/modules; ls /dev)
ALERT! /dev/mapper/boo--vg-root does not exist. Dropping to a shell!
BusyBox v1.35.0 (Debian 1:1.35.0-3+b1) built-in shell (ash)
Enter ´help´ for a list of built-in commands.
(initramfs) _
I could not enter the password to decrypt the hard disk, and so the laptop could not boot.
I am using Debian unstable, and this is the first time this was a problem: I was bitten by Bug #1023492 . And yes, I am running kernel 6.0.6-2. And I had purged the 5.x kernels a couple of days earlier when cleaning up the system :(
The bug report said that the bug was fixed with Debian kernel 6.0.8-1. But how do I upgrade the kernel on a system that does not boot?
I downloaded a live image and copied the .iso file to a USB flash drive with cp. After plugging it into the laptop I could boot from it and had a shell.
The live CD did not have cryptsetup on board, so I had to install it. Luckily I have an USB ethernet adapter, so I simply plugged it into the laptop and ran:
# see the available network devices
$ ip addr
# who had the idead to use the mac address in the device name?
# that one did not think of the people that have to manually type them!
$ dhclient enx000ec6e25b11
# check if the device is up now
$ ip addr
$ apt update && apt install -y cryptsetup
Now I could finally decrypt the harddisk and mount the partition. I had a LVM group so mounting was not as straight-forward as I had hoped:
$ cryptsetup open /dev/sda5 sda5_crypt
$ mount /dev/mapper/crypted_sda5 /mnt/
mount: /mnt: unknown filesystem type "LVM2_member"
$ vgdisplay
--- Volume group ---
VG Name boo-vg
[...]
$ mount /dev/boo-vg/root /mnt/
$ ls /mnt/
bin boot dev etc home ...
At first I used "crypted_sda5" as last parameter for cryptsetup. This worked, but when updating the kernel I got an error:
update-initramfs: Generating /boot/initrd.img-6.0.0-4-amd64 cryptsetup: WARNING: target 'crypted_sda5' not found in /etc/crypttab
It is better to look into /etc/crypttab to see the name you have to use.
Now that I could mount the harddisk, I only had to chroot into the system and update the kernel.
$ mount /dev/boo-vg/root /mnt/
$ mount /dev/sda1 /mnt/boot
$ mount -t proc proc /mnt/proc
$ mount -t sysfs sys /mnt/sys
$ mount -o bind /dev /mnt/dev
$ mount -t devpts pts /mnt/dev/pts
$ chroot /mnt
$ dhclient enx000ec6e25b11
$ apt update && apt upgrade -y
# manually force regenerating initramfs when you run into
# the "target 'crypted_sda5' not found in /etc/crypttab" error
# https://www.debian.org/doc/manuals/debian-kernel-handbook/ch-initramfs.html
$ dpkg-reconfigure linux-image-6.0.0-4-amd64
$ exit
$ reboot
With the updated kernel I could enter the harddisk password at boot, and the system started up normally.
The process of fixing this problem took ~ 2.5 hours.