Fryboyter

Arch Linux ARM - Keine Verbindung per SSH mehr möglich

In meinem privaten LAN ist ein Raspberry Pi 4 vorhanden der neben ein paar anderen Dingen eine Kombination von PiHole und unbound zur Verfügung stellt. Vor ein paar Tagen hat die Namensauflösung auf den Rechnern im LAN nicht mehr funktioniert.

Als ich mit SSH mit dem Raspberry Pi verbinden wollte, konnte keine Verbindung aufgebaut werden. Sehr seltsam…

Meine erste Vermutung war, dass die Speicherkarte defekt ist, da ich diese schon einige Jahre nutze und auch schon ein viele Schreibvorgänge stattgefunden haben. Also habe ich die Karte aus dem Raspberry Pi entfernt und mittels eines Kartenlesers an mein Notebook angeschlossen. Sofort wurden die beiden Partitionen auf der Speicherkarte erkannt, ich konnte sie mounten und auf die Dateien zugreifen. Also ist es scheinbar doch nicht die Speicherkarte.

Trotzdem habe ich erst mal ein Image der Karte erstellt und dieses dann mittels PiShrink auf eine annehmbare Größe verkleinert.

Vielleicht steht ja in den Log-Dateien etwas, dass auf das Problem hinweist. Da am Raspberry Pi weder ein Monitor noch eine Tastatur angeschlossen ist, habe ich die größere der beiden Partitionen gemountet. Nehmen wir an im Home-Verzeichnis des Notebooks im Verzeichnis rasp. Dann habe ich mittels journalctl -D ~/rasp/var/log/journal -r auf die Log-Dateien auf der Speicherkarte zugegriffen. Schon nach wenigen Zeilen habe ich die erste und einzige Fehlermeldung gefunden.

alarmpi systemd[1]: Failed to start Wait for Network to be Configured.
alarmpi systemd[1]: systemd-networkd-wait-online.service: Failed with result 'exit-code'.
alarmpi systemd[1]: systemd-networkd-wait-online.service: Main process exited, code=exited, status=1/FAILURE
alarmpi systemd-networkd-wait-online[322]: Timeout occurred while waiting for network connectivity.

Der Raspberry Pi bootet also, kann aber keine Netzwerkverbindung aufbauen. Aber warum? Die Konfigurationen habe ich seit mindestens einem Jahr nicht geändert.

Trotzdem habe ich mir die Konfigurationsdatei eth0.network unter ~/rasp/etc/systemd/network/ angesehen.

Sieht gut aus.

[Match]
Name=eth0
...

Wobei… Moment! Eth0 bei einer Distribution die systemd und somit Predictable Network Interface Names nutzt? Könnte das die Ursache sein?

Einen Versuch ist es wert. Also habe ich Name=eth0 in Name=en* geändert, da der Netzwerkanschluss per Kabel immer eine Bezeichnung zugeteilt bekommt die mit en beginnt. Welche genau, kann ich nicht sagen, da ich ja keinen Zugriff im laufenden Betrieb habe.

Und siehe da, der Raspberry Pi bootet und eine Verbindung per SSH ist wieder möglich. Mittels ip addr habe ich mir dann die Netzwerkverbindungen des Raspberry Pi anzeigen lassen und festgestellt, dass der Netzwerkanschluss per Kabel die Bezeichnung end0 hat. Also habe ich abschließend Name=en* noch in Name=end0 geändert. Wobei das ist in dem Fall nicht nötig ist, da nicht zwei unterschiedliche Netzwerkanschlüsse mit Kabel vorhanden sind. Aber sicher ist sicher.

Aber warum ist das erst jetzt passiert? Predictable Network Interface Names gibt es unter systemd schon ewig und sind in der Standardkonfiguration aktiv. Nachdem ich im offiziellen Forum von Arch Linux ARM gesucht habe, habe ich mehrere Fälle mit dem gleichen Problem gefunden. Z. B. https://archlinuxarm.org/forum/viewtopic.php?f=15&t=16245. Zumindest bin ich nicht alleine. Ich vermute, dass durch ein Update Predictable Network Interface Names aktiviert wurden und es deshalb zu Problemen gekommen ist, weil meine Installation schon sehr alt ist. Aber das ist eine Vermutung.

