This is not a nice post. This is a post about Gnome/GDM customization.

I recently got the opportunity to work on adapting the default Debian Gnome experience to a client’s corporate design, and it felt a LOT like reverse-engineering deeply into the undocumented.

I found the work to fall into a number of categories, which I will classify as “dconf policy”, “css”, “xml-manifest” and “packaging”.

GDM logodconf policy, packaging
GDM banner messagedconf policy
GDM background colorcss, xml-manifest
GDM wallpapercss, xml-manifest, packaging
Gnome default wallpaperdconf policy, packaging
Gnome default themedconf policy
Gnome shell pluginsdconf policy, packaging
Gnome UI and plugin defaultsdconf policy
Gnome wallpapersxml-manifest

Note I’m not familiar with any underlying Gnome/GTK philosopy aspects but come from a Linux engineering role and just need to get the job done.

Packaging

The “packaging” class really just means that required assets need to be packaged onto the system and that any shell plugins that should be enabled by default, must be installed.

GDM

The GDM-Settings workflow

For GDM customization, GDM-Settings proved immensely helpful for identifying where to make changes.

# Install via flatpak
sudo apt-get install flatpak gnome-software-plugin-flatpak
flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo
flatpak -y install io.github.realmazharhussain.GdmSettings

# Keep track of where we started off
touch /tmp/now

# Run gdm-settings
flatpak run io.github.realmazharhussain.GdmSettings

# See what changed
find / -type f -newer /tmp/now 2>/dev/null | egrep -v '^/(dev|run|proc|sys|home|var|tmp)'

For this post, I will stick with the default dconf policy filename used by GDM-Settings.

Logo and banner

# /etc/dconf/db/gdm.d/95-gdm-settings
[org/gnome/login-screen]
logo='/usr/share/icons/hicolor/48x48/apps/gvim.png'
banner-message-enable=true
banner-message-text='Welcome to VIMnux'

dconf needs an accompanying profile definition, /etc/dconf/profile/gdm:

user-db:user
system-db:gdm

dconf update needs to be run after modifying these files.

Background color and wallpaper

GDM background settings are hidden deep in the global gnome-shell theme CSS, which itself is hidden in /usr/share/gnome-shell/gnome-shell-theme.gresource.

GDM-Settings completely hides the tedious process of drilling down to the CSS away from the user, which is great from a user perspective, but not what I needed for my customizations. I went with the following workflow for unpacking the files. gresource list lists the file names contained in the gresource file, gresource extract extracts them one by one.

# Unpack /usr/share/gnome-shell/gnome-shell-theme.gresource
# to a temporary directory:
T=$(mktemp -d /tmp/gres.XXX); printf "Resources tempdir: %s\n" $T
cd $T
while read R
do
  gresource extract /usr/share/gnome-shell/gnome-shell-theme.gresource $R > $(basename $R)
done < <(gresource list /usr/share/gnome-shell/gnome-shell-theme.gresource)

At this point, the only file I’m interested in is gnome-shell.css, where I set a black background for my application.

.login-dialog { background: transparent; }
#lockDialogGroup { background-color: rgb(0,0,0); }

Similar CSS for a wallpaper:

.login-dialog { background: transparent; }
#lockDialogGroup {
  background-image: url('file:///usr/share/backgrounds/gnome/wood-d.webp');
  background-position: center;
  background-size: cover;
}

Reassembly of the gresource file requires an XML manifest which I generate using the following script, manifest.py:

#!/usr/bin/env python3

import os, sys, glob
import xml.etree.ElementTree as ET
from io import BytesIO

os.chdir(sys.argv[1])
gresources = ET.Element('gresources')
gresource = ET.SubElement(gresources, 'gresource', attrib = {'prefix': '/org/gnome/shell/theme'})
for resourcefile in glob.glob('*'):
    file = ET.SubElement(gresource, 'file')
    file.text = resourcefile

out = BytesIO()
xmldoc = ET.ElementTree(gresources)
ET.indent(xmldoc)
xmldoc.write(out, encoding='utf-8', xml_declaration=True)
print(out.getvalue().decode())

First generate the XML manifest, then compile the gresources file.

