Posts by McDotter

Mal ehrlich, ich kann mit "Bookworm" (welchen Version ist das noch mal? Die Namen und Vetsionsnummern ins Lexikon aufzunehmen wäre mir sehr hilfreich) und den ganzen anderen Namen NULL anfangen, ich geb normalerweise die Versionsnummer an (ihr werden nicht erleben, dass ich von mir aus auf die Idee käme, Ubuntu mit "Namen" zu adressieren. Da ist es das gleiche Drama...)

Von daher weiß ich nicht, ob es sich überhaupt lohnt, das aufzunehmen (würde eh fast niemand in meiner Liste finden... die ist wohl viel zu groß geworden, und scheint von den "Neulingen" auch kaum jemand zu lesen - will das denen auch nicht verdenken, wir sind alle nur Menschen , die sich gerade in Not lieber mitteilen als zu lesen)

und das spezielle Problem: 32bit, wenn 64bit erwartet werden, hat eine überschaubare Lebensdauer. Aber wer davon nichts weiß, wird verzewifeln.

Trotzdem wäre es schön, wenn wir erfahren könnten, was da erst mal schief ging.
Dann könnten wir auch besser auf die Fallstricke hinweisen, schließlich wird keiner als "Profi" gebohren und egal, wie oft man so was schon gemacht hat, niemand kann an alles denken.

ich verweiß auch nicht umsonst auf gnome-disks, es ist nicht das mächtigste, aber das bedienerfreundlichste Tool, das ich kenne und trotzdem nicht selbsterklärend.

und dann gibt es so viele Wege zum Ziel...
- per SD oder USB booten, das System clonen und die Partitionen bearbeiten
- am PC die SSD komplett vorbereiten, einbauen und Booten
- nur von Pi und SSD starten und am Livesystem herum frickeln geht so nicht (heißt, das endet normalerweise in ner Katastrophe)

was wir z.B. gar nicht explizit erwähnt haben, weil es jedesmal bei ner Hilfestellung ein Rießenaufwand ist, auf ALLES hinzuweisen und auch einfach die Hilfesuchenden überfordern kann.
Da geht man nur darauf ein, wenn die Rückmeldungrn das nahe legen

Aber ganz ohne Rückmeldungen könnten wir auch gleich "die Unterstützung einstellen" und auf reflexartig schreiben: lies dich ein, es gibt genug Bücher zu dem Thema. Würde sich jeder herzlich bedanken...

ist vielleicht schon "Leichenschändung", aber um Missverständnisse zu vermeiden:

das HifiBerryOS NG (kurz "HBOS NG") basiert auf Raspberry Pi OS Lite und zusätzlichen Packages. Siehe:

GitHub - hifiberry/hifiberry-os at hbosng

Linux distribution optimized for audio playback. Contribute to hifiberry/hifiberry-os development by creating an account on GitHub.

github.com

Tot ist das Projekt nicht, es gab "3,215 contributions in the last year" (Stand 05.2026)

ich bin mal gespannt, ob es irgendwann nen Raspi (also das Original) mit Risc-V-Prozessor geben wird?
Theoretisch wäre der bei gleicher Leistung sparsamer, aber ich geh davon aus, wenn dann die Peripherie mit USB3.2 oder gar USB4 bzw. Thunderbold kommt, spielt das kaum noch ne Rolle...

Generell rate ich mindestens zu einer verschlüsselten Imagedatei (und die dann auf mindestens 2 Systemen vorzuhalten), auf der man alles speichert, was definitiv nicht in fremde Hände gehört.
Auch gegen 2 verschlüsselte Datenträger spricht erst mal nichts (ich kenn ja auch nicht die Bedürfnisse der TO)