OSBN

Raspberry Pi Images schrumpfen

Nehmen wir an, man hat einen Raspberry Pi mit einer SD-Karte mit 120 GB komplett eingerichtet und will ein Image erstellen, um dies auf andere Raspberry Pi zu installieren. Die meisten Nutzer werden hierfür Befehle wie dd if=/dev/mmcblk0 of=/home/username/raspberry.img bs=4M nutzen. Das ist einfach. Hat allerdings einen Nachteil. Die Image-Datei ist 120 GB groß egal wie viel Speicherplatz tatsächlich genutzt wird. Auch wenn Speicherplatz nicht mehr sehr teuer ist, verschwendet man diesen in dem Fall. Man müsste das Image also schrumpfen. Was manuell durchaus machbar ist. Oder man nutzt PiShrink.

Damit lassen sich mittels dd erstellt Image-Dateien auf die tatsächlich genutzte Größe schrumpfen. In meinem Fall hatte ursprünglich 120 GB große Image nur noch eine Größe von 13 GB. Hierfür reicht der einfache Befehl pishrink.sh rasberry.img aus.

Erstelle man nun mittels dd den Inhalt des geschrumpften Image auf eine andere SD-Karte und bootet von dieser, passen sich die Partitionen automatisch an die Größe der SD-Karte an, sodass der gesamte Speicherplatz zur Verfügung steht. Hierfür baut PiShrink einen entsprechenden Befehl in die Image-Datei ein.

OSBN | Linux

Raspberry Pi - Gefälschte Echtzeituhr

Da die Raspberry Pi nicht mit einer Echtzeituhr ausgerüstet sind, stellt dich das Datum nach jedem Reboot erst einmal auf den 01.01.1970 00:00 Uhr.

Wer seinem Raspberry kein RTC-Modul (z. B. DS3231) spendieren möchte und es mit der Zeit nicht ganz so genau nimmt, kann schummeln und sich fake-hwclock installieren. Hiermit wird die aktuelle Uhrzeit des Raspberry Pi periodisch sowie beim Herunterfahren in eine Datei gespeichert und beim Booten wiederhergestellt. In Verbindung mit einem NTP-Client lässt sich so die Uhrzeit des Raspberry Pi durchgehend halbwegs aktuell halten.

Linux | OSBN

Temperatur des Raspberry Pi auslesen

Bei den aktuellen Temperaturen wollte ich mal wissen, wie sich hier mein Raspberry Pi schlägt, da dieser in einem nicht gerade kühlen Raum läuft. Dies kann man mit Boardmitteln auslesen und muss kein extra Paket installieren.

Unter /opt/vc/bin findet man den Befehl vcgencmd. Ruft man diesen mittels vcgencmd measure_temp auf, bekommt man die Temperatur des SoC angezeigt. Bei mir liegt diese aktuell bei 44,4 Grad Celsius. Für den Raspberry Pi ist das absolut in Ordnung. Erst ab 80 Grad Celsius wird es kritisch. Bei 85 zieht der Raspberry Pi automatisch die Notbremse und setzt den Takt herunter.

Linux | OSBN

EXT4-fs (mmcblk0p2): couldn''t mount as ext3 due to feature incompatibilities

In der Logdatei meines Raspberry Pi tauchen nach jedem Start die Fehlermeldungen “EXT4-fs (mmcblk0p2): couldn’t mount as ext3 due to feature incompatibilitie” und “EXT4-fs (mmcblk0p2): couldn’t mount as ext2 due to feature incompatibilities” auf. Es funktioniert zwar alles aber es nervt. Vor allem, weil mmcblk0p2 in dem Fall ext4 und nicht ext3 oder ext2 nutzt. Aber die Lösung ist recht einfach.

Einfach die Datei /boot/cmdline.txt öffnen und rootfstype=ext4 hinzufügen und abspeichern. Nach einem Neustart ist die Fehlermeldung verschwunden. Nebenwirkungen konnte ich auch noch keine feststellen.

Linux | OSBN