Closed rusitschka closed 2 years ago
Ich konnte es noch nicht durchtesten, aber ich gehe davon aus, dass es keine Probleme gibt.
Gestern konnte ich es testweise installieren, heute dann folgendes:
...
Setting up pivccu3 (3.59.6-59) ...
dpkg: error processing package pivccu3 (--configure):
installed pivccu3 package post-installation script subprocess returned error exit status 255
...
Errors were encountered while processing:
pivccu3
E: Sub-process /usr/bin/dpkg returned an error code (1)
Ich bin kein apt/dpkg-Kenner. Aber ich wundere mich wie man herausfindet was da genau schiefgelaufen ist.
Beim meinem Versuch das ganze per Ansible zu installieren gab's noch diese Meldungen:
Setting up uuid-runtime (2.36.1-8) ...
Adding group `uuidd' (GID 115) ...
Done.
Warning: The home dir /run/uuidd you specified can't be accessed: No such file or directory
Adding system user `uuidd' (UID 111) ...
Adding new user `uuidd' (UID 111) with group `uuidd' ...
Not creating home directory `/run/uuidd'.
Created symlink /etc/systemd/system/sockets.target.wants/uuidd.socket -> /lib/systemd/system/uuidd.socket.
uuidd.service is a disabled or a static unit, not starting it.
Nachdem ich die postinst
aus dem deb-Package mit set -x
gepatcht habe kommt dieses hier bei apt install ./patched.deb
heraus:
...
++ for dev_no in {0..5}
++ '[' 0 -eq 0 ']'
++ UART_DEV=raw-uart
++ '[' -e /dev/raw-uart ']'
++ echo 1
+++ detect_radio_module /dev/raw-uart
++ MODULE_INFO='Error: Radio module was not detected'
Ich hatte das schon öfter. Stromlosmachen des Raspis hilft meistens.
@alexreinert Im Übrigen kann dieser Test nicht funktionieren, da das File per postinst
mit set -e
geladen wird. D.h. es wird nur /dev/raw-uart
geprüft, die anderen Versuche mit /dev/raw-uart1
etc. werden nicht gestartet.
Vorschlag:
if MODULE_INFO=`detect_radio_module /dev/$UART_DEV`; then
...
fi
Wenn am Ende des for
-Loops dann bspw. $SGTIN
nicht gesetzt ist kann man immer noch mit exit 1
den Fehler melden.
Mit dem zweiten Anlauf läuft es nun mit Raspbian Bullseye 64-bit. Bei mir hängt es glaube ich an der Installationsreihenfolge, da ich doch recht viel mit docker betreibe. Anstatt backup/restore habe ich auch kurzerhand die lxc-Verzeichnisse von pivccu mit tar gesichert und wiedergergestellt. Vielleicht ist das nicht supported, aber für mich der schnellste Weg zum lauffähigen System. Dasselbe habe ich gemacht als ich Anfang der Woche von Buster 32-bit auf 64-bit umgestellt habe. Wenige Stunden nachdem ich das Image runtergeladen und fertig migriert hatte gab's dann das Bullseye-Release 🤦.
Danke für den Hinweis mit dem Test. Was mir aber nicht klar ist: Meines Wissens nach gibt es Rasbian bzw. Raspberry Pi OS nur als 32 Bit System? Oder nimmst du das 32 Bit Image und stellst nur den Kernel auf 64 Bit um? Das wäre nicht supported, weil es leider nicht möglich ist, auf dem Raspberry per DKMS Kernel Module für dem 64 Bit Kernel zu bauen.
Meines Wissens nach gibt es Rasbian bzw. Raspberry Pi OS nur als 32 Bit System?
Ja, supported wird nur 32-bit, wobei man den Kernel wie du sagst auf 64-bit umstellen kann. Aber der User Space ist dann immer noch 32-bit. Ich nutze aber auch InfluxDB, deren v2 gibt's nur noch als 64-bit docker Images was sich mit einem docker Daemon im 32-bit-Gewand aber nicht verträgt. Also hab ich die 64-bit beta (die seit dem RPi 4 mit 8GB RAM existiert) installiert: https://downloads.raspberrypi.org/raspios_lite_arm64/images/
Das wäre nicht supported, weil es leider nicht möglich ist, auf dem Raspberry per DKMS Kernel Module für dem 64 Bit Kernel zu bauen.
Wirklich?
pi@raspberrypi ~
$ uname -a
Linux raspberrypi 5.10.63-v8+ #1459 SMP PREEMPT Wed Oct 6 16:42:49 BST 2021 aarch64 GNU/Linux
pi@raspberrypi ~
$ file /lib/systemd/systemd
/lib/systemd/systemd: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=7c98b8a48f0fdb6de40454977985ccf783e6501a, for GNU/Linux 3.7.0, stripped
pi@raspberrypi ~
$ sudo pivccu-info
piVCCU version: 3.59.6-59
Kernel modules: Available
Raw UART dev: Available
Rasp.Pi UART: Assigned to GPIO pins
HMRF Hardware: HM-MOD-RPI-PCB
Connected via: GPIO (/dev/raw-uart)
Board serial: QEQ0406804
Radio MAC: 0x6CFF03
HMIP Hardware: HM-MOD-RPI-PCB
SGTIN: 3014F711A061A7DA498F9D14
Radio MAC: 0xB37E1F
State: RUNNING
PID: 1906
IP: 172.16.0.130
Link: vethpivccu
TX bytes: 3.94 MiB
RX bytes: 2.95 MiB
Total bytes: 6.89 MiB
Das wäre nicht supported, weil es leider nicht möglich ist, auf dem Raspberry per DKMS Kernel Module für dem 64 Bit Kernel zu bauen.
Wirklich?
Ich sprach vom (offiziellen) 32 Bit Image mit aktiviertem 64 Bit Kernel (per /boot/config.txt). Und dort geht es leider weiterhin nicht wg. dem angesprochenen Problem, dass man keine Kernel Module per DKMS bauen kann. Das 64 Bit Image verwendet meines Wissens nach eigene Kernel Pakete und dort ist auch die komplette 64 Bit Toolchain vorhanden, also komplett andere Vorraussetzungen.
Was bedeutet das nun für ein Standard-32-bit-Bullseye-Raspbian?
Was bedeutet das nun für ein Standard-32-bit-Bullseye-Raspbian?
Da es unter reinem 64-bit funktioniert würde ich meinen 32-bit funktioniert auch.
Was bedeutet das nun für ein Standard-32-bit-Bullseye-Raspbian?
Das u.A. piVCCU nicht laufen kann, wenn man den 64-Bit Kernel aktiviert (und auch alles andere nicht, was eigene Kernel Module braucht, die per DKMS auf den Gerät genaut werden)
Der erste Upgrade-Versuch ist fehlgeschlagen. Die WLAN-Verbindung auf meinem PI3 hat Probleme gemacht - vermutlich aus anderen Gründen als piVCCU. Ich bin zurück zum Backup.
dhcpcd war kaputt: https://forums.raspberrypi.com/viewtopic.php?t=320383
Nachdem ich "wait for network" deaktiviert habe ging das WLAN.
Nun kann ich bestätigen: Die piVCCU-Module laufen auf Raspian bullseye 32-Bit.
Wird Raspbian bullseye schon unterstützt? In der Doku konnte ich es nicht finden.