Posts by Mart

Quote from VeryPrivat

Danke, dass Du die Lösung mit uns teilst, dann kann leicht sein, dass das jemand anderen auch mal passiert

Wie mir gerade ... danke!

Am Rande: Nunmehr kommt nach apt update:

N: Für das Depot »http://raspbian.raspberrypi.org/raspbian bookworm InRelease« wurde der »Suite«-Wert von »testing« in »stable« geändert.

Örgs - nun ist es zu spät. Die meisten RPi sind umgestellt, via dist-upgrade. Das war relativ schmerzfrei.

Die Wlan-Interfaces hat er dabei nicht umbenannt.

Einen Haken gibt es bei den key-Signaturen des Systems, da zickt anschließend (also beim übernächsten Mal) apt update mit einer Warnung. Das löst man am einfachsten, in dem man die Schlüssel (Tipp aus dem Web) kopiert:

cd /etc/apt
cp trusted.gpg trusted.gpg.d/

Hallo,

auf einem RPi läuft ein Wlan-AP mit USB-Antenne. Heute machte ich das Upgrade auf bookworm. Der AP lief dann zunächst nicht. Im Augenwinkel las ich in den Tiefen des Web, dass man über raspi-config die Wlan-Ländereinstellung explizit auf DE stellen müsse. Das tat ich, der Ap läuft wieder.

Aaaaber

hostapd /etc/hostapd/hostapd.conf
nl80211: kernel reports: Match already configured
nl80211: Could not configure driver mode
nl80211: deinit ifname=wlan1 disabled_11b_rates=0
nl80211 driver initialization failed.
wlan1: interface state UNINITIALIZED->DISABLED
wlan1: AP-DISABLED
wlan1: CTRL-EVENT-TERMINATING
hostapd_free_hapd_data: Interface wlan1 wasn't started
--------
wlan1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.4.1  netmask 255.255.255.0  broadcast 192.168.4.255
        ether 1c:bf:ce:f4:2d:4b  txqueuelen 1000  (Ethernet)
        RX packets 974  bytes 122625 (119.7 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1014  bytes 893990 (873.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Was halte ich denn von dieser Ausgabe? (Der AP läuft, wie gesagt.) (Was soll ich an Ausgaben zeigen?)

RTFM

Quote from 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.

Quote from bombom

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.

Das Problem konnte ich lösen: autoremove löscht firmware-ralink und firmware-misc-nonfree. Ein

Quote

apt install firmware-ralink

und folgendes Reboot führte dazu, dass der AP sofort wieder verfügbar war.

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

Quote

==> messages <==

Jul 12 02:36:49 Wlan-2 kernel: [ 313.334211] ieee80211 phy0: rt2x00lib_request_firmware: Info - Loading firmware file 'rt2870.bin'

Jul 12 02:36:49 Wlan-2 kernel: [ 313.334333] rt2800usb 1-1.2:1.0: Direct firmware load for rt2870.bin failed with error -2

Jul 12 02:36:51 Wlan-2 kernel: [ 315.584553] ieee80211 phy0: rt2x00lib_request_firmware: Info - Loading firmware file 'rt2870.bin'

Jul 12 02:36:51 Wlan-2 kernel: [ 315.584672] rt2800usb 1-1.2:1.0: Direct firmware load for rt2870.bin failed with error -2

Jul 12 02:36:53 Wlan-2 kernel: [ 317.835841] ieee80211 phy0: rt2x00lib_request_firmware: Info - Loading firmware file 'rt2870.bin'

Jul 12 02:36:53 Wlan-2 kernel: [ 317.835962] rt2800usb 1-1.2:1.0: Direct firmware load for rt2870.bin failed with error -2

Jul 12 02:36:55 Wlan-2 kernel: [ 320.084375] ieee80211 phy0: rt2x00lib_request_firmware: Info - Loading firmware file 'rt2870.bin'

Jul 12 02:36:55 Wlan-2 kernel: [ 320.084494] rt2800usb 1-1.2:1.0: Direct firmware load for rt2870.bin failed with error -2

Jul 12 02:36:58 Wlan-2 kernel: [ 322.334844] ieee80211 phy0: rt2x00lib_request_firmware: Info - Loading firmware file 'rt2870.bin'

Jul 12 02:36:58 Wlan-2 kernel: [ 322.335040] rt2800usb 1-1.2:1.0: Direct firmware load for rt2870.bin failed with error -2

Display More

Die letzten Zeilen von /var/log/syslog

Quote

==> syslog <==

Jul 12 02:33:46 Wlan-2 systemd[1]: hostapd.service: Control process exited, code=exited, status=1/FAILURE

Jul 12 02:33:46 Wlan-2 hostapd[819]: nl80211: Could not set interface 'wlan0' UP

Jul 12 02:33:46 Wlan-2 hostapd[819]: nl80211: deinit ifname=wlan0 disabled_11b_rates=0

Jul 12 02:33:46 Wlan-2 hostapd[819]: nl80211 driver initialization failed.

Jul 12 02:33:46 Wlan-2 hostapd[819]: wlan0: interface state UNINITIALIZED->DISABLED

Jul 12 02:33:46 Wlan-2 hostapd[819]: wlan0: AP-DISABLED

Jul 12 02:33:46 Wlan-2 hostapd[819]: wlan0: CTRL-EVENT-TERMINATING

Jul 12 02:33:46 Wlan-2 hostapd[819]: hostapd_free_hapd_data: Interface wlan0 wasn't started

Jul 12 02:33:46 Wlan-2 systemd[1]: hostapd.service: Failed with result 'exit-code'.

Jul 12 02:33:46 Wlan-2 systemd[1]: Failed to start Advanced IEEE 802.11 AP and IEEE 802.1X/WPA/WPA2/EAP Authenticator.

Display More

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

Quote

interface=wlan0

#driver=nl80211

ssid=.....

channel=13

hw_mode=g

# Optionale Einstellungen

supported_rates=10 20 55 110 60 90 120 180 240 360 480 540

# DRAFT-N

ieee80211n=1

wmm_enabled=1

# COUNTRY

country_code=DE

ieee80211d=1

# WPA

macaddr_acl=0

auth_algs=1

ignore_broadcast_ssid=0

wpa=2

wpa_passphrase=.....

wpa_key_mgmt=WPA-PSK

wpa_pairwise=TKIP

rsn_pairwise=CCMP

Display More

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 mithttps://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/releases/buste…se-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.

Dann wünsche ich viel Spaß beim upgrade auf buster ohne apt upgrade.

Gibt es auch eine nähere Erklärung - oder wolltest Du auch mal was sagen?

Quote from Linus

Gar keine! Problem gelöst.

Schick. Danke!

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/blog/buster-th…on-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!

Quote from Bernd666

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.