# Generate XML
./manifest.py $T > gnome-shell-theme.gresource.xml

# Compile gresources (glib-compile-resources from libglib2.0-dev-bin)
glib-compile-resources gnome-shell-theme.gresource.xml --sourcedir=$T --target=gnome-shell-theme.gresource

Someone over here decided to indirect /usr/share/gnome-shell/gnome-shell-theme.gresource via /etc/alternatives, do whatever you like.

Note that on the systems I tested this on, gdm.css and gdm3.css could be left out of the gresource file and all changes were made in gnome-shell.css.

Gnome Wallpapers

Speaking of XML, Wallpapers can be installed to someplace intuitive such as /usr/share/backgrounds/corporate but must be accompanied by another XML manifest in /usr/share/gnome-background-properties, which I generate using another XML generator, properties-xml.py:

#!/usr/bin/env python3

import os, sys, glob
import xml.etree.ElementTree as ET
from io import BytesIO

os.chdir(sys.argv[1])
dirname='/usr/share/backgrounds/corporate'
wallpapers = ET.Element('wallpapers')
for wallpaper in glob.glob('*'):
    wallpaper_element = ET.SubElement(wallpapers, 'wallpaper', attrib = {'deleted': 'false'})
    filename = ET.SubElement(wallpaper_element, 'filename')
    filename.text = f"{dirname}/{wallpaper}"
    name = ET.SubElement(wallpaper_element, 'name')
    name.text = wallpaper
    options = ET.SubElement(wallpaper_element, 'options')
    options.text = 'zoom'
    pcolor = ET.SubElement(wallpaper_element, 'pcolor')
    pcolor.text = '#000000'
    scolor = ET.SubElement(wallpaper_element, 'scolor')
    scolor.text = '#ffffff'

out = BytesIO()
xmldoc = ET.ElementTree(wallpapers)
ET.indent(xmldoc)
xmldoc.write(out)
print('<?xml version="1.0" encoding="UTF-8"?>')
print('<!DOCTYPE wallpapers SYSTEM "gnome-wp-list.dtd">')
print(out.getvalue().decode())

Which I run as follows:

./properties-xml.py backgrounds > corporate.xml

