¿No arrancará después de quitar e insertar la tarjeta SD?

He instalado Arch Linux en mi tarjeta SD con Win32DiskImager. Si apago el RPi, quito la tarjeta, la inserto y vuelvo a iniciar el RPi, todo funciona bien. Pero si hago la actualización completa del sistema en pacman pacman -Syu, hay un problema. Si apago y vuelvo a iniciar el RPi, no hay problema, pero si lo apago, quito la tarjeta, la inserto y luego inicio el RPi, no puede arrancar nunca más, solo espero en la pantalla de inicio del arco iris siempre. Tampoco necesito quitar la tarjeta SD, solo lo suficiente para detener la fuente de alimentación durante 30 segundos (hasta que los condensadores se descarguen por completo) e iniciar el RPi, y se produce el mismo error.

He intentado desactivar el paquete de actualización de firmware Raspberry Pi-añadiendo IgnorePgk = raspberrypi-firmwareen /etc/pacman.confel archivo, y luego hacer la actualización completa del sistema, y luego extraer e insertar la tarjeta sd, y luego no veo la pantalla de arco iris de nuevo, pero este mensaje de error:

[  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> _ 

Este error también ocurre si solo actualizo el linux-raspberrypipaquete, y luego solo rebooty no elimino la tarjeta sd, y recibo el mismo mensaje de error de kernel-panic.

Tengo una tarjeta Samsung SDHC 16GB Class10 (MB-MPAGA aka MB-MPAGAEU). También probé con la tarjeta Kingmax SDHC 16GB Class10, y con una tarjeta Kingmax SDHC 8GB Class6, ninguno funcionó.

Si ignoro el raspberrypi-firmwarey el linux-raspberrypipaquete en pacman, y luego hago la actualización del sistema, no se produce ningún error incluso si quito la tarjeta sd. Por lo tanto, debe haber algún problema en estos paquetes.

Estoy publicando esto como respuesta ya que no hay suficiente espacio en los comentarios. Entonces, de toda la información recopilada hasta ahora, parece que el problema solo está relacionado con el contenido / boot / Partition Ahora el problema puede ser causado por dos cosas: 1. / boot / corrupción del sistema de archivos que hace imposible que el gestor de arranque cargue archivos de firmware 2. La nueva versión de firmware tiene cierta regresión que impide que su tarjeta SD funcione. Tienes que comprobar cuál de estos es cierto.

Una forma de hacerlo sería actualizar manualmente los archivos en / boot / en su PC. Para hacer esto, primero deberá asegurarse de que su sistema no se inicie directamente en el sistema gráfico (porque no tendrá módulos funcionando y esto haría imposible usar el teclado / mouse en X). Luego debe conectar su tarjeta SD en la PC, hacer una copia de seguridad de su contenido, ir a la página de github para ver los archivos de firmware, ingrese el directorio de arranque y descargue los siguientes archivos (anulando los existentes) a su / boot / partición - bootcode.bin, kernel.img, start.elf, loader.bin. No necesitará anular ningún otro archivo. Para descargar cada archivo, debe hacer clic en su nombre, luego hacer clic en "ver sin formato" y guardarlo en el disco. Después de guardar todos los archivos, asegúrese de haber expulsado su tarjeta SD y verifique si arranca. De esta manera, puede verificar si los archivos de firmware más recientes (kernel y bootloader) pueden arrancar desde su tarjeta SD. Si es cierto, entonces podemos estar seguros de que su problema es causado por la corrupción / arranque / partición, no por la regresión kernel / bootloader.

Como se mencionó anteriormente, también debe verificar cuántos destellos de led verde puede ver cuando ve la pantalla del arco iris. Hace algún tiempo, se agregó un código de solución de problemas al gestor de arranque y parpadeará en verde varias veces para mostrar qué salió mal. Aquí está la lista: 3 flashes: loader.bin no encontrado 4 flashes: loader.bin no lanzado 5 flashes: start.elf no encontrado 6 flashes: start.elf no lanzado

Si no ve ningún parpadeo, entonces su firmware es demasiado viejo para admitir esto o ni siquiera se cargó bootcode.bin. También puede verificar si la partición de arranque no está dañada verificando si todos los archivos necesarios para el arranque (mencionados anteriormente) están sanos (no tienen tamaño cero, existen, etc.). También puede verificar qué archivo en la partición de arranque causa problemas restaurando solo algunos de ellos. Por ejemplo, solo restaure kernel.bin o solo start.elf + loader.bin + bootcode.bin. Esto puede decirle si es un problema de firmware o kernel.

Debe ser un problema de tarjeta sd. Si instalo Raspbian "wheezy", en raspi-config amplío la partición para llenar la tarjeta, luego apago la Raspberry Pi, quito la tarjeta sd, la inserto de nuevo, no arrancará. La tarjeta Kingmax 16GB SDHC Class10 no es compatible.

También probé con Kingmax 8GB y Samsung 16GB como mencioné en la pregunta, y ninguno funcionó. Quizás sea algún otro problema.

Raspberry PI - PANIC: VFS No se puede montar la raíz fs en el bloque desconocido (179,2) Recibí este mensaje después de la actualización y reinicio.

PÁNICO: VFS No se puede montar la raíz fs en un bloque desconocido (179,2) Ingresando kdb (actual = 0xcb846c80, pid 1) debido a la entrada del teclado

El problema es fácil de resolver, al menos para mí.

Así que inicio en RescueCD: cualquier Linux está bien en otra PC

Luego ejecuto la reparación del sistema de archivos (use su nombre de dispositivo correcto)

fsck / dev / sdb2

Tuve que ejecutarlo varias veces, luego forcé la comprobación fsck -f / dev / sdb2

Y el sistema de archivos fue reparado.

Quizás haya una solución temporal. Lo que hago es sincronizar el archivo antes de reiniciar. Entonces, ejecuto la sincronización de comandos aproximadamente 2 o 3 veces antes de reiniciar sudo. Desde esto no he vuelto a ver el error.

Actualización 1: Probablemente haya una influencia del overclock en la aparición de la corrupción del sistema de archivos. Porque he visto los problemas siempre después de una carga más alta como, por ejemplo, actualizar y actualizar.

Actualización2: Sí, cuando no es overclock, entonces no hay problemas. Quizás con otra tarjeta SD también pueda funcionar overclock.

Actualización 3: Después de algunas investigaciones y pruebas, descubrí que la caja original que he usado para Pi tiene orificios de ventilación solo desde abajo y, por lo tanto, el controlador IO puede sobrecalentarse y causó problemas con ethernet, usb y tarjeta SD. Desde que lo abrí, pude hacer incluso el overclock medio sin problema.

Actualización 4: Frambuesa fallida Se envía para el intercambio al proveedor. Vea más información aquí.

Actualización 5: La frambuesa fue intercambiada por el proveedor. Nueva pieza se ve bien. Esperemos.

Actualización 6: La nueva pieza tiene aproximadamente 12 días de ejecución 7/24 sin ningún problema. Incluso está todo el tiempo overclockeado (medio). Supongo que si alguien todavía tiene problemas con la estabilidad, entonces debería pedir un intercambio bajo la cuarentena. Solo lo ejecuto ahora fuera de la caja de plástico original comprada sin ningún enfriamiento adicional con la tarjeta SD y la fuente de alimentación como la primera. No he usado ningún tweeks para el sistema Raspbian original.

Tuve un problema similar de kernel panic después de actualizar a linux-raspberrypi 3.18.3 (NO MÁS linux-raspberrypi-latest).

En mi caso, no se trataba de sistemas de archivos dañados, gestor de arranque o firmware. Era el paquete del núcleo.

El mensaje de error es

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

Al principio pensé que la pobre tarjeta SDHC murió pero resultó estar bien. La vfat /bootpartición y ext4 /y /homedos estaban bien.

Paso algo de tiempo y al final el linux-raspberrypi-3.18.3-3paquete fue el culpable.

Por alguna razón, el paquete actualiza /boot/cmdline.txt que apunta /a la partición incorrecta /dev/mmcblk0p2que debería ser /dev/mmcblk0p5.

NOTA: pacman -Qo /boot/cmdline.txtle dirá de qué paquetes proviene.

Después de enchufar la SD en el netbook y volver al buen cmdline.txt, vuelva a enchufarlo en el Pi, el sistema está funcionando y funcionando felizmente.