Posts by Mart

    RTFM

    Eine Partitionstabelle wird mit parted, fdisk, cfdisk, cgdisk, gdisk, sfdisk, sgdisk verändert, je nachdem, was < apropos partition > alles anzeigt. Das Gnome Frontend Gparted verwendet imho parted. Zur Umrechnung von Bytes/Sektors/Blocks wird nur von Kopfrechnergenies auf die Beiziehung eines Taschenrechners verzichtet.

    Wo hackt es denn konkret ?

    gparted schafft es (aktuelles BS wie U18.04 vorausgesetzt) bei SSD, die Grenzen selbstständig zu berechnen. Ich war nun der (offenbar irrigen) Ansicht, dass das auch für SD-Cards gilt. Das Verkleinern der ext4 war auch kein Problem. Beim Vergrößern der ersten Partition verkackte er grandios.

    Ja, gparted nutzt im Unterbau parted.


    Ich habe nun den Vorschlag von bombom aufgenommen: Neues System aufsetzen, dann rm -r auf der zweiten Partition, dann vermittels rsync die alte zweite Partition in die neue zweite Partition übernommen - auf den ersten Blick sehe ich keine Fehler - läuft.


    @alleWarner

    Selbstverständlich habt ihr alle Recht: Das macht man nicht. Das ist langfristig ein hohes Risiko.


    Dagegen steht aber: Nicht jeder sieht sein Hobby darin, jedes Jahr mehrere RPi und weitere Systeme völlig neu aufzusetzen - eine Minderheit nutzt die auch für ernsthaftere Dinge. Und da wäre dann das Argument der Langlebigkeit einer Installation ...


    Ja, es ist immer eine Abwägung. Man muss wissen, was man tut. Egal welcher Weg: Am Ende des Tages verantwortet man es selbst.


    Danke an alle, die mit Ideen halfen.

    Das ist eine Möglichkeit, ich hätte eher die neue SD-Karte genommen, manuell die Partitionen angelegt und dann alles 1:1 von der alten SD-Karte auf die neue Karte kopiert

    Ich vermute, den Weg über rsync. - Ok, wegen UUID muss ich fstab beachten. Was wären noch weitere Stolpersteine?

    Diese Erkenntnis hilft leider wenig: Ich habe hier ein System, was ich damals sehr zeitnah vermittels Distributions-Upgrade auf Buster hebelte - unter RPi3 läuft das prima.


    Ein simples Umstecken der SD-Card scheitert: RPi4 blinkt einmal grün, fährt aber nicht hoch.


    Ok, mal fix eine parallele Neuinstallation eines nackten Raspian-light/Buster - wo sind denn da Unterschiede? Schau mal an: in der Partition /boot sind deutlich mehr Dateien (die bisherigen unterscheiden sich aber nicht).


    Ok, kann man simpel kopieren. Das scheitert aber auch: Die von Debian-9 definierte Größe der Partition für /boot ist zu klein, läuft voll.


    Hmmm. Was sagen denn die internationalen Kollegen? Die sagen tatsächlich was - nämlich, dass es durchaus geht! Man möge doch bitte die unter /boot einzuhängende Partition entsprechend vergrößern.


    Leider sagen sie nicht (oder ich bin zu doof zur Recherche) wie man zuerst die zweite Partition verkleinert und danach die erste Partition vergrößert: Ich bin jedenfalls grandios gescheitert: Ich hatte die SD-Card an einem Ubuntu-18.04 und werkelte mit gparted rum.


    Die Frage ist schon von Interesse:

    Bei komplexen Installationen (hier: FHEM mit zig notwendigem Zusatz-Gedöhns) zeigt ein simples diff auf die beiden "dpkg --get-selections "*" hordenweise fehlende Pakete an. Das tut sich doch niemand freiwillig an, der nicht dafür bezahlt wird oder schon Rentner ist.

    @ChristPi

    Danke für Deinen qualifizierten Beitrag.


    Der Kühlturm sieht ja lustig aus, das nebenbei.


    Ich sehe die Sache genau so wie Du - wollte mich aber mit den hiesigen Regulars nicht anlegen. Ich will nicht erzählen wo ich arbeite: Aber in einem Rechenzentrum kommt man ja auch nicht auf die Idee, alle Prozessoren und Platten bis kurz unter die Temperaturgrenze zu fahren. Sondern man will die Elektronik nicht unnötigem Stress aussetzen. Insofern kommen da passive Kühlkörper drauf - kostet fast nichts und hat durchaus Wirkung.


    Ja, Du hast recht: Ich muss geduldiger werden. Wegen des Upgrades auf Buster dachte ich an einen zeitgleichen Umstieg auf PRi4 wegen meines FHEM: Das könnte schon mehr Leitung vertragen. - Aber Du hast recht: Erstmal in den Urlaub und dann entspannt die Entwicklung verfolgen.

    Hallo allerseits,


    ich nahm mir meinen ersten Wlan-Accesspoint vor. Da vorab klar war, dass das Upgrade im Vollbetrieb nicht durchlaufen würde, beendete ich alle möglichen Services auf die eher brachiale Art: kill [PID]. Das Update lief bis auf einen Punkt problemlos durch, den Punkt habe ich mir leider nicht notiert: Ich MEINE, dass das irgendwas mit "firmware" war und bin sicher, dass es mit apt --fix-broken install weiter ging: Das Paket wurde neu installiert. Ansonsten lief das Upgrade ohne Probleme durch.


    Leider kommt der AP nicht hoch, wlan0 kommt nicht an den Start:

    Die letzten Zeilen von /var/log/messages


    Die letzten Zeilen von /var/log/syslog


    /etc/hostapd/hostapd.conf sieht so aus (ja, die Driver-Zeile war auskommentiert)


    Also da fehlt in meinem Verständnis der Driver, der bei Stretch noch in irgend einer Paketquelle enthalten war.


    Hinweis: Der AP läuft auf einen USB-Stick mit zwei großen Antennen.


    Nun bin ich ratlos und weiß nicht weiter.
    Was muss ich tun?

    Ich hatte /etc/apt/sources.list und /etc/apt/sources.list.d/raspi.list umgestellt. An dieser Stelle gibt es auch keine Sonderlocken bei mir: Keine anderen Bezuglisten, Erweiterungen oder in dieser Richtung.


    Ansich ist das auch eine stinknormale Standard-Installation, Netz über eth0. Also völlig normal. Einzig abweichend ist FHEM (ok - und alles was konkrete FHEM-Installationen so nach sich ziehen; das kann sehr viel sein: Perl mit recht vielen Modulen, JSON, der ganze JavaScript-red-Dingens-Zauber, vmtl. Hardware-Schmonzes für die vielen Antennen-Sticks usw.). FHEM als solches ist ansich pflegeleicht und hockt in nur einem Verzeichnis.


    Allerdings -das macht stutzig- sah ich keinen Abbruch, keine Fehlermeldung. Nur ein dist-upgrade, welches nach recht kurzer Zeit der Meinung war, dass es fertig sei. Ohne Fehlermeldung.


    Ich gebe zu, dass ich nicht so unbedingt Lust habe, die Situation nochmals nachzustellen. Mir war wichtig, das bei mir aufgetretene Verhalten im richtigen Forum anzusprechen, quasi zu dokumentieren. (Die Masse der FHEM-Installationen läuft auf RPi.)

    Ich danke für die interessante Diskussion.


    Zur Kühlung:

    Ich selbst stehe auf dem Standpunkt "wenn es nichts nützt - so schadet es doch nicht". Von daher bin ich weiter an Kühlkörper-Vorschlägen (und wo ich die nun hinkleben muss) interessiert.


    Zu messen (CPU-Temperatur) ist da im Moment wenig: Ich habe ja noch keinen RPi4. Bei RPI3 und RPI2 brachte das deutlich was. - Danke für den Hinweis mit dem Vollkörper-Kühlkörper: Der geht leider bei der Konstruktion nicht: Auf GPIO hockt quer ein Riegel. Und daran noch eine Drahtantenne.


    Bzgl. des USB-C-Problems weiß ich zu wenig. Da ich im Arbeitszimmer nicht Steckdosen und Steckdosenleisten ohne Ende habe, nutze ich u.a. Mehrfach-Netzstecker. Es wäre halt schön, wenn alles so funktioniert wie gedacht.

    Ich bin zu doof, einzelne Sätze zu zitieren. Also anders:


    1) Beim meinem FHEM-RPi sind alle USB-Ports sowie der GPIO mit allen möglichen Antennen für die verschiedensten Funkprotokolle (Hausautomation kennt sehr viele) belegt. Damit kommen recht zügig jede Menge Daten rein. Vieles (Daten von Nachbarn) wird von FHEM sofort verworfen - aber genau genommen zunächst transportiert und angefasst.

    Auf dem RPI (3b) läuft so wenig wie irgend möglich. Daher ist der beschriebene Teil kein Problem.


    FHEM wird über Clients bedient: Browser, Apps usw. FHEM bereitet Daten in grafischen Oberflächen auf uns spielt stark mit html5. Kritisch wird es da durchaus schnell - ich schildere ein Beispiel:

    Ich schaue mir die Grafik meiner Wetterstation an: Da sind in einer Grafik Grafen für mehrere Temperaturen, Sonnenintensität, Regen, Wind. Diese werden mir für einen Tag angezeigt. Allerdings kann ich die Grafik navigieren: Beispielsweise kann ich in Schritten verkleinern: Mehrere Tage, Woche, Monat, das komplette Jahr ... und an solchen Stellen kommt richtig Last auf den Prozessor. Mehr Hauptspeicher und sehr schnelle SD-Card (vorhanden) ist da auch immer nett - aber primär ist dann der Prozessor unter Last.


    2) Ich bitte um Hinweis, welche Kühlkörper konkret in Frage kommen. Und wo ich diese hinkleben muss.


    3) Heise kommt gerade mit https://heise.de/-4467303 - aktuell ist bei RPI4 USB-C kaputt. Welche Relevanz das für mich wirklich hat - kann ich nicht übersehen. Vermutlich ist es klug, noch zuzuwarten?

    Um mal etwas Druck herauszunehmen (an dem ich nicht unschuldig bin - ich bitte um Vergebung, wollte niemanden angreifen):


    Ja, selbstverständlich hatte ich das System auf den aktuellen Stand der Dinge gebracht. Selbstverständlich habe ich danach die SD-Card (dd if=undsoweiter) gesichert. Trotzdem trat bei mir (System mit FHEM) das Phänomen auf, dass ohne apt upgrade vor apt dist-upgrade das große Upgrade ein höchst unvollständiges war. Ich schreibe das jetzt eher für Leute, die in eine ähnliche Falle tappen und in Tagen, Wochen, Monaten im Web dann suchen.


    Bei mir selbst war das dann kein Problem: Update - und alles nochmal - wie schon genauer erklärt.


    Weitere Anmerkungen:

    1) Bei Debian tauchen die ersten deutschen Upgrade-Handreichungen auf, z.B. hier: https://www.debian.org/release…md64/release-notes.de.pdf - auch allgemein ganz hilfreich.


    2) Ein Upgrade meiner Wlan-Accesspoints stirbt, wenn die Dienste nicht gestoppt werden. Hier würde ich meinem Vorredner zustimmen wollen: In dieser Konstellation ist es wohl besser, dass System sauber neu aufzusetzen.

    So - erster Bericht:

    Basis war eine tiny-Installation von Raspian-9, also ohne grafische Oberfläche; Zugang via ssh.


    Tja - was soll ich sagen? Wer klugsheißert, der wird sofort bestraft: Im ersten Anlauf habe ich das Upgrade gegen die Wand gefahren.


    Ansich gilt ja die Regel: Man denkt nicht - sondern hält sich strikt an die Installationsvorgabe, hier also https://www.raspberrypi.org/bl…-new-version-of-raspbian/

    Und die ist leider falsch!


    Ich wunderte mich so vor mich hin: Das Upgrade ging ja schnell ... was sagt denn /etc/issue? Oh, da steht was mit 9.


    Fehler ist folgender, dort steht:

    Quote

    2. In a terminal,

    sudo apt update

    and then

    sudo apt dist-upgrade


    Das ist natürlich falsch. Es fehlt upgrade, richtig wäre also

    sudo apt update

    sudo apt upgrade

    sudo apt dist-upgrade


    Dann folgend selbstverständlich ein

    sync && reboot

    sudo apt autoremove


    Den Zirkus aus Pkt.6 (apt purge) kann man sich sparen, wenn man eine tiny-Version von Raspian zu laufen hat: Nichts davon ist installiert.


    Also fhem scheint schon mal zu laufen. Schrittweise werde ich mir später weitere RPi mit Sonderlocken (Wlan-AP, Kamera usw) vornehmen. Falls es irgendwo hakt melde ich mich.

    Hallo allerseits,


    mein FHEM (Hausautomation, siehe dort) läuft derzeit auf einem RPI 3b. Nun liebäugele ich mit einem RPi 4b, da würden mir 2GB Hauptspeicher direkt reichen.


    Wie hält man es denn bei RPi4 mit passiven Kühlkörpern?

    * Welche nimmt man? Amazon-Link wäre hilfreich.

    * Wo klebt man die genau hin?


    Bitte bedenken: Ich bin der mit den beiden linken Händen ... ich mache es dann genau wie ihr mir sagt. Aber ihr müsst es mir bitte genau erklären.


    Danke!

    die dringende Empfehlung der Raspberrypi.org ist: Nimm ein neues, sauberes Image!!

    Naja. Diese Empfehlung gibt es seit der Erfindung von Distributionen. Und oft ist sie einigermaßen weltfremd: Wenn man einen Zoo von Raspberry und anderen Debian-Systemen hat, die dann noch real etwas arbeiten, dann müsste man schon hauptberuflich sysadmin sein um jedes System neu aufzusetzen.


    Heute abend werde ich mir mein erstes System (fhem) vornehmen und dann ggf. berichten.

    Diese Zitatfunktion hier ist der letzte Husten.


    @RTFM

    Danke für Deinen höchst hilfreichen Beitrag.


    @Zentris

    Danke für den Hinweis und Bestätigung Anker - bestelle ich sofort.


    Multimeter ist kein Problem, da liegt eins im Schuppen. Und wenn das hin ist, kaufe ich halt eins - also am Geld scheitert es nicht.


    Das Problem ist eher - also vermutlich soll ich bei den angeschlossenen Geräten messen, ob 5V ankommen, ja? Und da beginnt mein Problem: Ich weiß nicht, wo ich die beiden Prüfspitzen aufsetzen soll.

    den solltest du nehmen können.

    Ich habe den fast baugleichen von Anker. Bringt locker > 2A pro Port.


    Wichtig: Miss die Spannung, wenn alle 3 PasPi dran hängen...

    Zentris

    Anker sagt mir doch was? Von denen wollte ich den 2-Port für meine Frau, da aber nur zum laden.


    Meinst Du diesen hier? https://www.amazon.de/dp/B00MVHKTZQ (Affiliate-Link)


    Spannung messen ... welche, wo und wie? Bedenke bitte, dass ich von mehr als 30 Jahren zuletzt eine Spannung maß.

    Ich kenne nur Ladegeräte mit mehrene USB-Ports und die sind alle Sch...:stumm:

    Ich habe sowas befürchtet.


    Ich hatte den hier im Auge: https://www.amazon.de/dp/B00GYLYQ40/ (Affiliate-Link)


    Drei Sachen sollen ran: RPi-Zero mit offizieller Kamera, Feinstaubsensor (hat eine kleine Pumpe), Selbstbausignalduino. Das mit dem Hub habe ich nicht verstanden: einfach ein kleiner passiver USB-2.0 Hub? Oder wie meinst Du das?


    Nein, basteln kann ich leider nicht.