Posts by Th3Dan

Mit so embedded Mini ITX Systemen habe ich keine Erfahrung, meine Server sind größer. Die CPU hat schon einige Jahre auf dem Buckel, um nur einen Webserver zu betreiben reicht es trotzdem dicke, inkl. gut Luft für mehr. Ist halt natürlich im Verbrauch nicht so sparsam wie ein Pi, wenngleich ichs noch voll im bezahlbaren Rahmen sehe.

Quote from hyle

Weißt Du das sicher, dass das auch bei der neuren Legacy-Version der Fall ist oder um welches Image es sich hier überhaupt handelt? Also ich weiß es jedenfalls nicht.

Jop, hier zusätzlich im Praxistest auf einer Testinstallation:

cat /etc/*release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

$ head -1 /etc/rpi-issue
Raspberry Pi reference 2022-01-28

$ python3 -V
Python 3.7.3

Dort lässt sich das Pip-Problem auch nicht reproduzieren. Gerade deswegen die Frage, was der TE da überhaupt für ein Image hat. Wenn ich es wüsste, würde ich die Frage wohl kaum stellen Das einzige was man bisher weiß ist, dass sein Image recht alt ist (ca 1 Jahr).

Mit Updates kann er das natürlich auf die aktuellste 3.7.3 Version bekommen, aber nicht ohne weiteres auf 3.9. Somit hat er entweder irgend eine andere Distribution, die auf dem RPI aufbaut aber neuere Pakete mitbringt. Oder er hat selbst von Hand was gebastelt, dass er hier nicht erwähnt hat und nun Konflikte verursacht.

Der Ausgabe von dem find Befehl nach spricht stark für Letzteres, da tauchten nämlich u.a. diese Ordner hier auf:

/home/pi/Python-3.9.10
/usr/local/lib/python3.9
/usr/lib/python3.7
/usr/lib/python2.7

Es gibt also Python 3.7, was vmtl. offiziell zum RPIOS 10 gehört. Python 3.9 wurde offensichtlich von Hand ins Homeverzeichnis geladen und wohl auch in /usr/lib kopiert. Dazu gibts auch noch Python 2.7.

Bei so einem bunter Mischmasch von Paketen und händischen Installationen sind Probleme vorprogrammiert. Wenn man händisch was installiert (was ich in Zeiten von Containern eh nicht mehr empfehlen würde, außer zum lernen) sollte man unbedingt die entsprechenden Pakete vorher deinstallieren, vor allem dann wenn man die händischen Installationen in die globalen Ordner legt, die auch von den Paketquellen genutzt werden. Ansonsten fängt es mit solchen Problemen wie dem hier an und spätestens beim Updaten knallt es dann wieder, wenn man sich überhaupt traut da Aktualisierungen einzuspielen.

Ich würde das zumindest aufräumen. Und bevor ich das mache mir die Frage stellen, warum ich Oldstable nutze, wenn ich neuere Pakete brauche. Bullseye kommt nämlich mit 3.9 direkt über die Paketverwaltung. Wenn nichts anderweitig dagegen spricht wäre eine saubere Neuinstallation mit Bullseye am sinnvollsten, dann nutzt du die offiziellen Paketquellen und brauchst gar kein neueres Python von Hand drüber installiern.

Quote from simonz

Macht -3,6 MB.

Das lohnt erstens den Aufwand nicht und zweitens sind das hilfreiche Standard-Tools.

Das waren Beispiele, richtiges Lesen würde helfen Wenn man sich die Mühe macht das Optimieren weiter zu treiben, kann man das recht umfangreiche RPI OS halbieren. Wenn sich das für dich nicht lohnt, ist der Thread und Post dann offensichtlich nix für dich, denn der TE (falls du das auch überlesen hast) möchte aufräumen was er nicht benötigt. Ob er wget/curl benötigt oder sich nicht zumindest von einem davon trennt, kann er wohl besser für sich selbst entscheiden als du

Apache als "Storage Server"? Dir ist bewusst, dass das nur ein Webserver ist? Alleine ist der zum Dateien ablegen ziemlich sperrig, v.a. wenn der nach außen erreichbar sein soll und damit ein Mindestmaß an ACLs dazu kommen. Verbreitet ist dafür eher eine private Cloud wie z.B. Nextcloud.

HDD: Wie schon gesagt brauchst du für 3,5" Platten eine eigene Stromversorgung. Macht das ganze unabhängiger, wird aber ein klein wenig mehr Strom brauchen und du hast halt 2 NTs. Für einen Microserver reicht das zusammen mit dem Pi. Technisch muss es erst mit höheren Ansprüchen (ECC, Leistung etc) zwingend x86 sein. Kommt drauf an was du da erwartest. Es macht ja auch einen Unterschied ob da ein paar Bilder und Dokumente liegen, oder 2 TB verschiedenster privater Daten.

Ansonsten ist die Frage eher, wie realistisch es ist, dass du einen Pi zu einem halbwegs vernünftigen Preis bekommst. Deine Erwartung in allen Ehren, aber Fakt ist: Die Dinger sind seit einiger Zeit schwer lieferbar/teuer. Heute gabs in einem bekannten Shop 200 Stück RPI4 mit 8 GB, die waren in ein paar Minuten ausverkauft. Das Video was gepostet wurde ist gut und zeigt dir nur deine Möglichkeiten auf. Diskussionen ob die Liefersituation und Preise akzeptabel sind oder nicht kann man ewig führen, die bringen dir aber leider alle keinen Pi...

Quote from morob65

ich mache nie ein backup von der gesamten karte, /home und /etc reicht meist, eventuell noch /opt

Wer alle Pakete im Kopf hat und die danach installieren möchte bzw. seine Installationen geskriptet hat, kann das machen. Für alle anderen wird es einfacher sein, ein gesamtes Image zu erstellen, dass man dann ohne viel drum herum nur zurück zu spielen braucht

5,5 GB ist ein Haufen, wenn da nicht ein Großteil von den Anwendungen kommt wie z.B. logs. Das könnte sein, da /var ziemlich groß ist. Ein minimales RPIOs belegt vanilla ein gutes Gigabyte.

Wenn du ein möglichst kompaktes, effizientes OS willst, schau dir mit dpkg -l an welche Pakete installiert sind und deinstalliere jene die du nicht brauchst, das könnte z.B. curl/wget sein. Oder du installierst gleich ein optimiertes OS wie DietPi. Maximale Effizienz erreichst du mit minimalistischen Distributionen wie Alpine, das belegt nur 0,2GB. Ist dafür aber auch kein Debian mehr und nutzt keine glibc, was ggf. ein Problem sein kann.

Auch wenn man das kann sollte man es möglichst lassen. Nicht nur aus Sicherheitsgründen (was ja ggf. in dem Fall noch vertretbar wäre), sondern auch um Konflikte mit den OS-Paketen zu vermeiden.

Wenn /usr/bin in $PATH liegt aber nicht gefunden wird, läuft generell etwas schief. Normal braucht es da kein gebastel mit Aliasen. Seltsam ist auch, dass Python 3.9 installiert ist, obwohl Buster nur 3.7 enthält. Und das Image ist ziemlich alt. Ich würde da mal prüfen was das für ein Image ist und ob du selbst Änderungen vorgenommen hast, die das erklären. Ansonsten kann es evtl noch zu weiteren seltsamen Überraschungen kommen.

Probiere es mal über Python selbst anzusprechen:

# python3 -m pip -V
pip 20.2.4 from /usr/local/lib/python3.5/dist-packages/pip (python 3.5)

Je nachdem was das Paket für Abhängigkeiten hat kann das schon einiges zerschießen, wenn es blöd läuft. Ein Grund warum fachlich gute Anleitungen entsprechend warnen. Dass der gar kein Bild anzeigt ist schon eher unüblich, v.a. wenn es der erste HDMI Port war. So was passiert bei ARM sonst eher bei z.B. Treibern.

Wenn es dich interessiert kannst du das genauer analysieren und zur Not die Karte woanders mounten. Aber das wird mühsam, habe so was auf meinen ersten Servern gemacht. Mittlerweile seit etlichen Jahren keine kaputte Paketverwaltung mehr gehabt, da ich alles auf Container umgezogen habe und auf dem Desktop zu aktuelleren Distributionen gewechselt bin. Dementsprechend ist auf den Hosts neben der Container-Laufzeitumgebung kaum mehr was installiert und statt eines relativ aufgeblähten Raspberry Pi OS/Debian/Ubuntu würde mittlerweile auch ein z.B. schlankes Alpine reichen.

Für die Container ist durch die Abstraktion das OS drunter ziemlich egal, ein weiterer Vorteil der Technologie. Macht eine Migration einfacher und ich muss die Wahl der Distribution nicht von einer vorherigen Analyse der Pakete abhängig machen. Gibt da schon eine Reihe an Vorteilen, sich da mal einzulesen ist definitiv kein Fehler.

Was willst du denn erreichen? Das ist die Datei zur automatischen Vorkonfiguration des OS und der Ausschnitt zeigt die Netzwerkonfiguration. Was du da einstellst kommt 1. auf dein Netzwerk an und 2. was du erreichen willst. Für eine fixe IP solltest du das dort entsprechend deines Netzes konfigurieren. Wenn du keine fixe IP brauchst (z.B. Desktop-Einsatz) kannst du das auch auf den Standardeinstellungen (DHCP) lassen.

Die Version gibts nicht mehr, sieht aus als wären die Paketquellen veraltet. Aktualisiere mal die Paketquellen mit apt update und poste die Ausgabe, vmtl ist da was schief gelaufen, weswegen er die alte Version referenziert.

Quote from martij

Habe zwar schon mal was ähnliches gefragt, allerdings gin's dabei um Version 9. Das auszuprobieren ist mir ehrlich gesagt ein zu grosses Risiko, dass dabei was "geschottet" wird ist äusserst realistisch...

http://coldcorner.de/2018/02/2…r-vollen-desktop-version/

Backups sind Gold wert Bei so was würde ich vorher ein aktuelles Image-Backup der gesamten Karte erstellen. Dann gefahrlos experimentieren, wenns schief läuft und du es nicht in absehbarer Zeit gelöst bekommst Image zurückspielen und wieder ein sauberes System haben.

Du hast einen Paketkonflikt von InfluxDB, da du zahlreiche Drittanbieter-Repositorys verwendest. Ich würde da heutzutage gar nicht mehr viel dran rum basteln sondern gleich Container (z.B. Docker) nutzen. Damit kannst du NodeJS, Grafana und InfluxDB in einzelnen Containern betreiben, die sauber voneinander isoliert sind. Solche Konflikte kann es daher im Gegensatz zu einer klassischen direkten Installation nicht passieren und die Technik hat richtig eingesetzt noch einige weitere Vorteile.

Mit PiShrink kannst du unter Linux ein Image auf die tatsächliche Größe reduzieren und dadurch auch auf eine kleinere Karte zurück spielen, sofern die Karte mindestens so groß ist wie die belegte Größe. Das geht mit PiShrink ziemlich leicht. Mit dd wäre es auch kein Problem das auf jedes andere Block-Device zurück zu spielen wie z.B. SSDs.

Apple nutze ich nicht, musst du selbst mal schauen was dein Apple Backup-Programm macht. Im besten Falle ist das bereits ein Abbild oder es gibt da zumindest eine Möglichkeit das als Image zu exportieren, dann könntest du das mit PiShrink machen wie beschrieben.

Wohin du das zurück spielst ist egal so lange der Bootloader entsprechend konfiguriert ist. Wahrscheinlich USB Boot je nachdem wie du die angebunden hast:

Hallo,

ich betreibe eine Adafruit 64x32 RGB LED Matrix an einem Raspberry Pi 3 B+. Dafür habe ich zwei Micro-USB Netzteile: 1x4A für die Matrix und 1x3A für den Raspberry Pi. 4A entspricht der empfohlenen Dimensionierung für eine LED-Matrix in dieser Größe.

Mein Grundsätzlicher Gedanke ist, beides (Matrix + PI) an EINEM Netzteil zu betreiben. Dies muss dann natürlich stärker sein, ich würde mindestens 7A ansetzen. Ab 6A wird es mit fertig verbauten Netzteilen inkl. Gehäuse bei 5V schwierig, ich habe aber das Mean Well MW LRS-35-5 gefunden. Es liefert 5V und 7A. Ist zwar ein Einbaunetzteil, aber so wie ich das sehe müsste ich nur an L/N und den Nulleiter ein Kabel mit Schuko-Stecker anschließen und an V+/V- hab ich meine 5V Ausgangsspannung. Dann noch einen Schutz über die Kontakte, sodass man diese nicht versehentlich berühren kann, und das ganze sollte sicher betreibbar sein. Zusammen mit Display + Pi wird es auf einer Holzplatte verschraubt, auf der sich Pi + Bildschirm befinden.

Mit solch einem Micro-USB Kabel könnte ich den PI direkt über seine Micro-USB Schnittstelle anschließen, ohne Bastelleien mit den GPIO-Pins (wo scheinbar die Sicherheitsschaltungen nicht greifen). Also eine saubere Sache soweit.

Geplant wäre also, dass ich die Stromversorgungs-Pins des Micro-USB Kabels für den Pi an V+/V- des Netzteils anschließe. Eben so die +/- Kontakte der Matrix.

Gedanken dahinter: Vereinfachung, weniger Redundanz und höhere Effizient (vor allem wenn das im Dauerbetrieb läuft).

Meine Frage: Spricht etwas dagegen, das in der Form umzusetzen? Vor allem hinsichtlich Schutzschaltungen: Brauche ich eine Schutzschaltung für den recht hohen Strom von bis zu 7A des Netzteiles hinsichtlich des RPI?

Wie sieht es aus, wenn ich die gleiche Konstellation betreibe, aber mit einem 5V 12A Netzteil an dem 1x RPI und zwei jeweils 64x32 Matritzen angeschlossen sind?