Wird nach dem Entfernen und Einsetzen der SD-Karte nicht gebootet?

Ich habe Arch Linux mit Win32DiskImager auf meiner SD-Karte installiert. Wenn ich das RPi heruntergefahren, die Karte herausgenommen, eingesetzt und das RPi erneut gestartet habe, funktioniert alles einwandfrei. Aber wenn ich ein vollständiges System-Update mit pacman mache pacman -Syu, gibt es ein Problem. Wenn ich das RPi herunterfahre und wieder hochfahre, ist das kein Problem, aber wenn ich es herunterfahre, entferne ich die Karte, lege sie ein und starte das RPi, es kann nie wieder hochfahren, warte nur immer auf den Regenbogen-Startbildschirm. Ich muss auch nicht die SD-Karte entfernen, nur genug, um die Stromversorgung für 30 Sekunden zu unterbrechen (bis die Kondensatoren vollständig entladen sind) und das RPi zu starten, und der gleiche Fehler tritt auf.

Ich versuchte , das Raspberry Pi-Firmware - Paket aktualisieren , indem zu deaktivieren IgnorePgk = raspberrypi-firmwarein /etc/pacman.confDatei, und dann das vollständige System - Update zu tun, und dann habe ich entfernen und die SD - Karte einlegen, und dann nicht , daß ich den Regenbogen - Bildschirm wieder sehen , aber diese Fehlermeldung erhalten:

[  20.217557] Kernel panic - not syncing : VFS: Unable to mount root fs on unknown-block(179,2)

PANIC: VFS: Unable to mount root fs on unknown-block(179,2)

Entering kdb (current=0xcd828ca0, pid 1) due to Keyboard Entry
kdb> _ 

Dieser Fehler tritt auch auf, wenn ich nur das linux-raspberrypiPaket aktualisiere und dann nur rebootdie SD-Karte entferne und dieselbe Kernel-Panic-Fehlermeldung erhalte.

Ich habe eine Samsung SDHC 16GB Class10 (MB-MPAGA oder MB-MPAGAEU) Karte. Ich habe es auch mit einer Kingmax SDHC 16GB Class10-Karte versucht, und mit einer Kingmax SDHC 8GB Class6-Karte hat es auch nicht funktioniert.

Wenn ich das raspberrypi-firmwareund das linux-raspberrypiPaket in Pacman ignoriere und dann die Systemaktualisierung durchführe, tritt kein Fehler auf, selbst wenn ich die SD-Karte entferne. Es muss also ein Problem in diesen Paketen geben.

Ich poste dies als Antwort, da in Kommentaren nicht genügend Platz ist. Aus all den bisher gesammelten Informationen geht hervor, dass das Problem nur mit dem Inhalt von / boot / partition zusammenhängt. Jetzt kann das Problem durch zwei Dinge verursacht werden: 1. / boot / Dateisystembeschädigung, die es dem Bootloader unmöglich macht, Firmwaredateien zu laden. 2. Die neue Firmware-Version weist eine gewisse Regression auf, die die Funktion Ihrer SD-Karte verhindert. Sie müssen überprüfen, welche davon wahr ist.

Eine Möglichkeit, dies zu tun, besteht darin, Dateien in / boot / auf Ihrem PC manuell zu aktualisieren. Um dies zu tun, müssen Sie zuerst sicherstellen, dass Ihr System nicht direkt in das grafische System bootet (da keine Module funktionieren und die Verwendung von Tastatur / Maus in X nicht möglich ist). Dann müssen Sie Ihre SD-Karte in den PC einbinden , den Inhalt sichern und auf der Github-Seite nach Firmware-Dateien suchenGeben Sie das Boot-Verzeichnis ein und laden Sie die folgenden Dateien (die vorhandenen überschreiben) auf Ihre / boot / -Partition herunter - bootcode.bin, kernel.img, start.elf, loader.bin. Sie müssen keine anderen Dateien überschreiben. Um jede Datei herunterzuladen, müssen Sie auf ihren Namen klicken, dann auf "Rohdaten anzeigen" klicken und diese auf Disc speichern. Nachdem Sie alle Dateien gespeichert haben, stellen Sie sicher, dass Sie Ihre SD-Karte sicher ausgeworfen haben, und prüfen Sie, ob sie startet. Auf diese Weise können Sie prüfen, ob die neuesten Firmware-Dateien (Kernel und Bootloader) von Ihrer SD-Karte booten können. Wenn dies zutrifft, können wir sicher sein, dass Ihr Problem durch eine Beschädigung von / boot / partition und nicht durch eine Regression von Kernel / Bootloader verursacht wird.

Wie bereits erwähnt, sollten Sie auch überprüfen, wie viele grüne LED-Blitze Sie sehen können, wenn Sie den Regenbogenbildschirm sehen. Vor einiger Zeit wurde dem Bootloader ein Fehlerbehebungscode hinzugefügt, der mehrmals grün blinkt, um anzuzeigen, was falsch gelaufen ist. Hier ist die Liste: 3 Blitze: loader.bin nicht gefunden 4 Blitze: loader.bin nicht gestartet 5 Blitze: start.elf nicht gefunden 6 Blitze: start.elf nicht gestartet

