Non si avvia dopo aver rimosso e inserito la scheda SD?

Ho installato Arch Linux sulla mia scheda SD con Win32DiskImager. Se chiudo l'RPi, rimuovo la scheda, la inserisco e riavvio l'RPi, tutto funziona perfettamente. Ma se eseguo l'aggiornamento completo del sistema in pacman con pacman -Syu, c'è un problema. Se spengo e riavvio l'RPi, nessun problema, ma se spengo, rimuovo la scheda, inserisco, quindi avvio l'RPi, non può avviarsi mai più, aspettando sempre dalla schermata di avvio dell'arcobaleno. Inoltre non ho bisogno di rimuovere la scheda SD, solo abbastanza per interrompere l'alimentazione per 30 secondi (fino a quando i condensatori non si scaricano completamente) e avviare l'RPI e si verifica lo stesso errore.

Ho provato a disabilitare l'aggiornamento del pacchetto raspberrypi aggiungendo IgnorePgk = raspberrypi-firmwarenel /etc/pacman.conffile, quindi eseguendo l'aggiornamento completo del sistema, quindi rimuovo e inserisco la sdcard, quindi non vedo più la schermata arcobaleno, ma visualizzo questo messaggio di errore:

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

Questo errore si verifica anche se aggiorno solo il file linux-raspberrypi pacchetto, quindi rebootrimuovo solo e non rimuovo la sdcard e ricevo lo stesso messaggio di errore di panico del kernel.

Ho una scheda Samsung SDHC 16GB Class10 (MB-MPAGA aka MB-MPAGAEU). Ho anche provato con la scheda Kingmax SDHC 16GB Class10 e con una scheda Kingmax SDHC 8GB Class6, né ha funzionato.

Se ignoro il raspberrypi-firmwaree il linux-raspberrypipacchetto pacman, e poi fare l'aggiornamento del sistema, nessun errore si verifica anche se mi tolgo la sdcard. Quindi deve essere un problema in questi pacchetti.

Sto postando questo come risposta in quanto non c'è abbastanza spazio nei commenti. Quindi, da tutte le informazioni raccolte finora sembra che il problema sia legato solo al contenuto / boot / partition. Ora il problema può essere causato da due cose: 1. Corruzione / boot / filesystem che rende impossibile per il bootloader caricare i file del firmware 2. La nuova versione del firmware ha una regressione che impedisce il funzionamento della scheda SD. Devi verificare quale di questi è vero.

Un modo per farlo sarebbe aggiornare manualmente i file in / boot / sul tuo PC. Per fare ciò, devi prima assicurarti che il tuo sistema non si avvii direttamente sul sistema grafico (perché non avrai moduli funzionanti e questo renderebbe impossibile usare tastiera / mouse in X). Quindi devi connettere la tua scheda SD nel PC, eseguire il backup del suo contenuto, vai su pagina github per i file del firmware, inserisci la directory di avvio e scarica i seguenti file (sovrascrivendo quelli esistenti) nella tua / boot / partition - bootcode.bin, kernel.img, start.elf, loader.bin. Non avrai bisogno di sovrascrivere altri file. Per scaricare ogni file devi fare clic sul suo nome, quindi fare clic su "Visualizza non elaborato" e salvarlo su disco. Dopo aver salvato tutti i file, assicurarsi di aver espulso di nascosto la scheda SD e controllare se si avvia. In questo modo è possibile verificare se i file del firmware più recenti (kernel e bootloader) sono in grado di avviarsi dalla scheda SD. Se è vero, allora possiamo essere sicuri che il tuo problema sia causato dalla corruzione / boot / partition, non dalla regressione kernel / bootloader.

Come accennato in precedenza, dovresti anche controllare quanti lampi a led verdi puoi vedere quando vedi lo schermo arcobaleno. Qualche tempo fa il codice di risoluzione dei problemi è stato aggiunto al bootloader e lampeggerà più volte in verde per mostrare cosa è andato storto. Ecco l'elenco: 3 lampeggi: loader.bin non trovato 4 lampeggi: loader.bin non avviato 5 lampeggi: start.elf non trovato 6 lampeggi: start.elf non avviato

