Bei mir passt das so. Ich hatte mit Sicherheit WLAN in der Konfiguration im Raspberry Pi Imager vorkonfiguriert. Ich dachte zwar das hätte damals gar nicht richtig funktioniert, aber anscheinend doch.
Posts by pgloor
-
-
-
In der Zwischenzeit habe ich mich etwas schlauer gemacht über "stateless" vs. "stateful" Address Configuration, DHCP (IPv4), DHCPv6 vs. SLAAC und experimentiere noch mit verschiedenen Konfigurationen.
Mir ist dabei schnell klar geworden, dass mein gewünschtes Setup mit udhcpc/udhcpc6 in Kombination mit meinem Router nicht funktioniert. Nutze ich anstelle von udhcpc aus der Busybox das dhcp Paket von Buildroot, dann funktioniert es.
Das Thema ist für mich noch nicht abgeschlossen. Das heisst, bitte melden, falls jemand etwas zur korrekten Konfiguration von udhcpc6 sagen kann oder wie sich das Problem mit SLAAC und dem Router als DNS lösen lässt.
-
Ich habe die vergangenen Tage dazu benutzt mich mit Buildroot zu befassen um meinem Pi 1 Model B Rev. 2 (aus ca. 2013 mit 500 MB RAM) neues Leben einzuhauchen. Ziel des Projektes war darauf eine Web-Applikation zu installieren, die ich bereits vor längerer Zeit mit Go (golang) für meinem Pi Zero programmiert habe. Die Web-App sollte im LAN über IPv4 und IPv6 erreichbar sein. Über IPv6 sollte sie auch über das Internet erreichbar sein.
Es ist mir soweit ganz gut gelungen mit Buildroot ein minimales und schnelles Image mit Busybox und ein paar Spezialitäten zu erstellen, die mir für das Projekt wichtig sind. Dazu gehören z.B. kbd für mein Schweizer Tastaturlayout, Zeitzone Europe/Zurich, chrony als NTP-Client, sudo, traceroute6 und tmux. Die Netzwerkkonfiguration erfolgt über den in der Busybox standardmässig installieren udhcpc Dienst.
Das einzige Problem, das ich jetzt mit meinem Projekt noch habe ist, dass mein Home-Router (eine Internet-Box von Swisscom) die IPv6 Adresse nicht kennt. Bei meinem Pi 4 mit Trixie und dem Hostnamen pi4 ist es so, dass der Router, sobald ich den Pi 4 gestartet habe, diesen mit seinem Hostnamen erkennt und dazu zuerst eine IPv4 Adresse setzt. Der Pi 4 ist dann sofort über IPv4 von meinem PC aus mit pi4.home (es genügt auch pi4) erreichbar. Es dauert dann nur noch ein paar Sekunden und er ist auch über die IPv6 erreichbar. Auf dem Router wird dann in den Gerätedaten zum Namen pi4 die MAC-Adresse, die IP-Adresse (v4) und die IPv6-Adresse sowie der Anschluss am Router ausgewiesen.
Bei meinem Pi 1 mit dem Buildroot/Busybox Image ist das leider nicht der Fall. Was IPv4 betrifft so ist das identisch. Mein Pi 1 hat auch eine IPv6 Adresse und ist über diese im LAN erreichbar. Auf dem Router ist sie aber nicht sichtbar, so dass z.B. die Adresse für ein ping -6 pi1.home von meinem PC aus nicht aufgelöst werden kann. Die IPv6-Adresse wird aber in dem Moment im Router auch gesetzt, wenn ich z.B. von meinem Pi 1 aus einen ping -6 auf einen externen Server absetze. Ich bin mir nicht sicher ob das auch bis zum nächsten Neustart so bleibt, aber ich weiss, dass sie wieder verloren geht, sobald ich den Pi 1 mehr als ca. 2 Minuten vom Netz nehme.
Ich hatte dann zusätzlich udhcpc6 installiert, weiss aber nicht wie ich das konfigurieren soll. Meine diesbezüglichen Versuche haben leider keinen Erfolg gebracht.
So wie ich das sehe hat es irgendwie einfach mit dem Router Advertisement zu tun. Ich blicke da aber nicht ganz durch.
Wenn ich die IPv6-Adressen (ip a) und das Routig (ip -6 route) vom Pi 4 mit dem Pi 1 vergleiche so fällt folgendes auf:
Pi 1: die Link Adresse wird aus der MAC Adresse gebildet und die hinteren vier Teile der globalen Adresse sind identisch.
inet6 2a02:1210:XXXX:YYYY:ba27:bbbb:cccc:7a4a/64 scope global dynamic flags 100
inet6 fe80::ba27:bbbb:cccc:7a4a/64 scope linkPi 4: die globale und die Link-Adresse haben keinen sichtbaren Bezug zur MAC Adresse und die hinteren vier Teile sind verschieden.
inet6 2a02:1210:XXXX:XXXX:30dc:bbbb:cccc:1644/64 scope global dynamic noprefixroute
inet6 fe80::3fb6:bbbb:cccc:ba29/64 scope link proto kernel_llVielleicht kann mir jemand mehr dazu sagen und mich in die richtige Richtung lenken.
Für heute gebe ich auf