/usr/share/backgrounds/corporate/* and /usr/share/gnome-background-properties/corporate.xml then get packaged onto the system.

Gnome Extensions and Defaults

At this point, a dconf user profile needs to be introduced:

$ cat /etc/dconf/profile/user 
user-db:user
system-db:local

(Things get easier from here.)

Default-enabled extensions

I chose to enable the extensions and set related defaults in /etc/dconf/db/local.d/99-extensions:

[org/gnome/shell]
enabled-extensions=[ 'ding@rastersoft.com', 'no-overview@fthx', 'dash-to-dock@micxgx.gmail.com', 'ubuntu-appindicators@ubuntu.com', 'TopIcons@phocean.net' ]

[org/gnome/shell/extensions/dash-to-dock]
dock-fixed=true
background-opacity=0.2
transparency-mode='FIXED'

dconf update needs to be run after modifying this file.

Other Gnome defaults

dconf watch /

dconf watch / in a terminal makes it possible to take note of what configuration options change as changes are being made. They can now be made the defaults in a policy file such as /etc/dconf/db/local.d/99-misc-defaults:

[org/gnome/desktop/wm/preferences]
button-layout='appmenu:minimize,maximize,close'

[org/gnome/terminal/legacy]
theme-variant='dark'

[org/gnome/desktop/interface]
color-scheme='prefer-dark'
gtk-theme='Adwaita-dark'

dconf update needs to be run after modifying this file.

tl;dr: Example customization package

A debian package that provides live examples, can be found here: https://github.com/mschmitt/gnome-local-custom

Too good to #0012

Today: Mounting tar archives, a novel take on uptime, ipxe escapes.


ratarmountAccess large archives as a filesystem efficiently, e.g., TAR, RAR, ZIP, GZ, BZ2, XZ, ZSTD archives

$ virtualenv ~/.local/ratarmount
$ ~/.local/ratarmount/bin/pip3 install -U ratarmount
$ ~/.local/ratarmount/bin/ratarmount
$ install -D ~/.local/ratarmount/bin/ratarmount ~/bin/

$ mkdir -p ~/mnt
$ curl -O https://data.iana.org/time-zones/tzdata-latest.tar.gz
$ ratarmount tzdata-latest.tar.gz ~/mnt
$ find ~/mnt
$ fusermount -u ~/mnt

tuptimeReport historical and statistical real time of the system, keeping it between restarts. Total uptime

tuptime calculates overall uptime of the system it’s running on. It also flags shutdowns as “BAD” if it comes up without having been gracefully stopped before.

As I grew up in an age where uptime braggery was common even among professionals, my entirely unreasonable use case here is to determine uptime since the previous unclean shutdown:

function tuptime-graceful () {
        local tuptime_since=1
        local temp_array
        while read -r line 
        do
                if [[ "${line}" =~ ' BAD ' ]]
                then
                        read -r -a temp_array <<< "${line}"
                        tuptime_since=$(( temp_array[0] + 1 ))
                        break
                fi
        done < <(tuptime --table --order e --reverse)
        tuptime --since "${tuptime_since}"
}

Ampersand in ipxe script

Example is from a Debian preseed environment where preseed/late_command downloads and executes a shell script

set amp &
set latecmd in-target wget ${script_url} ${amp}${amp} in-target bash script.sh
kernel [...] preseed/late_command="${latecmd}"

Vollständige Liste aller Amazon-Alternativen

Vielen Dank für eure Aufmerksamkeit. Es folgt eine unvollständige Liste einiger weniger Amazon-Alternativen.

Ich sage nicht, dass ich Amazon nicht benutze oder ihr Amazon nicht benutzen sollt. Ich sage lediglich, dass ich diese Shops bereits alternativ benutzt habe. (Updates folgen.)

Hardware

Elektro- und Elektronikmaterial

Werkzeug

Verbrauchs- und Bastelmaterial

Büromaterial

Drogerie / Körperpflege

Genussmittel


Aus dem Feedback

(Von mir ungetestet, aber aus vertrauenswürdigen Quellen.)

Failsafe curl

Nothing serious, just a few notes I like to share with friends and colleagues who, like me, script around curl.

curl -f / --fail

I try to use --fail whenever I can, because why would I want to exit zero on server errors?

$ curl -L https://download.grml.org/grml64-small_2024.02.iso.NO
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL was not found on this server.</p>
<hr>
<address>Apache/2.4.41 (Ubuntu) Server at ftp.fau.de Port 443</address>
</body></html>
$ echo $?
0
$ curl -f -L https://download.grml.org/grml64-small_2024.02.iso.NO
curl: (22) The requested URL returned error: 404
$ echo $?
22

curl --fail-with-body

I have a CI/CD situation where curl calls a webhook and it’s incredibly useful to see its error message in case of failure.

$ curl --fail https://binblog.de/xmlrpc.php
curl: (22) The requested URL returned error: 405
$ curl --fail-with-body https://binblog.de/xmlrpc.php
curl: (22) The requested URL returned error: 405
XML-RPC server accepts POST requests only.

set -o pipefail

When curl‘s output gets piped to any other command, I try to remember to set -o pipefail along with curl --fail so if curl fails, the pipe exits non-zero.

#!/usr/bin/env bash

url='https://download.grml.org/grml64-small_2024.02.iso.NONO'

if curl -s -f -L "${url}" | sha256sum
then
        echo "Success."
else
        echo "Failure."
fi

set -o pipefail

if curl -s -f -L "${url}" | sha256sum
then
        echo "Success."
else
        echo "Failure."
fi

curl --connect-timeout

Useful to get quicker response in scripts instead of waiting for the system’s default timeouts.

curl -w / --write-out

This may be over the top most of the time, but I have one situation that requires extremely detailed error handling. (The reason being a bit of a foul split DNS situation in the environment, long story.) This is where I use --write-out to analyze the server response.

curl_http_status="$(curl -o "${tmpfile}" --write-out '%{http_code}\n' "${url}")"
curl_exit_status=$?

(Would be even nicer if a destination filename could be specified instead of needing to work with stdout only.)

curl -n / --netrc / [ --netrc-file ]

Username:password authentication is a thing, no matter how much it’s discouraged. Here’s how to at least hide username and password from the process list.

$ chmod 600 ~/.netrc
$ cat ~/.netrc
machine binblog.de
login foo
password bar
$ curl -v -o /dev/null -n https://binblog.de
...
* Server auth using Basic with user 'foo'
...

To use any other file instead of ~/.netrc, use --netrc-file instead.

Too good to #0011

Mozilla Firefox APT special

The Mozilla Firefox APT repository is incompatible with legacy apt-mirror. Here’s how I install apt-mirror2 as a dedicated python-virtualenv

# apt-get install virtualenv
# virtualenv --no-setuptools /usr/local/apt-mirror2/
# /usr/local/apt-mirror2/bin/pip3 install -U apt-mirror
# /usr/local/apt-mirror2/bin/apt-mirror --help
  • Repeat as-is to update.
  • Here’s the bug that neccessitates the --no-setuptools option: “ModuleNotFoundError: No module named ‘debian'”

mirror.list entry for the Mozilla Firefox APT repository:

deb-all [signed-by=/path/to/packages-mozilla-org.gpg] https://packages.mozilla.org/apt mozilla main
deb-amd64 [signed-by=/path/to/packages-mozilla-org.gpg] https://packages.mozilla.org/apt mozilla main

How to convert Mozilla’s sloppy ASCII-armored PGP key:

$ curl -s -O https://packages.mozilla.org/apt/repo-signing-key.gpg
$ file repo-signing-key.gpg
repo-signing-key.gpg: PGP public key block Secret-Key
$ mv repo-signing-key.gpg repo-signing-key
$ gpg --dearmor repo-signing-key
$ file repo-signing-key.gpg
repo-signing-key.gpg: OpenPGP Public Key Version 4, Created Tue May 4 21:08:03 2021, RSA (Encrypt or Sign, 2048 bits); User ID; Signature; OpenPGP Certificate

Too good to #0010

In today’s installment:

  • “Headless” Nextcloud
  • Monitoring of fork activity

Mount Nextcloud files via rclone+Webdav, as a systemd user unit

# ~/.config/systemd/user/nextcloud-mount.service
[Unit]
Description=Mount Nextcloud via rclone-webdav

[Service]
ExecStartPre=mkdir -p %h/Nextcloud
ExecStart=rclone mount --vfs-cache-mode full --verbose nextcloud_webdav: %h/Nextcloud/
ExecStop=fusermount -u %h/Nextcloud/
ExecStopPost=rmdir %h/Nextcloud

[Install]
WantedBy=default.target

Sync instead of mount

Nextcloud via Webdav is absurdly slow, so maybe use nextcloudcmd instead, which unfortunately does not have its own daemonization:

# ~/.netrc (chmod 600)
machine my.nextcloud.example.com
login myuser
password *** (app password)
# ~/.config/systemd/user/nextcloudcmd.service
[Unit]
Description=nextcloudcmd (service)

[Service]
ExecStart=nextcloudcmd -n --silent %h/Nextcloud https://my.nextcloud.example.com
# ~/.config/systemd/user/nextcloudcmd.timer
[Unit]
Description=nextcloudcmd (timer)

[Timer]
OnStartupSec=60
OnUnitInactiveSec=300

[Install]
WantedBy=default.target

forkstat (8) – a tool to show process fork/exec/exit activity

High load without a single obvious CPU consuming process (not related to the Nextcloud shenanigans above) led me to forkstat(8):

Forkstat is a program that logs process fork(), exec(), exit(), coredump and process name change activity. It is useful for monitoring system behaviour and to track down rogue processes that are spawning off processes and potentially abusing the system.

$ sudo forkstat # (that's all)

Das Rezept für gebrannte Mandeln

Auf vielfachen vereinzelten Wunsch, und für den Fall, dass die Primärquelle, bei der ich mich zwecks Abwandlung bedient habe, irgendwann aus dem Internet verschwindet, hier mein Rezept für gebrannte Mandeln.

Die Zubereitung ist eine ziemliche Geduldsprobe, dafür kann man aber außer bei der Karamellisierung fast nichts verkehrt machen, und sogar dann sind nicht so gut gelungene gebrannte Mandeln immer noch: Gebrannte Mandeln.

Zubereitungszeit

45 Minuten

Zutaten für eine große Bratpfanne

  • 250 g Mandeln mit Haut
  • 150 g Zucker
  • 1 Beutel Vanillezucker
  • Einen gestrichenen Teelöffel Zimt, dazu zu Weihnachten gern einen Hauch Muskat, Nelken, Anis, Piment oder Pfeffer.
  • Etwas Wasser, ca. 100 ml

Werkzeug

  • Große Bratpfanne, beschichtet mit dem guten Mikroplastik
  • Holzlöffel
  • Backpapier
  • 2 Gabeln

Zubereitung

  • 50 g Zucker mit Vanillezucker und den Gewürzen verrühren und für später aufheben.
  • 100 g Zucker mit gerade so wenig Wasser in die Pfanne geben, dass sich der Zucker auflösen kann.
  • Das Zucker-Wasser-Gemisch aufkochen.
  • Die Mandeln hinzugeben, und so lange bei höchster Hitze rühren, bis das Wasser verdampft ist und der Zucker kristallisiert. Danach noch kurz weiterrühren, bis an den ersten Mandeln braun glänzende Stellen zu erkennen sind.
  • Temperatur runterregeln (bei mir von 9 auf 6), die Mandeln gleichmäßig verteilen und den restlichen Zucker mit den Gewürzen gut verteilt drüberstreuen.
  • Ununterbrochen rühren, bis die Mandeln karamellisiert sind. Die Temperatur so niedrig halten, dass sich keine schwappende Karamellsoße in der Pfanne sammelt. Alles was flüssig ist, muss von den Mandeln sofort angenommen werden können.
  • Wenn die Mandeln nicht mehr krustig, sondern schön karamellisiert sind, den Pfanneninhalt so weit und locker wie möglich auf einem Bogen Backpapier verteilen, die Mandeln mit zwei Gabeln soweit möglich vereinzeln und abkühlen lassen.

Frohe Weihnachten, lasst es euch schmecken.

Die 15-Euro-Schieblehre

Kurz nachdem ich vor einer Weile meinen guten Messschieber (Amazon-Link ohne Affiliation) bekommen hatte, hat mich bereits zufällig die 15-Euro-Schieblehre vom Bauhaus angelacht. Preislich lässt sie ganz Amazon hinter sich und Ebay gleich mit, und ich musste heute dem Drang nachgeben, sie für “draußen” anzuschaffen.

Zwei Messchieber übereinander abgebildet, sie messen jeweils eine rostige Mutter mit 22 mm Schlüsselweite.

Etwas kratzig ist ihre Qualitätsanmutung schon, speziell beim Drehen des Rädchens und Spiel ist vorhanden und messbar, aber zumindest nicht als Klapprigkeit zwischen den Fingern spürbar. Zwischen mm/inch kann per einfachem Tastendruck umgeschaltet werden, die Verarbeitung am Austritt des Tiefenmaß finde ich sogar deutlich schöner als bei der Helios-Preisser. Für Preis/Leistung zu einem Siebtel des Preises gibts von mir den Daumen nach oben. 👍

Too good to #0009

In this episode:

  • urlwatch for new daily Ubuntu Server ISO
  • systemd-run ephemeral timers as replacement for at
  • Mozillateam Firefox on Debian
  • systemd service: ExecStartPre as root
  • gdm3 autosuspend/shutdown behaviour

urlwatch for new daily Ubuntu Server ISO

Somewhat desparate because at the time of starting this post, the (pre-beta, non-LTS, not blaming anyone) server image in question was badly broken.

---
name: Ubuntu Server Daily ISO
url: https://cdimage.ubuntu.com/ubuntu-server/daily-live/current/SHA256SUMS
filter:
  - grep: .*-live-server-amd64.iso
---

systemd-run ephemeral timers as replacement for at

Goes great with “hardened” systems that deny use of at(1).

Run a command 60 seconds from now, via the user’s private systemd (after logout only if session lingering is enabled).

systemd-run --user --on-active=60s -- logger --tag foo "Hello world"

Run a command 2 minutes from now, privileged or as a specific user via the global systemd:

sudo systemd-run --uid="${LOGNAME}" --on-active=2m -- touch /tmp/hello

Insights

systemctl --user list-timers
journalctl --user -u 'run-*.timer'
sudo systemctl list-timers
sudo journalctl -u 'run-*.timer'

Mozillateam Firefox on Debian

$ sudo tee /etc/apt/sources.list.d/mozillateam-ppa.list <<Here
deb https://ppa.launchpadcontent.net/mozillateam/ppa/ubuntu jammy main
deb-src https://ppa.launchpadcontent.net/mozillateam/ppa/ubuntu jammy main
Here
$ sudo tee /etc/apt/trusted.gpg.d/mozillateam.asc < <(curl 'https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x0ab215679c571d1c8325275b9bdb3d89ce49ec21')

systemd service: ExecStartPre as root

[Service]
...
User=nonroot
Group=nonroot
ExecStartPre=+install -d /var/lib/theservice -o nonroot -g nonroot
ExecStart=/usr/sbin/theservice

See systemd.service, “special executable prefixes”.


gdm3 autosuspend/shutdown behaviour

Debian:

$ sudo apt-get install dbus-x11
$ sudo chsh -s /bin/bash Debian-gdm
$ sudo -i -u Debian-gdm
$ gsettings get org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type
'suspend'
$ dbus-launch gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type nothing
$ gsettings get org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type
$ exit
$ sudo chsh -s /bin/false Debian-gdm

Arch/Garuda:

$ sudo chsh -s /bin/bash gdm
$ gsettings get org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type
'suspend'
$ dbus-launch gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type nothing
$ gsettings get org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type
$ exit
$ sudo chsh -s /usr/bin/nologin gdm

Fremantle Highway – Chronologie nicht brennender 500 Elektroautos

500 Elektroautos waren an Bord, 500 Elektroautos wurden auf einem Deck entfernt vom Brandherd unbeschädigt vorgefunden, 500 Elektroautos gelten als Brandursache. Ganz normal.


Am 26. Juli 2023 geriet der Autofrachter Fremantle Highway in der Nordsee in Brand. Die Besatzung war gezwungen, das Schiff aufzugeben und zu verlassen, dabei kam tragischerweise ein Besatzungsmitglied ums Leben. Der Frachter trieb führerlos im Meer. Eine extrem bedrohliche Situation, denn die Fremantle Highway war gerade erst in Bremerhaven gestartet, hatte genug Schweröl für die Fahrt bis nach Singapur an Bord, und es drohte unmittelbar eine Ölpest im Wattenmeer.

Sofort wurde berichtet, unter den ca. 4000 Fahrzeugen an Bord seien ca. 25 Elektroautos (Handelsblatt, 26.07.2023, lokale Kopie des Artikels hier).

Die niederländische Küstenwache wurde zitiert, dass brennende Elektroautos an Bord Löscharbeiten erschweren könnten (Electrek, 26.07.2023 in englischer Sprache, lokale Kopie hier). Bezogen auf Löscharbeiten an Bord, unter der Voraussetzung, dass tatsächlich ein Fahrzeugakku gebrannt hätte, wäre ja auch objektiv nicht auszuschließen, dass Schiff und Besatzung möglicherweise nicht auf diese Situation vorbereitet gewesen sein könnten.

Eine Aussage, dass tatsächlich ein Elektroauto den Brand verursacht hatte oder auch nur mit in Brand geraten war, war von keiner Stelle getroffen worden. Es soll hier auch noch einmal verdeutlicht werden, dass tausende mit Verbrennungsmotor betriebene Fahrzeuge ebenfalls an Bord waren, mit Benzin in den Tanks und leicht entzündlichem Kältemittel in den Klimaanlagen (Der Spiegel, 12.04.2011).

In den Tagen darauf wurde die Anzahl der Elektroautos an Bord auf die auch zuletzt gemeldeten 498 erhöht (Tagesschau, 28.7.2023, lokale Kopie des Artikels hier).

Nachdem die Bildzeitung (29.7.2023, lokale Kopie des Artikels hier) als ausgewiesene Brandexpertin die 500 Elektroautos als wahrscheinlichste Brandursache identifiziert und die Presseabteilungen der Hersteller zur Rede gestellt hatte, galt die Geschichte von den 500 brennenden Elektroautos als beschlossene Sache und die Angelegenheit begann in den Kommentarsektionen so richtig zu gären. 500 brennende Elektroautos als Zerstörer des Wattenmeers, und an allem Schuld sind die Ökos und die Grünen! Was für eine Wendung des Schicksals!

Die ausgebrannte Fremantle Highway - Quelle: Verteidigungsministerium der Niederlande
Die ausgebrannte Fremantle Highway – Quelle: Verteidigungsministerium der Niederlande

2 Wochen später war das Feuer aus, die Gefahr für die Umwelt glücklicherweise gebannt, und die Fremantle Highway in einen sicheren Hafen geschleppt worden. Hier wurde festgestellt (Tagesschau, 11.08.2023, lokale Kopie des Artikels hier), dass die 498 Elektroautos sich auf einem tiefer gelegenen Deck befanden und beim Brand unbeschädigt geblieben waren:

Bei der Inspektion wurde nun deutlich, dass die unteren vier der zwölf Decks weitgehend unbeschädigt sind. Auch etwa 1.000 Autos, darunter 500 elektrische, seien auf den ersten Blick in gutem Zustand.

(Tagesschau-Artikel vom 11.08.2023)

Wenn alle 498 Elektroautos in gutem Zustand an Bord stehen, sollte eigentlich klar sein, dass der Brand nicht von den 498 Elektroautos ausgegangen sein kann. Aus Gründen, die sich dem nüchternen Betrachter nur schwer erschließen, stehen die 498 Elektroauos aber weiter im Fokus und Experten haben Angst, dass die 498 Elektroautos, die überhaupt nicht gebrannt haben, sich bei der Bergung erneut entzünden könnten:

“Das kann sehr gefährlich sein.” Man will nicht, dass die Autos sich durch den Transport erneut entzündeten, “und alles Elend von vorne anfängt”.

(Tagesschau-Artikel vom 11.08.2023)

Die Geschichte der Fremantle Highway ist also für immer als die vom Schiff mit den brennenden Elektroautos abgelegt, auf dem kein einziges Elektroauto gebrannt hat.

Update vom 04.09.2023

Eine niederländische Quelle (eemskrant.nl, 30.08.2023, Link via Google Translate, Direktlink zum eingebetteten Youtube-Video) berichtete als erste, ein vom Feuer beschädigtes Elektrofahrzeug habe sich erneut entzündet. Dass der Mercedes sich “erneut” entzündet habe, wird von keinem anderen Medium so formuliert (z.B. Welt, 01.09.2023).

Die enorm dicke Verrußung des Mercedes bei ansonsten relativ gutem Fahrzeugzustand dürfte nicht von einem sofort unter Kontrolle gebrachten Entstehungsbrand stammen, sondern vom Feuer an Bord im vergangenen Juli. Dass die anderen Autos, die von Bord kommen, im Gegensatz dazu sauber sind, könnte daran liegen, dass sie, früheren Presseberichten zufolge (NDR, 19.08.2023), noch an Bord gewaschen werden. Auf dem Foto eines weißen BMW i4 sind grau-braune Spuren am Dach zu erkennen (oben bereits verlinkt, Welt, 01.09.2023).

Der gute Zustand der sichtbaren Reifen des Mercedes spricht gegen einen Akkubrand, der in Fetzen herunterhängende Unterboden dagegen zumindest für Schäden in diesem Bereich. Ob diese Schäden beim Löschangriff oder bei der Bergung des Fahrzeugs aufgetreten sind, kann von hier aus nicht gesagt werden. Eine leichte Rauchentwicklung ist erst zu sehen, während über einen gelben Schlauch links im Bild bereits Wasser in den Container eingeleitet wird.

What goes up, must come down. Ask any system administrator.