=> so lange der Schlüssel und Passphrase auch sicher sind (Thema: Haus zu Fort Nox aufgerüstet und Ersatz-Haustürschlüssel unter der Fußmatte...)
in der fstab als lesbarer Text wäre die Passphrase also "für'n A***", wenn man den jedoch in ner systemverschlüsselten Datei wie gshadow speichern könnte und in der fstab darauf verweisen kann (also in etwa wie der Bitlocker von Windows), dann ist nichts dagegen zu sagen. Ob das unter Linux geht, kann ich nicht beantworten.
Das Vorgehen aus #4 hat - vorausgesetzt, root wäre unverschlüsselt - den Nachteil, dass jeder root werden kann, wenn man von das System auch von einem USB-Datenträger booten kann...

Bei Ubuntu regt mich auf, dass ich als User ohne Authentifizierung an meinen Schlüsselbund komme und alle Passwörter einsehen kann. Da kämen auch die Passphrases von LUKS2-verschlüsselten Devices/Images/Files rein
Die (verschiedenen) Passphrase meiner LUKS2-Imagedateien gibt es nur in meinem Kopf - wehe, wenn ich die vergesse... aber einen Tod muss man ja sterben.

sudo gdisk -l /dev/nvme1n1

...

Main partition table begins at sector 2 and ends at sector 33
First usable sector is 2048, last usable sector is 1953525134
...

und hinten:

...ich erinnere mich, dass ich auf einem Amstrad mit 516kB RAM die Festplatte parken musste, damit mir der MBR nicht flöten ging. Seitdem kann ich mich nicht erinnern, dass ich auf einem intakten Datenträger Partitionen verloren hätte. Aber verkehrt ist es bestimmt nicht, das zu tun, da geb ich dir 100% recht.
Andererseits, wenn ich Daten verliere, wechsle ich lieber den Datenträger aus (weil der dann sehr wahrscheinlich was an der Latte hat).

Laut Liste ist diese SSD voll Raspi-kompatibel.

viel Spaß

Nachtrag:

was auch geht:

nach der Installation (per rpi-imager z.B.) des OS auf die SSD diese manuell partitionieren (heißt root auf gewünschte Größe setzen und die Datenpartition anlegen).

dann den Raspi mit SSD booten und in Ruhe alles einrichten. Das ist mein bevorzugter Weg (allerdings werde ich mit gnome-disks auch Eigentümer der Datenpartition. Alternativ diese neu formatieren, dann biste eh Eigentümer).

Das ist ein Allerweltsweg, der Profi könnte das auch anders.

Und zu [OT] aus #7:

so ruhig, wie es bei neuen Problemanfragen im RPi4- und RPi5-Unterforum derzeit ist, merkt man die Auswirkung mbMn sehr wohl (und ich hab Momente, wo ich mich freue, nicht so oft in die Tischplatte zu beißen wie befürchtet - mein Hauptgrund sind meine Typos auf'm Tablett und weniger trollige Posts )

Um es mal nüchtern mit ner Art Metapher auszudrücken:

Mit dem ersten Atemzug unterliegen Zellen dem unausweichlichen Tod dzrch oxidativem Stress. Um dem zu entgegen, muss nan einfach nie mit dem Atmen anfangen...

AI oder Big Data sind da und geht nicht mehr weg, genauso wie Schokokade, Alkohol, Viren, Trolle und Schlagermusik - und was macht der Mensch: sich anpassen
also was soll's...

Zur Begründung:
fstab ist für jeden lesbar
eine Datei mit der Passphrase sollte für root lesbar sein (vielleicht gibt es da ne Lösung, die könnte evtl. für dein Szenario ausreichen?)

Ich vermute mal, dass man in der fstab die Passphrase hinterlegen kann (direkt oder indirekt).

Nur macht dieses Vorgehen due Nutzung von LUKS völlig sinnfrei und führt nur zur Verschwendung von wertvoller CPU-Ressourcen...

2 USB-Devices, die je max. 0,9A ziehen, werden - theoretisch früher oder später - zu Datenverlusten führen, weil der RPi5 nur max. 1,6A bereit stellen kann - minus alles, was du sonst noch (außer PCI) dran hängst. D.h. der Lüfteranschluß zählt mit.
Da die aufgeführten Samsung SSDs einen großen Cache haben (das ist gesichert, kann man in den Spez nachlesen) und für den Burst-Write auch etwas Strom puffern (das ist eine Annahme, beruht auf dem Fakt, dass der Burst-Write deutlich mehr Strom zieht als USB3 bereit stellt), ist die Wahrscheinlichkeit, dass der oben beschriebene Fall eintritt, unwahrscheinlicher als erwartet - aber eben nicht vollständig ausgeschlossen.
Wenn ich schätzen müsste, würde ich sagen, bei "normaler Nutzung" nach Monaten... (bis Jahren). Ist halt eine Frage der Wahrscheinlichkeit von Extremsituationen. Werden nie so große Mengen an Daten auf beiden Devices hin- und hergeschoben, dass der interne Strompuffer erschöpft wird oder die Controller drosseln rechtzeitig, dann tritt das Extrem nicht/nie ein.
In diesem Fall wäre es trotz Überschreiten der formalen Spezifikation des Raspi sicher.

um da 100-komma-Null% auf der sicheren Seite zu sein, müssten die Sticks entweder weniger als 900mA ziehen (kann man mit dem Befehl "lsusb -v" überprüfen) oder man einenn Stick an einen aktiven HUB hängen.

Zu der Partitionierung von sdb:
zumindest die letzten Sektoren werden unter Garantie frei sein, ich hab auch schon gesehen, dass Datenträger auf den ersten paar kB ungenutzt waren (also auch da ein freier Bereich). Ein Blick mit gnome-disks (ider fdisk) auf die Aufteilung zeigt das auf.

Beim Booten die Tasten ESC, F2, F9, F10, F11, F12, Entf ausprobieren, das sind die Tasten, denen (je nach Gerät) beim Booten Funktionen zugeordnet sind, um ins BIOS/EFI reinzukommen bzw das Bootmedium auszuwählen.

Wenn Windows so konfiguriert war, dass es sich beim Ausschalten in den Tiefschlaf legt statt wirklich herunter zu fahren (was die Standardeinstellung ist), hilft es evtl den Einschaltknopf länger zu drücken.

Na das ist doch schon mal vielversprechend.

Probier besser Lubuntu (statt Ubuntu), dieser Desktop (LXDE) ist schlank und kommt auch mit 4GB und dem Celeron klar (Browsen mit vielen Tabs wird trotzdem schwierig).
Mit gnome-disks (Laufwerke) kannst du einen Blick auf den Datenträger werfen und nachschauen, was da an Partitionen drauf ist. Der Installer ist zudem ein anderer als bei Ubuntu, mit dem würde ich ne Installation versuchen.

viel Erfolg

Wie du schon angeschnitten hast, gegen fehlerhafte (und properitäre) Firmware ist man als Endverbraucher nahezu machtlos. Oder könnte das nicht bezahlen...

Zu dem Gerät gibt es ne ARM und ne Intelvariante...

behauptet zumindest die AI von DuckDuckGo

und dass ich ne AI gefragt hab, zeigt schon mal, dass es kaum Infos im Netz gibt.

Wichtig ist, was für ein Prozessor drin steck.

Aber noch was anderes: hat dein Gerät WSL (Window Subsystem Linux)? Wenn ja, könntest du darüber erst mal testen, ob ein Linux läuft... und welche Infos Linux dann auslesen kann über die Hardware

Meine nüchterne Meinung: lass die Finger davon - im letzten Absatz stehen ein paar Hinweise aus der Praxis...

schon alleine die Infornationen, die du anbietest, sind völlig ungeeignet (für so ziemlich alles - um es unfreundlich und nüchtern auszudrücken).

Wenn ich überlege, ob ein Gerät Linuxgeeignet ist, finde ich zuallererst heraus, welches Windows genau da läuft und welche Prozessorfamilie drin steckt (Intel/AMD oder ARM, bei Risc-V ist aktuell kaum was möglich - aber Risc-V ist sicherlich ausgeschlossen). Davon hast du gar nichts berichtet, aber für Unterstützung sind solcge Infirmationen unabdingbar - in DE ist der Betrieb von Kristallkugeln mit Reichweiten über 10m Reichweute verboten; im Freien dürfen die dann auch nur das 2,4GGz Frequenzband nutzen <Blödel mode off>
Immerhin soll es 64bit sein..

Dann (kurzer Weg) ist das Gerät von einem Linux namentlich (= Gerätecode) unterstützt? wenn Nein, dann sind bis auf "Profies" schon fast alle raus.
Langer Weg - und den gehen die "Profies" (bzw den können sie gehen, wenn es denen danach ist), die z.B. Custom ROMs für ein Smartphone maintainen - die gesamte Peripherie des Gerätes heraus finden (weit mehr Informationen sammeln als nur das, was ein Windows-Gerätemanager ausgibt) und abwägen können, was davon erforderlich ist, um das Gerät stabil zum laufen zu bringen.

Damit man überhaupt einigermaßen Aussicht auf Erfolg hat, sollten auch Erfahrung mit der Installation von Linux-Distributionen und dem Finden, Lesen und Verstehen von Logfiles vorhanden sein.

zu Ubuntu im Speziellen: Ubuntu 24.04 ist da weit weniger zickig als das neuste 26.04 - weil man 26.04 Desktop eher nicht auf älterer Hardware installiert bekommt (HP 255G7 mit AMD 2500U, Medion 220 mit i3 z.B. scheitern beim Installer, immer an der selben Stelle...)
Nachtrag: der Fehler war, dass das Installationsmedium keinen Schreibzugriff für /var/log hatte. Nach Behebung konnte ich auf beiden Systemen 26.04 installieren

Also wenn du einen Test wagen wolltest, versuch dich mit 24.04, wenn die Hardware auf x64 basiert. Bei ARM war schon die Installation auf dem Pi nicht untrivial. Da wärst du besser mit ARMBian dran, falls überhaupt...

Nur so ne Anmerkung am Rande: Ubuntu 26.04 ist "out-of-the-box" gefixt (aber abgesehen von McDotter nutzt das ja keiner - scnr)

Aber im Ernst: "kein Update - kein Mitleid" bzw bitte haltet eure Systeme immer zeitnah auf dem neusten Stand! Und gerade seit KI wird dieser Druck durch neu entdeckte Sicherheitslücken massiv zunehmen.

Immerhin ist Linux eine Welt, in der solche Lücken puplic gemacht werden, propieretäre OS tun das nicht in dieser Offenheit

deswegen ein aktiver USB-HUB (der seine eigene Stromversorgung für die USB-Geräte mitbringt).

der soll zum einen aufzeigen, ob du ein Stromversorgungsproblem hast.

zum anderen, wenn deine Sticks weiter weg vom Raspi sind, ob es dann noch Probleme gibt. In dem Fall wäre die Ursache die Funkwellen deiner Sticks. Dann wäre ein isoliertes FFC-Kabel bzw Aluumwicklung hilfreich.

Der SONOFF USB-Dongle zieht unter Garantie 900mA - siehe "lsusb -v" Ausgabe.
Störungen durch Zigbee sind nur für 2,4GHz WLan und Bluetooth bekannt.

was der Smart HUB zieht, weiß ich nicht, edit: offiziell wird 0,5A angegeben. Der Raspi gibt max. 1,6A bei offiziellem Netzteil für USB her.

häng mal diese Dongles an einen aktiven USB-Hub (und leg den etwas vom Raspi weg) und beobachte, ob die Fehler mit dee SSD dann noch immer auftreten.
Evtl auch das FFC-Kabel mit Alu umwickeln, falls das kein geschirmtes ist.