-
Ich hatte einmal einen kurzen USB Stick von PNY der so heiss wurde, dass mein neuer Pi 2 innert weniger Tage beschädigt wurde. Der Stick war in meinem Fall aber so heiss, dass er sich nicht mehr wirklich anfassen liess, also bestimmt über 60°. Zum Glück hatte ich den Pi und den Stick zusammen beim gleichen Händler gekauft und mir wurde beides problemlos ersetzt. Der ersetzte Stick wurde nicht mehr so heiss, aber ich habe ihn für den Pi trotzdem nicht mehr benutzt.
Von SanDisk habe ich zwei kurze Sticks. Einen ganz kurzen 32 GB (Ultr-Fit?) und einen etwas längeren 16 GB der vorwiegend metallisch ist. Beide lassen sich auch bei längerem Betrieb gut anfassen und ich habe keine Bedenken sie am Pi zu nutzen.
-
Pi-hole fände ich auch nicht schlecht. Du könntest dich dann dafür bedanken, dass dein Netzwerk jetzt werbefrei und sicherer geworden ist

-
Ich hatte auf meinem Linux Ubuntu 24.04 Desktop auch noch den Raspberry Pi Imager 1.8.5 installiert. Damit wurden aber bei der Installation von Raspbery Pi OS Lite (64-bit) Trixie die mitgegebenen Konfugurationsparameter nicht berücksichtigt.
Mit dem neuen imager_2.0.0_amd64.AppImage hat bei mir soweit alles funktoniert.
-
Ich hatte das Ganze in eine Art selbstgebasteltes Rack verbaut (unten SSD, darüber Pi 4). Dadurch hatte ich keinen Zugang zu den USB 2.0 Ports. Das habe ich jetzt verbessert. Aber ich werde zusätzlich eine USB 2.0 Verlängerung verwenden.
-
Ich habe eine kabellose Logitech K270 Tastatur mit einer Logitech M185 Maus mit einem Unified USB Receiver. Ich nutze diese Kombination seit Jahren problemlos bei all meinen PI's die ich mit Raspberry Pi OS Lite betreibe.
Meinen Pi 4 mit 8 GB RAM und dem offiziellen 15 W Netzteil boote ich seit mehr als 2 Jahren direkt von einer 500 GB Samsung T7 SSD die am unteren der USB 3.0 Ports hängt. Im Pi ist noch ein Raspberry Pi 4 Case Fan verbaut. Historisch und Platz bedingt hatte ich den USB Receiver Dongle an den freien Port darüber gesteckt (also ebenfalls USB 3.0, obwohl der Dongle USB 2.0 ist). Das ist bisher immer problemlos gelaufen!
Leider hatte ich neulich wegen eines Software Updates einer Third Party Anwendung ein Problem, da es Konflikte mit der in Bookworm installierten Python Version gab. Da ich das Problem auf die Schnelle nicht lösen konnte, beschloss ich alles neu aufzusetzen und Raspberry Pi OS Lite Trixie zu installieren.
Da ich normalerweise auf dem Pi über SSH von meinem Linux PC aus arbeite, habe ich noch gar nicht bemerkt, dass die Tastatur nicht mehr funktioniert. Erst bei einem anschliessenden Test ist mir das aufgefallen. Ein Blick in dmsg und lsusb hat gezeigt, dass die Tastatur und die Maus erkannt werden. Trotzdem war es nicht möglich irgendwelche Tastatur-Eingaben zu machen.
Ich erstellte dann eine SD Karte mit der gleichen Konfiguration und bootete diese vom SD Card Slot. Die SSD hatte ich vorher vom USB Port entfernt. Jetzt lief alles normal.
Ich steckte die SD Karte in einen USB Adapter und bootete damit über den USB 3.0 Port. Auch damit funktionierte das Keyboard nicht mehr.
Ich steckte den Receiver Dongle auf den oberen der USB 2.0 Ports um und alles lief normal.
Ich bootete wieder direkt von der Samsung SSD, aber dieses Mal mit dem Receiver Dongle im USB 2.0 Port. Auch so funktionierte es.
Das Problem ist also gelöst. Aber was ist die Ursache?
Warum funktionierte es mit Bullyseye/Bookworm aber nicht mehr mit Trixie?
Warum funktioniert es wenn ich den USB Dongle auf den USB 2.0 Port lege? interferenzen mit USB 3.0 und dem Funksignal? Stromverbrauch am gleichen Bus?
Es funktionierte übringens auch, wenn ich den Receiver Dongle an einem aktiven USB 2.0 HUB ansteckte und diesen HUB auf den USB 3.0 Port steckte.
Es nimmt mich einfach nur wunder. Har jemand eine Erklärung?
-
Normalerweise benutze ich für all meine Pi's ein Original-Gehäuse, kein Gehäuse für meinen Pi Zero sowie ein selbstmodifiziertes Originalgehäuse für ein Spezialprojekt mit Sensoren und einer darunter montierten Festplatte.
-
Danke für deinen Bericht. Ich selber nutze meine Pi's fast immer nur mit Raspberry Pi OS Lite ohne Benutzeroberfläche. Ich bin aber immer daran interessiert, von anderen zu erfahren, was sie nutzen um möglichst ressourcen-schonend eine Benutzeroberfläche zur Verfügung zu haben.
Ich habe jetzt mal versucht die Installation von MX Linux auf einem Pi 3 nachzuvollziehen. Ich nutzte auch den Pi Imager und machte dort Voreinstellungen für den Computernamen, den User und das WLAN. Leider funktionierte meine Wireless Logitech Maus nicht. Die Tastatur funktionierte, aber die Tastatureinstellungen waren auch nicht brauchbar.
Bei mir erschien zuerst eine Dielaogbox mit einer Abfrage für die Spracheinstellung und ob Handbücher für andere Sprachen gelöscht werden sollen. Danach kamm die Dialogbox für das Login mit dem von mir gewählten Usernamen. Leider ging das auch bei mir nicht.
Nach einer Weile war mein Pi mit dem von mir gewählten Netzwerknamen über das WLAN erreichbar, so dass ich mich mit meinem vordefinierten Usernamen über ssh einloggen konnte. Ich legte einen neuen Demo User an und startete den Pi 3 neu.
Jetzt hatte ich auch den Demo User zur Auswahl. Wieder kam die Aufforderung zur Spracheinstellung, kurz danach kam eine Abfolge von Fenstern zur Systemkonfiguration. Da die Maus nicht funktionierte, konnte ich nur mit "Weiter" durchhangeln.
Ich nehme an, dase es sich dabei um das von dir erwähnte Installationsscript handelt. Bei mir kam das jetzt bei jedem Neustart. Links oben im Dialogfenster ist mir aufgefallen, dass da etwas von Life CD (oder ähnlich) stand und rechts davon war etwas wie eine leere Checkbox. Ohne Maus und mit den falschen Tastatureinstellungen konnte ich aber nichts auswählen oder ändern.
Für mich habe ich es jetzt wieder aufgegeben. Ich hoffe, dass du mit dem Problem weiterkommst oder eine andere Möglichkeit für den XFCE-Desktop findest.
-
Aus reiner Neugier: was macht für dich MX-Linux so besonders, dass du das verwenden möchtest? Darunter liegt doch auch nur ein Raspberry Pi OS?
-
Mir ist der Sinn hinter deinem Projekt noch nicht ganz klar. Wozu soll das gut sein und worin liegt der Nutzen? Ob ich die Tools gesammelt in einer busybox oder in den bin-Verzeichnissen der Distro habe ist mir eigentlich egal und bisher sehe ich nicht sehr viel sinnvolle Möglichkeiten die Anzahl installierter Pakete abzuspecken.
Vielleicht wäre das pi-gen Projekt etwas für dich. Ich würde meinerseits jedenfalls meine Energie eher dort reinstecken. In deinem Repo kann ich nichts finden, was ich nicht irgendwie schon kenne und das für mich einen Sinn ergeben würde. Mir fehlt ein Konzept und eine klare Aussage mit einer überzeugenden Vision.
Wie auch immer, ich hoffe, dass du mit dem Pi mindestens so viel Spass wie ich hast und wünsche dir nur das Beste auf dem Weg zur Verwirklichung deiner Träume.
-
Hm... der Zeit voraus. Aber für mich ist das soweit mal ok. Basierend auf Grund meiner Unterlagen habe ich diesen Pi 4 im August 2023 installiert. Seither läuft er rund um die Uhr. Updates mache ich unregelmässig, aber normalerweise mindestens einmal im Monat und meistens gefolgt von einem Reboot.
-
..., aber es hat leider nichts gebracht.
Das ist keine Antwort. Gab es eine Ausgabe?
Was es halt so ausgibt, wenn es nichts gebracht hat. Alles unverändert bei sudo apt update und ansonsten:
Codeuser@pi4:~ $ sudo apt -f install Paketlisten werden gelesen… Fertig Abhängigkeitsbaum wird aufgebaut… Fertig Statusinformationen werden eingelesen… Fertig 0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.Die Lössung ist einfach, wenn man weiss wie
`sudo rpi-update`
Das ist nicht die Lösung.
Für mich war damit das Problem gelöst.
-
Danach bekam ich dann bei einem sudo apt update && sudo apt full-upgrade fogenden Fehler:
Code
Display Moreraspi-firmware (1:1.20250430-1) wird eingerichtet ... stat: die Dateisysteminformation für '/boot/firmware' kann nicht gelesen werden: Datei oder Verzeichnis nicht gefunden Error: missing /boot/firmware, did you forget to mount it? dpkg: Fehler beim Bearbeiten des Paketes raspi-firmware (--configure): »installiertes post-installation-Skript des Paketes raspi-firmware«-Unterprozes s gab den Fehlerwert 1 zurück Trigger für initramfs-tools (0.142+rpt3+deb12u3) werden verarbeitet ... Fehler traten auf beim Bearbeiten von: raspi-firmware needrestart is being skipped since dpkg has failed E: Sub-process /usr/bin/dpkg returned an error code (1)Den konnte ich mit einem sudo apt purge raspi-firmware wieder loswerden.
-
Wenn ich das jetzt unter dem neuen Kernel mache, dann erhalte ich einen Fehler;
Codeuser@pi4:~ $ sudo apt install --reinstall raspi-firmware Paketlisten werden gelesen… Fertig Abhängigkeitsbaum wird aufgebaut… Fertig Statusinformationen werden eingelesen… Fertig 0 aktualisiert, 0 neu installiert, 1 erneut installiert, 0 zu entfernen und 0 nicht aktualisiert. 1 nicht vollständig installiert oder entfernt. Nach dieser Operation werden 0 B Plattenplatz zusätzlich benutzt. E: Internal Error, No file name for raspi-firmware:arm64 -
Danke für den Hinweis, aber es hat leider nichts gebracht.
Die Lössung ist einfach, wenn man weiss wie

