Debian Log-Files werden zugemüllt mit kernel-Commands
-
@homoran sagte in Debian Log-Files werden zugemüllt mit kernel-Commands:
wie machst du das?
bein1GB ist üblicherweise bein10 Instanzen SchlussIst ein Master Slave System. Nur 4 Instanzen laufen auf dem Raspi3 (Master), der Rest auf dem Raspi4 (Slave)
Die Diskussion wegen buster/bullseye hatten wir schon mal.
Im Raspberry-Imager wird aber auch noch eine aktuelle Buster-Version angeboten
Ja, ich muss den Schnitt zum bullseye natürlich bald mal machen und dann möglichst auch Master/Slave-Rolle tauschen, aber warum sollte das für kernel-Log-Fehler verantwortlich sein? -
@tottbeck sagte in Debian Log-Files werden zugemüllt mit kernel-Commands:
Die Diskussion wegen buster/bullseye hatten wir schon mal.
Da gibt's nix zu diskutieren.
-
@tottbeck sagte in Debian Log-Files werden zugemüllt mit kernel-Commands:
Ja, ich muss den Schnitt zum bullseye natürlich bald mal machen
Die Tage wird schon das Nachfolgerelease 'Bookworm' Debian12 erwartet, 'Bullseye' verabschiedet sich also im Sommer 2024 und die Übergangsphase dahin startet mit Release von Debian 12.
-
"sudo apt dist-upgrade -y" (noch mit buster) bringt
Preparing to unpack .../13-raspberrypi-kernel_1%3a1.20230509~buster-1_armhf.deb... Adding 'diversion of /boot/kernel.img to /usr/share/rpikernelhack/kernel.img by rpikernelhack' dpkg-divert: error: cannot copy '/boot/kernel.img' to '/usr/share/rpikernelhack/kernel.img.dpkg-divert.tmp': failed to read (Input/output error) dpkg: error processing archive /tmp/apt-dpkg-install-uzKoHr/13-raspberrypi-kernel_1%3a1.20230509~buster-1_armhf.deb (--unpack): new raspberrypi-kernel package pre-installation script subprocess returned error exit status 2Evtl. ein Problem mit der SD-Card ? Ich werde mal die kernel.img überschreiben.
-
Ne, neue sd Karte
Dann kennst du jetzt auch den Grund für die Kernel Meldungen -
Richtig. Und dann halt direkt auch ein noch unterstütze Version installieren.
-
Ich habe des Raspi 3 nun mit bullseye und iobroker mit aktuellem npm/node neu aufgesetzt. Das dauerte zwar ziemlich lange trotz Backup, aber nun läuft fast alles wieder. Was mir aufgefallen ist: Die GPIOs gehen nicht mehr, da habe ich ein paar Kontakte an Relaiskarte im Schaltschrank angeschlossen (Türklingel, Garagentor .. ).
Ich habe die bisher über Systeminfo-Adapter angesteuert, welcher wohl über WiringPi (gpio write x) arbeitet.
Da WiringPi nicht mehr im bullseye vorhanden ist und auch nicht (oder nur indirekt) nachinstalliert werden kann muss ich mich wohl um Alternativen bemühen. Per "raspi-gpio"-Kommandos müsste es funktionieren, aber die verwenden einen anderen Syntax, den ich im Systeminfo-Adapter anpassen müsste.
Das war mit ein Grund warum ich ein ansonsten lauffähiges System nicht mal eben portieren wollte. Irgendetwas ist dann immer. GPIO läuft aber jetzt wieder mit WiringPi Nachinstallation.
Die Speicherkarte war übrigens eine SanDisk-Industrial 8GB. Hat aber nach ca. 3 Jahren trotzdem die Grätsche gemacht. -
wiringpi sollte eh nicht mehr verwendet werden.
-
Post unter falschem Beitrag
-
@tottbeck
Wahrscheinlich ist im Debian Image der Treiber für raspi gpio nicht enthalten.
Durch Installation von wiringpi wurde der Treiber über die Abhängigkeiten wieder installiert.Das kapseln von Funktionalität in Docker Container ist mittlerweile mein Ansatz.
Das Host Betriebssystem so original lassen wie möglich. Alle software in ein oder mehrere Docker Container packen.
Und alles kann unabhängig voneinander ohne Probleme aktualisiert werden.
Die ganzen Abhängigkeiten der Container zum Host betriebssystem oder Hardware in Docker Compose Dateien dokumentiert -
echad@chet:~ $ apt policy pigpio pigpio: Installed: (none) Candidate: 1.79-1+rpt1 Version table: 1.79-1+rpt1 500 500 http://archive.raspberrypi.org/debian bullseye/main arm64 Packages echad@chet:~ $Ist halt eine library von/für Raspberry OS und kommt daher auch aus deren Repo.
-
@thomas-braun sagte in Debian Log-Files werden zugemüllt mit kernel-Commands:
wiringpi sollte eh nicht mehr verwendet werden.
Danke für den Hinweis. WiringPi wird nicht mehr maintained und ist daher verständlicherweise rausgeflogen. Funktional bieten die anderen GPIO-Lösungen soweit ich sagen kann keinen Unterschied. Ich werden mich wohl eh über kurz oder lang von den Relaiskarte verabschieden und dafür Shellys oder ähnliches verwenden. Ist so einfach besser pflegbar.