Wenn Sie überhaupt keine Flashes sehen, ist entweder Ihre Firmware zu alt, um dies zu unterstützen, oder es wurde nicht einmal bootcode.bin geladen. Sie können auch überprüfen, ob die Startpartition nicht beschädigt ist, indem Sie prüfen, ob alle für den Start erforderlichen Dateien (wie oben erwähnt) korrekt sind (nicht in der Größe Null, vorhanden usw.). Sie können auch überprüfen, welche Datei auf der Startpartition ein Problem verursacht, indem Sie nur einige davon wiederherstellen. Zum Beispiel nur kernel.bin wiederherstellen oder nur start.elf + loader.bin + bootcode.bin. Dies kann Ihnen sagen, ob es sich um ein Firmware- oder Kernelproblem handelt.

Es muss sdcard problem sein. Wenn ich Raspbian „wheezy“ installiere, erweitere ich in der raspi-config die Partition, um die Karte auszufüllen, schalte dann den Raspberry Pi aus, entferne die SD-Karte, stecke sie erneut ein und boote nicht. Die Kingmax 16GB SDHC Class10-Karte wird nicht unterstützt.

Ich habe es auch mit Kingmax 8GB und Samsung 16GB versucht, wie ich in der Frage erwähnt habe, und es hat auch nicht funktioniert. Vielleicht ist es ein anderes Problem.

Raspberry PI - PANIC: VFS Kann Root-Fs nicht auf Unbekannt-Block mounten (179,2) Ich habe diese Meldung nach Update und Neustart erhalten.

PANIC: VFS Kann Root-Fs auf unknown-block (179,2) nicht mounten. Eingabe von kdb (current = 0xcb846c80, pid 1) wegen Tastatureingabe

Das Problem ist zumindest für mich leicht lösbar.

Also starte ich auf RescueCD - jedes Linux ist auf einem anderen PC in Ordnung

Dann führe ich die Dateisystemreparatur durch (benutze deinen korrekten Gerätenamen)

fsck / dev / sdb2

Ich musste es mehrmals ausführen, dann habe ich die Prüfung fsck -f / dev / sdb2 erzwungen

Und das Dateisystem wurde repariert.

Vielleicht gibt es eine vorübergehende Lösung. Ich synchronisiere die Datei vor dem Neustart. Daher führe ich die Befehlssynchronisierung etwa zwei- oder dreimal vor dem Neustart von sudo aus. Seitdem habe ich den Fehler nicht mehr gesehen.

Update1: Es gibt wahrscheinlich einen Einfluss der Übertaktung auf das Erscheinungsbild der Dateisystembeschädigung. Denn ich habe die Probleme immer nach höherer Auslastung gesehen, wie zum Beispiel Update und Upgrade.

Update2: Ja, wenn es nicht übertaktet ist, dann sind sie keine Probleme. Vielleicht kann es mit einer anderen SD-Karte auch übertakten.

Update3: Nach einigen Untersuchungen und Tests stellte ich fest, dass die Originalbox, die ich für Pi verwendet habe, nur von unten belüftete Löcher aufweist und daher der IO-Treiber überhitzen kann und Probleme mit Ethernet, USB und SD-Karte verursacht. Da ich es offen laufen lasse konnte ich auch das Medium problemlos übertakten.

Update4: Himbeere fehlgeschlagen Es wird zum Umtausch an den Lieferanten gesendet. Weitere Informationen finden Sie hier.

Update5: Die Himbeere wurde vom Lieferanten getauscht. Neues Stück sieht OK aus. Lass uns hoffen.

Update6: Das neue Stück hat ca. 12 Tage am 24.7. Ohne Probleme laufen. Es ist sogar die ganze Zeit übertaktet (mittel). Ich nehme an, wenn jemand immer noch Probleme mit der Stabilität hat, sollte er um einen Austausch unter der Quarantäne bitten. Ich führe es jetzt aus dem gekauften Original-Kunststoffgehäuse ohne zusätzliche Kühlung mit der SD-Karte und dem Netzteil als erstem aus. Ich habe keine Tweeks zum ursprünglichen Raspbian-System verwendet.

Ich hatte nach dem Upgrade auf linux-raspberrypi 3.18.3 ein ähnliches Kernel-Panik-Problem (NO MORE linux-raspberrypi-latest).

In meinem Fall waren es keine beschädigten Dateisysteme, Bootloader oder Firmware. Es war das Kernelpaket.

Die Fehlermeldung lautet

Error: Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(179,2)

Zuerst dachte ich, die arme SDHC-Karte sei gestorben, aber es stellte sich heraus, dass es in Ordnung war. Die vfat /bootPartition und ext4 /und /homewaren beide in Ordnung.

Ich verbringe einige Zeit und am Ende war das linux-raspberrypi-3.18.3-3Paket der Schuldige.

Aus irgendeinem Grund aktualisiert das Paket , um das /boot/cmdline.txt die Punkte /auf die falsche Partition , /dev/mmcblk0p2die sein sollte /dev/mmcblk0p5.

HINWEIS: pacman -Qo /boot/cmdline.txtZeigt an, von welchen Paketen es stammt.

Nachdem Sie die SD-Karte in das Netbook eingesteckt und die Datei cmdline.txt wiederhergestellt haben, stecken Sie sie wieder in den Pi, und das System läuft einwandfrei.