Das aktualisiert die Firmware und den Kernel. Danach ein Reboot und alles war wie erwartet.
Hinweis aus dem Lexikon hier im Forum: rpi-update ist ein Befehl, den man niemals verwenden sollte (wenn man nicht genau weiß, was man damit tatsächlich macht)!
-
Mit ChatGPT habe ich keine Erfahrung, was die Code Generierung betrifft.
Hingegen hatte ich in beschränktem Umfang unter VSCode mit Github Copilot gute Erfahrungen gemacht, wenn es darum ging einfache repetitive Aufgaben zu lösen. Also z.B. für Go (Golang) Typen mit JSON Tags oder für Datenbank-Strukturen zu definieren. Aber auch um, ausgehend von bestehendem Code, Unit Tests zu schreiben.
Für komplexeren Code waren meine Resultate fast immer unbrauchbar und haben unter dem Strich für Mehraufwand gesorgt.
Interessant finde ich aber noch Gemini. Da kann ich eine Aufgabe beschreiben und erhalte, wenn die Aufgabe einfach und gut formuliert ist, fast immer ein brauchbares Resultat, das mir zumindest Schreibarbeit abnimmt. Es eignet sich aber auch um über eine Aufgabe zu "diskutieren".
So wusste ich z.B. neulich nicht recht wie ich aus mehreren Dateien, die alle gleichen Inhalt, aber verschiedene Quellen und Dateinamen hatten, Duplikate filtern kann. Ich dachte dabei an MD5 oder SHA-1 Hashes. Gemini meinte aber, dass ich unbedingt SHA-256 benutzen sollte und hat mir eine Begründung geliefert. Als ich antwortete, dass ich das nicht brauche, weil ich noch andere Kriterien habe mit denen ich sicher stellen kann, dass es sich nicht um Duplikete handelt, hat mir Gemini dann doch das entscheidende Kriterium geliefert um mich von einer SHA-256-Lösung zu überzeugen. Zum Schluss hat Gemini mir dann gut brauchbaren Code als Ausgangslage für meinen Duplikatsfilter geliefert. Ich konnte die vorgeschlagene Funktion einfach in meinen Code einbauen.
Was in diesem Zusammenhang mit Gemini und Go zu erwähnen ist, dass Gemini häufig Code mit veralteten Funktionen und Bibliotheken vorschlägt (oft deprecated). Wichtige neue Funktionen, die sich erst in den letzten 6 Monaten etabliert haben, scheint Gemini überhaupt noch nicht zu kennen.
-
Was könnte eigentlich der Grund dafür sein, dass auf meinem Pi4 mit 64-bit Raspberry Pi OS Lite (bookworm) kein Kernel Upgrade stattfindet?
user@pi4:~ $ uname -a
Linux pi4 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux
user@pi4:~ $ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 12 (bookworm)
Release: 12
Codename: bookworm
user@pi4:~ $ sudo apt update && sudo apt full-upgrade && sudo apt autopurge
Holen:1 file:/home/peter/Downloads/mariadb-10.11.7-debian-bookworm-arm64-debs ./ InRelease [1’698 B]
Holen:1 file:/home/peter/Downloads/mariadb-10.11.7-debian-bookworm-arm64-debs ./ InRelease [1’698 B]
OK:2 http://archive.raspberrypi.org/debian bookworm InRelease
OK:3 http://security.debian.org/debian-security bookworm-security InRelease
OK:4 https://download.docker.com/linux/debian bookworm InRelease
OK:5 http://deb.debian.org/debian bookworm InRelease
OK:6 http://deb.debian.org/debian bookworm-updates InRelease
Holen:7 https://dl.cloudsmith.io/public/caddy/stable/deb/debian any-version InRelease [8’266 B]
Es wurden 8’266 B in 2 s geholt (4’002 B/s).
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Alle Pakete sind aktuell.
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Paketaktualisierung (Upgrade) wird berechnet… Fertig
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
user@pi4:~ $