gddrescue dauert ..., microSDXC SanDisk mit bad-sectors und -aereas wiederverwenden nach mke2fs -c? Maßnahmen Schreibvorgänge zu reduzieren und zu kontrollieren.

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Hallo,

    ich habe den raspi 3B+ (debian stretch raspbian) wohl nicht gut vorbereitet, als ich ihn für Intel® Mesh Commander vorbereitete, ohne mich sehr mit dem raspi zu befassen.

    Jetzt musste ich erfahren, dass man Vorbereitungen trifft, um das Schreiben auf die microSD zu verringern um die Lebensdauer etwas zu verlängern, wie z.B. /var/log per smb/cifs oder besser nfs zu mounten, also remote auszulagern, Schreibzugriffe in /var/run etc. nach /tmp per /tmpfs in den RAM zu verlagern, Partitionen mit noatime mounten und so weiter. FZum Monitoring der Schreibzugriffe kann man wohl iotop -oPak verwenden. Das gibt es aber wohl nicht für LibreELEC? Nur htop?

    Hier würde ich mich freuen, wenn ihr das ergänzen könntet.

    Ich frage mich gerade, ob es Sinn machen könnte die microSD, nach dem ich den Inhalt per gddrescue gesichert habe mit mke2fs -c zu formatieren – '-c' für die Nutzung der badblock infos um die defekten Blöcke kennzuzeichnen und auszusparen, und dann das reparierte image (fsck) darauf wiederherzustellen.

    Die andere Frage: Wie sind eure Erfahrungen, wie lange eine 'Datenrettung' per gddrescue auf einer defekten microSD card dauert? Ich habe so 24-30h überschlagen.

    Außerdem frage ich mich, ob mein raspi4 B+ mit LibreELEC und Kodi da von Haus aus besser prepariert sind.

    Sieht danach aus.



    gddrescue session

    Broken Corrupted Raspberry Pi SD Card

    Iarsin pastebin, microSD corrupt

    Einmal editiert, zuletzt von Iarsin (3. September 2020 um 23:18)

  • gddrescue dauert ..., microSDXC SanDisk mit bad-sectors und -aereas wiederverwenden nach mke2fs -c? Maßnahmen Schreibvorgänge zu reduzieren und zu kontrollieren.? Schau mal ob du hier fündig wirst!



  • Ich frage mich gerade, ob es Sinn machen könnte die microSD, nach dem ich den Inhalt per gddrescue gesichert habe mit mke2fs -c zu formatieren – '-c' für die Nutzung der badblock infos um die defekten Blöcke kennzuzeichnen und auszusparen, und dann das reparierte image (fsck) darauf wiederherzustellen.

    Besser mke2fs -cc, siehe < man mke2fs >

    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. In einem solchen Fall musst Du die Daten aus dem Image File einzeln auf das neue Ext4 Filesystem (unter Aufrechterhaltung der Dateirechte, Link- und ACL-Logic) kopieren.

    Servus !

    RTFM = Read The Factory Manual, oder so


  • Hallo, vielen Dank für die Antworten!

    Zitat

    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?

    Zitat

    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

    Einmal editiert, zuletzt von Iarsin (4. September 2020 um 17:49)

  • Ich bin selbst nur Linux Amateuranwender und habe ddrescue, oder dessen Gnome Frontend gddrescue noch nie installiert. Demgemäss habe ich auch keine man-page, aus der ich vorlesen könnte.

    Ich kann auch keine exakte Verarbeitungsdauer für die verschiedenen Badblockmodi nennen.

    Servus !

    RTFM = Read The Factory Manual, oder so

  • Also was ich schreiben kann ist, es gibt eine CRC Fehlerkorrektur die läuft praktisch immer wenn etwas von einem Datenträger gelesen wird. Es wird immer eine Fehlerkorrektur ausgeführt. Was ddrescue macht ist sie probieren rückwärts und Vorwärts bitweise mittles CRC Fehlerkorektur die Daten zu retten. Ist Das """Loch""" zu groß und die CRC Fehlerkorrektur kann nichts mehr korregieren ist finito leider. Ich kann mich an ein Musik CD erinnern die ich eine Wochlang Retten wollte und es kam tatsächlich ein Lied von der Münchner Freiheit raus.

  • 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.

    2 Mal editiert, zuletzt von Iarsin (5. September 2020 um 02:14)

  • 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.

    2 Mal editiert, zuletzt von Iarsin (6. September 2020 um 14:57) aus folgendem Grund: [em] vs. [i] Typo

  • Aber was ist den so besonderes an LibreElec das man da retten muß :)

    Man könnte das Wertvolle gewonnnen Image erst mal woanders hinkopieren nur zur Sicherheit. Und das Image mounten und auch die einzelnen Partitionen einzeln (gemountetes wertvolles Image) die Partition mit e2fsk repaieren dann müssten ja diese ""badblocks"" verschwinden.

    PS: Ich denke jetzt: also: es liegt ein Image von einer geretten sdcard vor?

    Das von ddrescue erstellt wurde. Also das kann man nicht einfach wieder auf sdcard schreiben. Man müsste einen 1:1 Kopie machen mit rsync. Also die Daten vom (wertvollen) Image auf eine neue Sdcard Partition schreiben mit rsync und cp.

    hier mal ein Beispiel: ( ohne diese badblocks aus dem geretten Image auf die neue Karte zu schreiben, kann auch Blödsinn sein es auf die Tour zu kopieren :) )

    Code
    rsync loop/* loop1/ -r --append --progress -l -D -o -g
    cp -p --attributes-only -r -v loop/* loop1
    
    #symlinks (in loop/ müssten mit rsync copiert werden (hab das aus einem alten Script von mir Keine Garantie)

    Der Ordner loop ist eine gemountete Partition vom (wertvollen) Image.

    Der Ordner loop1 ist die gemountete Partition von der neuen sdcard

    2 Mal editiert, zuletzt von det_lev_da (6. September 2020 um 16:51)

  • 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/questions/1199…pberry-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/documentation/…mages/README.md
    https://ubuntu.com/blog/how-to-in…berry-pi-imager
    https://ubuntu.com/tutorials/how-…y-pi#1-overview

    Zitat

    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/raspb…ure=arm64+raspi

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

    Einmal editiert, zuletzt von Iarsin (6. September 2020 um 17:02)

  • 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.stackexchange.com/questions/9859…04-with-netplan

    2 Mal editiert, zuletzt von Iarsin (6. September 2020 um 20:33)

  • sorry: das $ Zeichen ist der Anfang einer bash variable, die Zeile hab ich nur schnell aus dem einem Skript kopiert :)

    Hast du das Image, welches von ddrescue erstellt wurde noch?

    (Am besten irgendwo sichern, sprich wohin kopieren und md5sum vergleichen)

    Wenn ich es jetzt richtig verstanden habe hast Du eine neue sdcard mit Ubuntu erstellt so wie es auch auf der alten sdcard war?

    Das ist gut!

    hab gerade in meiner bash history kpartx gefunden.

    Also kpartx (sudo apt install kpartx) kann dieses gerettet image von ddrescure mounten. Also ich hab mir das jetzt so vorgestellt:

    Wir löschen den Inhalt der 2ten Partition komplett damit dort keine Datei mehr ist und kopieren einfach den Inhalt der 2ten Partition vom geretteten Image mit rsync und cp wie oben gepostet auf die sdcard.

    Also:

    #vorbereiten zum mounten

    sudo kpartx "geretet_image_von_ddrescue.img" -a

    # Jetzt wird es schwirig das loop device zu finden um es zu mounten.

    # unter /dev/mapper/loop...p2 müsste das device sein

    # (z.B: /dev/mapper/loop1p2 oder /dev/mapper/loop2p2 ... oder ..... oder)

    # ich nehme /dev/loop1p2 hier im Beispiel

    # wir wechseln nach /mnt

    cd /mnt

    sudo mkdir loop

    sudo mount /dev/mapper/loop1p2 loop

    # Die sdcard 2te Partition mounten wir auf loop1

    # Erst mal schauen wie das dev device sich nennt.

    # Da muss man 2 Ausgaben vergleichen.

    sudo blkid|awk -F':' '{print$1}'

    # Jezt die Sdcard einstecken (Usb-Sdcard-Reader)

    # Nochmal eingeben

    sudo blkid|awk -F':' '{print$1}'

    # Es müssten nun Zeilen hinzugekommen sein

    # Ich nehme hier im Beispiel /dev/sdb2 <---- die 2 steht für die 2te Partition

    mkdir loop1

    mount /dev/sdb2 loop1

    #jetzt die 2te Partition der sdcard löschen (alle Dateien und Ordner)

    sudo rm -r loop1/*

    #kontrolle

    ls -l -a -h loop1


    So und jetzt den rsync Befehl von oben ausführen

    Sollte diese Sdcard nicht booten, muss auch die 1te Partition des Images /dev/mapper/loop1p1 auf die erste Partitin /dev/sdb1 kopiert werden.

    Der kpartx Befehl geht schnell und ist einfach.

    Das Image könnte man auch mit losetup einbinden und anschließend mounten.

    Aber kpartx ist einfacher und schneller.

    Es ist nur ein Versuch wie ich mir das vorstellen würde :)

  • 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/manpages/artfu…/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.

  • Mir ist es auch schon passiert, dass ein sdcard nach ddrescue defekt war.

    Aber ich gehe davon aus das die ersten 50Bytes??? (das weiß ich nicht genau) die Partitiontable ist, wenn die hinüber sind ist die sdcard auch Schrott :-).

    Was man eben bei der rsync Methode beachten sollte ist das die /etc/fstat mit den richtigen UUID's angepasst wird. Hat z.B die neu sdcard und die 2te Partionion eine UUID von 1234567 und das mit rsync eingespielte /etc/fstab ein UUID Eintrag von abcdef, muss eben abcdef mit 1234567 ersetzt werden.

    Aber ich bin echt froh das ich auf eine SSD umgestigen bin. Und auch noch das glück gehabt hab das ich kein USB3 Hub brauch mit eigener Spannungsversorgung. Hab eine alte USB3 Fesplatt (mobil mit Kabel) entkernt und eine SSD eingesteckt geht ohne Zusätzliches Netzteil bei mir (die anderen USB Ports nichts angeschloss bis auf Tastatur-Maus dongle.

    Das was du mit der "auslagerung" ins Ram machen willst, hatte ich auf einem gerooteten Smartphone, mit dem Ergibniss die Sdcard war ok :) aber das RAM im Smartphone was kaputt. Das Ubuntu auf dem Smartphone (chroot-Methode) hatte die Aufgabe 1 Million mal ein Bitcon Ei zu klicken und natürlich einfache Rechenaufgaben lösen, dass es wirklich kein Robot ist :) :) mit gocr den frambuffer abgefragt. Naja 1 Million klicks hat es geschaff, den Preis bekam ich nur nicht. Bei 2ten Anlauf kam Plötzlich das RAM Bauteil sei kaputt hahahahahaha Die Sdcard ist noch gut gewesen :)

  • 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.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!