Posts by Iarsin

    Ich werde noch mal versuchen per cifs share weitere OS images einzubinden, die dann aktueller sind.

    Dazu müssen sie mit dem universial-image-generator-for-berryboot mit sqashfs vorbereitet werden. https://github.com/agoldcheidt…e-Generator-for-Berryboot

    Was die pdates anbelagt, so habe ich die mirrorlist.pacnew in mirrorlist umbenannt und sudo pacman -Syyu aufgerufen.
    Warnung: /etc/pacman.d/mirrorlist installiert als /etc/pacman.d/mirrorlist.pacnew

    Das gibt dann allerdings Paketkonflikte, die ich erstmal belassen habe. Ich versuche es lieber mit einem aktuellerem manjaro-image, und vielleicht auch eher auf dem rp4 mit 4GB RAM. Die QT-basierte Desktopversion mit lxqt ist, trotzdem sie sehr leicht wirkt überlastet, was aber wohl eher an firefox und dem javascriptgebrauch von google keep liegt. Die manjaro Version mit lxqt Desktop gibt es auch nicht mehr. Daher werde ich xfce, i3 oder sway ausprobieren. Ich nehme an Gnome und KDE sind zu schwer für den rp3, vielleicht auch für den rp4.

    Danke für den Tipp, direkt mit etcher etc. zu flashen, aber ich experimentiere noch etwas mit NOOBS, PINN und berryboot.

    Oder ich probiere eins dieser images: https://berryboot.alexgoldcheidt.com/images/
    https://sourceforge.net/projects/berryboot/files/os_images/

    Hallo,

    ich habe gestern mal berryboot ausprobiert und gleich alle angebotenen Systeme installiert. Auf dem Raspi 3B+ laggte allerdings das OpenSuSE extrem. Also wandte ich mich Manjaro zu, das im Archiv berryboot-berryboot-20210701-pi4.zip (sha1sum: 0f9c921e5540eaa967ab42f85c10e1669752a626 sha256sum) von der berryboot-website enthalten war.


    Soweit so gut. Auch wenn ich zuerst Probleme hatte, dass die WLAN-Einrichtung auch die eingetragenen DNS füpr das System verfügbar machte, so klappte schlussendlich die Verbindung.


    Leider aber gab es Probleme mit der pamac Paketverwaltung. Sämtliche Mirrors waren nicht erreichbar und es gab entsprechende Fehlermeldungen mit Abbruch und dem Hinweis das System sei aktuell (was wohl nicht sein kann).

    Mit pacman kam ich auch nicht weiter


    Dann habe ich eine aktuelle mirror-list gefunden.



    Damit funktioniert es aber auch nicht.

    Ich nehme mal an, es hat mit meiner Unerfahrenheit mit arch-ähnlichen Systemen zu tun. Ich kenne mich mit pacman einfach nicht aus.

    Merkwürdig, dass nun pacman-mirrors verschwunden ist und mir fällt die Zeile Warnung: /etc/pacman.d/mirrorlist installiert als /etc/pacman.d/mirrorlist.pacnew auf.

    Kann es sein, dass ich da mit relfector ran muss, damit die upgegradeten Mirrorlisten auch übernommen werden?

    Andererseits, wie wirkt sich das aus, denn von 19.06 bis 21.06 ist ja eher ein langer Weg und mit Rolling-Release-Distributionen habe ich keine Erfahrungen. Unter Ubuntu nutze ich LTS-Upgrades.


    Ein weiteres Problem habe ich, mit berryboot auf ein Share von Windows 10 zuzugreifen um die berryboot-images von berryterminal zu installieren. Die Anmeldung scheitert.

    Habe allerdings nun auch bemerkt, dass berryboot eigentlich der Vorgänger von NOOBS oder PINN ist, welche auch distributionsspezifische Kernel und damit auch völlig andere Betriebssysteme als linux-basierte booten können, wie BSD, pan9, RISC OS oder Windows IoT.

    Hallo, ich habe gelesen, der Raspberry pi 4 (und alle anderen) unterstützen kein Wake on WLAN und sind auch nicht über USB (z.b. Funk-Maus) zu starten(?).
    Es gibt Anleitungen für GPIO3 per Taster, wie hier z.B. https://bitreporter.de/raspber…ter-fur-den-raspberry-pi/

    Nun hat mich das auf die Idee gebracht einen Espressif ESP32, ESP8266 oder einen anderen sehr sparsamen WLAN-fähigen Microcontroler mit GPIO dazu zu nutzen, der ständig läuft. Wäre das denkbar?

    Oder andere Ideen?

    Ich habe noch folgende Aussage von einem Rezensenten »Werden USB-2-Anschlüsse benutzt, benötigt man 2 Anschlüsse am Computer, um genug Strom für das Laufwerk zu erhalten, bei USB 3 reicht einer.«

    Ich würde da wohl nicht um einen aktiven Hub herumkommen.

    Gibt es denn Unterschiede der Treiber zwischen ubuntu amd64 und arm64?

    Zur Sicherheit: Mysterium™ sind schlecht zu debuggende Fehler des Raspi aufgrund eines nicht empfohlenen Netzteils, ja? Das hat aber mit einem aktiven Hub wiederum nichts zu tun, oder?

    Auf der LG-Seite steht »Dieser Brenner braucht keinen separaten Stromanschluss: Der Strom kommt direkt über USB, so dass Sie sich ein Kabel sparen können.«

    In den Spezifikationen kann ich aber nichts finden, ob die USB-Stromversorgung des pi4 ausreichen würde.

    Dann habe ich noch das hier gefunden. https://www.raspberrypi.org/fo…iewtopic.php?f=35&t=17877


    Edit: Im Manual steht irgendwas von USB 5V und das hier.

    Quote

    Connecting to computer or A/V Device.
    - Connect the drive to the computer as shown in figure.

    1. Connect the USB 2.0 (Ytype) cable to the drive.
    2. Connect the other end of the USB 2.0 cable to your computer.
    3. The drive may get its power from the PCUSB power. All systems may not meet USB power requirements and full performance may not be achieved. In this case, connect to the USB power cable.

    Ah, okay. Da scheint ein USB-Kabel dabei zu sein mit zwei USB-Steckern an einem Ende, wohl für den Fall, dass die Versorgungsspannung vom Computer nicht aufgebracht werden kann? Dann kann man einen Stecker zur Stromversorgung in ein USB-Netzteil stecken? Y-Kabel? USB 2.0 (Ytype) cable?

    Handbuch

    Hallo,


    was meint ihr? Ich betreibe meinen 42" Plasma-Fernseher von 2010 mit dem pi4 mit LibreElec und Kodi.

    Eventuell würde ich auf 20.10 Ubuntu Desktop umsteigen.

    Könnte das BP55EB40 BlueRay Laufwerk an dem pi4 funktionieren? Sind die Treiber im arm64 Ubuntu funktionsfähig? Reicht der Strom?
    Am Plasma geht ja wohl nur ein USB mass storage (pendrive, USB-Flashdrive, USB-Stick, externe USB-Festplatte(?)), oder?

    LG 42PJ350 42"plasma tv
    https://www.lg.com/nz/tvs/lg-42PJ350-plasma-tv

    LG BlueRay Brenner extern BP55EB40
    https://www.lg.com/de/brenner-laufwerke/lg-BP55EB40

    BlueRay Laufwerk an pi3B+
    Externes DVD-Laufwerk am Rasp 3 B+

    Oh je. Okay, war ja nur eine Idee. Ich frage mich auch was das System macht, wenn ich /var per nfs übers Netz einbinden will und der die Netzverbindung ist plötzlich weg ...

    Ach das mit dem RAM macht ubuntu-server wohl von Haus aus

    Das Wlan geht nun auch. Ich hatte wpa_passphrase ein falsches Passwort übergeben. Hatte hier einen Thread eröffnet. War wohl zu lange vor dem Rechner gesessen.

    Aua. Das Kennwort war falsch, das ich per wpa_passphrase übergeben hatte ...

    Alles gut.



    Apropos /var im RAM auf dem raspi 3B+: Das habe ich nach der Anleitung zur Schonung der microSD selbst in die /etc/fstab eingetragen. Nur reichen die 30MB für /var/tmp nicht für ein Kernel-upgrade aus:

    Ja.

    Mich verwundert jetzt dann doch die unterschiedliche Hardware-MAC-Adresse ...
    Ich war jetzt ein paar Stunden weg. Es ist die Fritz!Box selbst ... Na, dann ...

    Code
    ubuntu@ubuntu-server-rpi3:~$ sudo arp-scan -l
    Interface: eth0, type: EN10MB, MAC: b8:27:eb:b3:04:96, IPv4: 172.16.240.41
    Starting arp-scan 1.9.7 with 256 hosts (https://github.com/royhills/arp-scan)
    172.16.240.3    38:10:d5:73:45:38       AVM Audiovisuelles Marketing und Computersysteme GmbH




    Vielleicht liegt es daran, dass die Fritz!Box kein ordentlicher Accesspoint ist, sondern ein Mesh Ad Hoc Netz? https://de.wikipedia.org/wiki/Service_Set


    Dann ist in der MAC noch das letzte Dupel des Gateway :38 in der Meldung aber :3a ...

    Hallo,

    ich habe ein Problem den internen WLAN-Adapter an die AVM Fritz!Box 7490 zu verbinden/anzumelden. Es wird aber rejected mit CTRL-EVENT-ASSOC-REJECT und CTRL-EVENT-SSID-TEMP-DISABLED.

    Code
    Sep  7 14:36:31 ubuntu-server-rpi3 wpa_supplicant[5132]:
    wlan0: CTRL-EVENT-SSID-REENABLED id=0 ssid="fritz-ggaussling-home"
    wlan0: Trying to associate with SSID 'fritz-mywlan-home'
    wlan0: CTRL-EVENT-ASSOC-REJECT bssid=38:10:d5:73:45:3a status_code=16
    wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="fritz-mywlan-home" auth_failures=33 duration=120 reason=CONN_FAILED

    Mit wpa_cli oder wpa_supplicant komme ich auch nicht weiter. Eine alte funktionierende Konfiguration sieht nicht viel anders aus als unter Ubuntu-Server.

    netplan /etc/netplan/50-cloud-init.yaml


    Ich habe wpa_passphrase zur Verschlüsselung genutzt, zusätzlich hier verändert.



    Die Mac-Adresse weicht ab.

    Die Vorgehensweise mit losetup und kpartx ist veraltet und wurde durch losetup und partprobe und anschließendem herkömmlichen mounten abgelöst. Es mag aber sein, dass kpartx trotzdem praktischer ist. Das hatte ich auch schon mal verwendet.

    Ich habe inzwischen ubuntu-server 20.04 LTS auf den raspberry pi kopiert. Da habe ich allerdings Probleme mit wpasupplicant und netplan (davon habe ich keinen plan ...). Bei der netpaln Konfiguration hilft yaml lint, denn ähnlich python ist die Anzahl der Leerzeichen in der config wichtig (intend).

    https://wiki.ubuntuusers.de/Netplan/
    http://www.yamllint.com/
    http://manpages.ubuntu.com/man…rtful/man5/netplan.5.html
    https://raspberrypi.stackexchange.com/a/98636

    Es gibt einen Authorisierungsfehler. Mit Netzkabel läuft aber alles

    Code
    Sep  7 00:20:44 ubuntu-server-rpi3 wpa_supplicant[2989]: wlan0: CTRL-EVENT-SSID-REENABLED id=0 ssid="fritz-iarsin-home"
    Sep  7 00:20:44 ubuntu-server-rpi3 wpa_supplicant[2989]: wlan0: Trying to associate with SSID 'fritz-iarsin-home'
    Sep  7 00:20:52 ubuntu-server-rpi3 wpa_supplicant[2989]: wlan0: CTRL-EVENT-ASSOC-REJECT bssid=38:10:d5:73:45:3a status_code=16
    Sep  7 00:20:52 ubuntu-server-rpi3 wpa_supplicant[2989]: wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="fritz-iarsin-home" auth_failures=14 duration=120 reason=CONN_FAILED


    Ich habe mir gedacht, ich nutze nur noch die .bash_history und /etc usw. aus dem gddrescue image des raspbian, um die Dienste dann auf dem ubuntu-server auf dem raspberry pi 3B+ zu realisieren.

    Jetzt werde ich als nächstes also die Vorschläge, die ich gefunden habe umsetzen, die sich auf die Lebensdauer und Belastung der microSD beziehen, das war ja im rasbian nicht eingestellt. Ich habe da unburden-home-dir gefunden und werde nach der Anleitung aus Broken corrupted raspberry pi microSD card | Raymii's Blog gehen und /var vielleicht per nfs über meinem internet server einbinden.

    Bei mir kommen da nur auto-ip 169.254.253.0/24

    Code
    $ nmap -sP $ip/24 -oG - |grep "Status: Up"| wc -l
    256
    $ nmap -sP $ip/24 -oG - |grep "Status: Up"| grep -v '169.254.253' | wc -l
    0

    https://en.wikipedia.org/wiki/Link-local_address


    Ah, okay. Habe mir das nicht so genau angesehen $ip hat nichts mit einer mir unbekannten Option für nmap zu tun, sondern hier soll ich die eintragen. Mit leerer variable kommt da nur Müll raus.

    Lösung für die Netzanbindung per WLAN für Ubuntu-Server ist netplan https://raspberrypi.stackexcha…server-18-04-with-netplan

    Nein es ist raspbian mit der Installation des Intel ME Servers Mesh commanders.

    Ehrlich gesagt war ich nun etwas besorgt über den Raspi 3B+ selbst, da nun SD Formater auch die "neue" microSD kein zweites mal formatieren wollte, und es eigentlich beim ersten mal hätte klappen müssen, da kam aber nur der schwarze screen. gut danach hatte ich es mit dem drüberkopieren vermasselt. Nun dachte ich, wegen der ganzen Nacht grüne LED, dass die möglichweise schreibenden Zugriffe diese SD nun auch gehimmelt haben könnten. Ich machte mir auch wegen des HDMI Anschlusses und der Grafik Sorgen, da der Fernseher no signal zeigte.

    Ich habe dann per Pi Imager nun einfach Ubuntu nochmals drübergebügelt, trots der SD Formatter Probleme die microSD zu verweigern. Ich habe die beiden Dateien in /boot der ext4 Partition abgelegt. Nun bootet das Ding doch, aber die Zugangsdaten, die ich im Netz dazu finde lassen mich nicht einloggen ... u:pi, p:raspberry geht nicht, ubuntu:ubuntu auch nicht. Weiß da wer was? (Pi Imager v1.4, Ubuntu LTS 20.04 x64)?

    Die IP taucht im Netz nicht auf, wenn ich arp -a ausführe. ssh klapp demnach auch nicht.

    Code
    $ arp -a | grep 'b8-27-eb-e6-51-c3'



    Oder ändert sich die MAC mit der Neuinstallation? (virtuelle vnet devices?) Glaube ich eher nicht. b8-27-eb-e6-51-c3 wird in der fritz.box ausgegraut in der Mesh-Anzeige und Sicherheit dargestellt.

    Na, erst mal muss ich einlogge können ...

    LibreELEC habe ich auf dem Raspi 4 mit Kodi installiert. Das hatte ich nur als Beispiel wegen der default /tmpfs und /var/log Geschichten in /etc/fstab erwähnt, die die microSD-Abnutzung verringern.

    Was mich noch angetrieben hat war, herauszufinden, ob ein zweites image, das ich mit gddrescue mittels optionen -nN erstellen würde, auch sauber sein würde, ohne die microSD durch den Scraping Durchgang weiter zu strapazieren. Wie lange es gedauert hätte. Außerdem finde ich es nun merkwürdig, das sie plötzlich ganz kaputt sen sollte. Aber das ist mit dem scraping wohl schon nach wenigen Stunden vielleicht 3-4 passiert. Keine genaue Ahnung.

    EDIT: Ich werde es dann vielleicht später noch mal mit
    ubuntu:ubuntu sowie pi:raspberry (z und y vertauscht, amerikanisches keyboard layout)
    https://askubuntu.com/question…-using-raspberry-pi-image

    Nachdem ich ein bisschen gewartet hatte ging es jetzt mit ubuntu:ubuntu.

    Okay, es ist ja nicht Pi OS (raspbian) https://www.raspberrypi.org/do…stalling-images/README.md
    https://ubuntu.com/blog/how-to…e-new-raspberry-pi-imager
    https://ubuntu.com/tutorials/h…r-raspberry-pi#1-overview

    Quote

    When prompted to log in, use “ubuntu” for the username and the password. You will be asked to change this default password after you log in.

    https://ubuntu.com/download/ra…&architecture=arm64+raspi

    Allerdings ist nichts eingerichtet, weder netz, ssh, noch das keyboard-layout oder das Datum.

    Hallo,

    Ich noch mal (wahrscheinlich abschließend zum Thema microSD).

    Was mich nun doch wundert, ist, dass die microSD Karte nun, nach sehr erfolgreicher Datenrettung PROMPT tot ist. Oder hat gddrescue -r1 (retry 1 time) sie gekillt? Schließlich gab es irgendwann zu Anfang der letzten 24h etwa, nie mehr erfolgreich Leseoperationen.

    So ganz kann das aber auch nicht sein, da ich direkt nach erfolgreichem Abschluss nochmals gddrescue aufrufen konnte. Obwohl, der kernel hatte die device node ja schon bereitgestellt (/dev/sdj), was nun nicht mehr gelingt.

    Es wurde ja höchstens 1MB zusätzlich gesichert.
    1. Durchlauf (unterbrochen)



    2. Durchlauf mit -r, ebenfalls unterbrochen.


    3. Durchlauf ohne Option abgeschlossen (Finished)


    4. Durchlauf direkt nach der Erfolgreichen Beendung, ohne Optionen.


    Danach habe ich losetup -D ausgeführt, vielleicht fehlte aber der reboot, um die nodes auch unter /dev zu löschen ...
    Habe die sdcard heraus gelegt und nicht mehr angerührt.

    Beim nächsten mal war sie dann eigentlich schon tot, unter ubuntu und hier unter FreeNAS. Oder ist nur ein write protect bit(?) gesetzt, dass sie unansprechbar macht? Ich denke aber linux und FreeBSD kümmern sich nicht darum und lesen sie trotzdem sie derartig von Windows vor zugriffen geschützt ist.

    FreeNAS:

    sdcard SanDisk 16GB microSDHC I 10 A red/grey dead

    In FreeNAS mit 3 verschiedenen Cardreadern getestet




    Eigentlich wollte ich noch mal mit gddrescue -nN schauen, wie lange die Rettung dauert ohne Trimming und Scraping, und wieviel das dann sichert, denn es ist wohl die schonendere Art. Beim Parameter -N bin ich mir nicht sicher man ddrescue. Aber wohl zu spät.

    Ich hätte dann die sdcard so formatiert, indem ich in einem erstn Schritt die ddrescue map in eine badblock list mittels ddrescuelog umgewandelt hätte ...

    Code
    root:~# ddrescuelog --list-blocks=- http://ddrescue.map/ > badblocks.lst
    root:~# mkfs.vfat -l badblocks.lst /dev/<sdcard block device file>



    Siehe man ddrescue, man ddrescuelog, man mkfs, man mkfs.vfat.
    Nun habe ich eine 32GB microSD, ebenfalls SanDisk, HC I 10 aber ohne A mit Raspberry Pi imager v1.4 mit Ubuntu LTS 64bit überschrieben.
    Diese habe ich zuvor mit dem SD Formatter 5.0.1 formatiert, und zwar nicht Quick, sondern overwrite format.

    Ich hatte Ubuntu Server 20.04 LTS mit Pi imager v1.4 drauf geschrieben, dann versucht ihn an meinem Fernseher anzuschließen, das einzige HDMI Anzeigegerät (sonst nur VGA und DVI), das ich zur Verfügung habe.

    Leider blieb der Fernseher schwarz, und die zuvor mit der defekten microSD ausschließlich tote grüne ACT LED blinkte beim Start, und dann alle paar Sekunden ein paar mal, wohl weil auf die sdcard zugegriffen wurde. Die ACT POST codes laufen doch darauf hinaus, dass danach die ACT LED dunkel bleibt, oder?

    Gut, danach hatte ich noch den NOOBS ordner auf die vfat Partition per drag&drop geschoben und dabei einige Dateien mit gleichem Namen in der vfat Partition der Ubuntu LTS (mit Raspberry Pi Imager 1.4) überschrieben und in der ext3 Partition im /boot Verzeichnis per ext2fd gemounted (Ext2 Volume Manager for Windows), wpacompliant.conf und ssh angelegt. Ich hoffe das ist grundsätzlich richtig, bis auf das Übertragen des NOOBS Zip-Inhaltes auf die vfat Partition?

    Jedenfalls bleibt es schwarz und nun brennt nach dem booten(?) die grüne ACT beinahe im Dauerbetrieb und blinkt nur manchmal dadurch, dass sie im Millisekundenbereich vielleicht m,al nicht an ist, um danach direkt dauernd weiter zu leuchten.

    Nun eine Frage: Muss die Partitionstabelle "resettet" werden (z.B. durch Alexander Beugs USB Image Tool, oder SD Formatter 5.0.1) , um nun das Ubuntu LTS Image nochmals drauf zu schreiben, und es diesmal mit den beiden Konfigurationsdateien im /boot-Verzeichnis zu versuchen? Oder funktioniert Etcher, USB Image tool oder Raspberry Pi Imager v1.4 for Windows auch ohne diese Vorbereitung?

    Eine weitere Frage: Nach meinem Verständnis sollte man beim zweiten Formatierungsvorgang, so er überhaupt nötig sein sollte, mit der Option Quick, anders als bei der ersten Vorbereitung, richtig liegen, da ja schon mit Overwrite Format und CHS format size adjustment nach badblocks gesucht wurde und diese neue Karte in Ordnung ist.

    Hier hat es ~31h40min gedauert auf der 16GB SanDisk Ultra microSDHC I 10 A1


    Unter /var/log haben sich 4,82 GB kern.log und messages angesammelt, ausschließlich wegen der Lesefehler seit Juli ...

    fsck musste nur bei einem ext4 das Journal einlesen und bei den vfat Partitionen ein Dirty-bit entfernen, also nichts reparieren. Demzufolge müssten trotz der vielen badblocks alle Dateien okay sein.



    losetup, partprobe und loop mount


    fsck.e2fs der linux Partitionen


    fsck.vfat der msdos Partitionen.


    Hallo, vielen Dank für die Antworten!

    Quote

    man mke2fs -c [...] If this option is specified twice, then a slower read-write test is used instead of a fast read-only test.

    Ich dachte mir, da Schreibvorgänge die NAND-Speicher belasten, das wäre vielleicht keine gute Idee, und ich verwende ddrescue, um die badblocks zu beachten. Vielleicht gibt es da sogar eine Methode beim zurückspielen des images, diese bad areas und -blocks auszulassen?

    Quote

    Das hilft aber garnichts, wenn Du ein Image wieder darüberflasht, da dann die Bytes vom ersten bis zum letzten Sektor des .img Files auf die SD Karte geschrieben werden. Damit bekommt die SD wieder die Badblocklist des .img Files geflasht und das mühsam erstellte ext4 Filesystem wird überschrieben.

    Ja, ansonsten per file, z.B. mittels rsync, oder eben die microSD anderweitig verwenden.

    Ich frage mich auch, ob Scraping failed blocks... (forwards) etwa nur bei magnetischen Datenträgern Sinn macht, oder ob es auch bei Flash-Speicher sein kann, dass da mal ein Speicherzustand kippt, wenn man nur oft genug liest?

    Jedenfalls ist das sicherlich mit 6B/s wesentlich langsamer und selbst bei -r1 scheint gddrescue bei dieser microSD extremst lange zu benötigen. Ich weiß nicht, ob das heute noch fertig wird, denke aber schon. Möglicherweise reicht ein Durchlauf mit -nN und einmal von der anderen Richtung mit den gleichen Optionen und ohne -r?

    Wird mke2fs -cc dann ebenso lange dauern wie das scraping in ddrescue?


    https://pastebin.pl/view/c219bc4c