Se non vedi alcun flash, allora il tuo firmware è troppo vecchio per supportare questo o nemmeno bootcode.bin è stato caricato. Puoi anche verificare se la partizione di avvio non è danneggiata controllando se tutti i file necessari per l'avvio (menzionati in precedenza) sono sani (non di dimensioni zero, esistono ecc.). Puoi anche controllare quale file sulla partizione di avvio causa problemi ripristinandone solo alcuni. Ad esempio ripristinare solo kernel.bin o solo start.elf + loader.bin + bootcode.bin. Questo può dirti se si tratta di un problema del firmware o del kernel.

Deve essere un problema sdcard. Se installo Raspbian "wheezy", nella configurazione di raspi espanderò la partizione per riempire la scheda, quindi spegnerò Raspberry Pi, rimuoverò la sdcard, inserirò di nuovo, non si avvierà. La scheda Kingmax SDHC Class10 da 16 GB non è supportata.

Ho anche provato con Kingmax 8GB e Samsung 16GB, come ho già detto nella domanda, e nessuno dei due ha funzionato. Forse è qualche altro problema.

Raspberry PI - PANIC: VFS Impossibile montare il root fs su unknown-block (179,2) Ho ricevuto questo messaggio dopo l'aggiornamento e il riavvio.

PANIC: VFS Impossibile montare root fs su unknown-block (179,2) Immissione di kdb (corrente = 0xcb846c80, pid 1) a causa dell'entrata della tastiera

Il problema è facilmente risolvibile almeno per me.

Quindi avvio su RescueCD - qualsiasi Linux è OK su un altro PC

Quindi eseguo la riparazione del filesystem (usa il nome corretto del tuo dispositivo)

fsck / dev / sdb2

Ho dovuto eseguirlo più volte, quindi ho forzato il controllo fsck -f / dev / sdb2

E il file system è stato riparato.

Forse c'è una soluzione temporanea. Quello che faccio è sincronizzare il file prima di riavviare. Quindi, eseguo la sincronizzazione dei comandi circa 2 o 3 volte prima di riavviare sudo. Da allora non ho più visto l'errore.

Aggiornamento 1: probabilmente c'è un'influenza dell'overclock sull'apparenza della corruzione del file system. Perché ho visto i simboli sempre dopo un carico maggiore come ad esempio aggiornamento e aggiornamento.

Aggiornamento2: Sì, quando non si esegue l'overclocking non si verificano problemi. Forse con un'altra scheda SD può funzionare anche l'overclock.

Aggiornamento3: dopo alcune indagini e prove ho scoperto che la scatola originale che ho usato per Pi ha fori di ventilazione solo dal basso e quindi il driver IO può surriscaldarsi e ha causato problemi con Ethernet, USB e SD card. Da quando lo eseguo aperto potrei effettuare anche l'overclock medio senza problemi.

Aggiornamento 4: Raspberry fallito Viene inviato per lo scambio al fornitore per maggiori informazioni qui.

Aggiornamento 5: Il Raspberry è stato scambiato dal fornitore. Il nuovo pezzo sembra OK. Speriamo.

Update6: il nuovo pezzo ha circa 12 giorni di esecuzione 7/24 senza alcun problema. È anche sempre overcloccato (medio). Suppongo che se qualcuno ha ancora problemi di stabilità, dovrebbe chiedere uno scambio sotto la quarantena. Solo ora lo eseguo dalla custodia di plastica originale acquistata senza alcun raffreddamento aggiuntivo con la scheda SD e l'alimentatore come il primo. Non ho usato tweeks per il sistema Raspbian originale.

Ho avuto un problema di panico simile al kernel dopo l'aggiornamento a linux-raspberrypi 3.18.3 (NON PIÙ linux-raspberrypi-latest).

Nel mio caso, non si trattava di file system, bootloader o firmware danneggiati. Era il pacchetto del kernel.

Il messaggio di errore è

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

All'inizio pensavo che la povera scheda SDHC fosse morta, ma alla fine è andata bene. La vfat /bootpartizione e ext4 /e/home erano entrambi bene.

Passo un po 'di tempo e alla fine il linux-raspberrypi-3.18.3-3 pacco è stato il colpevole.

Per qualche ragione il pacchetto aggiorna /boot/cmdline.txt che punta /alla partizione sbagliata /dev/mmcblk0p2che dovrebbe essere /dev/mmcblk0p5.

NOTA: pacman -Qo /boot/cmdline.txtti dirà da quali pacchetti proviene.

Dopo aver collegato la SD al netbook e aver effettuato il rollback al buon cmdline.txt, ricollegalo al Pi, il sistema è funzionante e funzionante.