Ne démarre pas après avoir retiré et inséré la carte SD?

J'ai installé Arch Linux sur ma carte SD avec Win32DiskImager. Si j'arrête le RPi, retire la carte, l'insère et redémarre le RPi, tout fonctionne bien. Mais si je fais une mise à jour complète du système dans pacman avec pacman -Syu, il y a un problème. Si j'arrête et redémarre le RPi, pas de problème, mais si j'arrête, retirez la carte, insérez, puis démarrez le RPi, il ne pourra plus jamais redémarrer, en attendant toujours l'écran de démarrage de l'arc-en-ciel. Je n'ai pas non plus besoin de retirer la carte SD, juste assez pour arrêter l'alimentation pendant 30 secondes (jusqu'à ce que les condensateurs se déchargent complètement) et démarrer le RPi, et la même erreur se produit.

J'ai essayé de désactiver le paquet Raspberry Pi-firmware mise à jour en ajoutant IgnorePgk = raspberrypi-firmwaredans le /etc/pacman.conffichier, puis effectuez la mise à jour complète du système, puis - je supprimer et insérez la carte SD, et je ne vois pas à nouveau l'écran d'arc en ciel, mais ce message d'erreur:

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

Cette erreur se produit également si je ne mets à jour que le linux-raspberrypipackage, puis que je rebootretire et non la carte SD, et que j'obtiens le même message d'erreur de panique du noyau.

J'ai une carte Samsung SDHC 16GB Class10 (MB-MPAGA aka MB-MPAGAEU). J'ai également essayé avec la carte Kingmax SDHC 16 Go Class10, et avec une carte Kingmax SDHC 8 Go Class6, ni l'un ni l'autre n'a fonctionné.

Si j'ignore le raspberrypi-firmwareet le linux-raspberrypipackage dans pacman, puis fais la mise à jour du système, aucune erreur ne se produit même si je retire la carte SD. Il doit donc y avoir un problème dans ces packages.

Je poste ceci comme réponse car il n'y a pas assez d'espace dans les commentaires. Donc, d'après toutes les informations recueillies jusqu'à présent, il semble que le problème ne soit lié qu'au contenu de / boot / partition. Maintenant, le problème peut être causé par deux choses: 1. / boot / corruption du système de fichiers qui empêche le chargeur de démarrage de charger les fichiers du firmware 2. La nouvelle version du firmware a une régression qui empêche votre carte SD de fonctionner. Vous devez vérifier laquelle de ces affirmations est vraie.

Une façon de procéder serait de mettre à jour manuellement les fichiers dans / boot / sur votre PC. Pour ce faire, vous devrez d'abord vous assurer que votre système ne démarre pas directement sur le système graphique (car vous n'aurez pas de modules fonctionnant et cela rendrait impossible l'utilisation du clavier / souris dans X). Ensuite, vous devez connecter votre carte SD au PC, sauvegarder son contenu, aller sur la page github pour les fichiers du firmware, entrez le répertoire de démarrage et téléchargez les fichiers suivants (en remplaçant ceux existants) sur votre / boot / partition - bootcode.bin, kernel.img, start.elf, loader.bin. Vous n'aurez pas besoin de remplacer les autres fichiers. Pour télécharger chaque fichier, vous devez cliquer sur son nom, puis cliquer sur "Afficher brut" et l'enregistrer sur disque. Après avoir enregistré tous les fichiers, assurez-vous d'avoir éjecté votre carte SD en toute sécurité et vérifiez si elle démarre. De cette façon, vous pouvez vérifier si les fichiers de firmware les plus récents (noyau et chargeur de démarrage) peuvent démarrer à partir de votre carte SD. Si c'est vrai, nous pouvons être sûrs que votre problème est causé par la corruption / boot / partition, et non par la régression noyau / chargeur de démarrage.

Comme mentionné précédemment, vous devez également vérifier le nombre de flashs verts que vous pouvez voir lorsque vous voyez un écran arc-en-ciel. Il y a quelque temps, du code de dépannage a été ajouté au chargeur de démarrage et il clignotera plusieurs fois en vert pour indiquer ce qui n'a pas fonctionné. Voici la liste: 3 flashs: loader.bin non trouvé 4 flashs: loader.bin non lancé 5 flashs: start.elf introuvable 6 flashs: start.elf non lancé

Si vous ne voyez aucun flash, alors votre micrologiciel est trop ancien pour le supporter ou même bootcode.bin n'a pas été chargé. Vous pouvez également vérifier si la partition de démarrage n'est pas corrompue en vérifiant si tous les fichiers nécessaires au démarrage (mentionnés précédemment) sont sains (pas de taille zéro, existent, etc.). Vous pouvez également vérifier quel fichier sur la partition de démarrage pose problème en ne restaurant que certains d'entre eux. Par exemple, ne restaurez que kernel.bin ou seulement start.elf + loader.bin + bootcode.bin. Cela peut vous dire s'il s'agit d'un problème de firmware ou de noyau.

Ce doit être un problème de carte SD. Si j'installe Raspbian «wheezy», puis dans la configuration de raspi j'étends la partition pour remplir la carte, puis arrête le Raspberry Pi, retire la carte SD, réinsère-la, elle ne démarrera pas. La carte SDHC Class10 Kingmax 16 Go n'est pas prise en charge.

J'ai également essayé avec Kingmax 8GB et Samsung 16GB comme je l'ai mentionné dans la question, et aucun n'a fonctionné. C'est peut-être un autre problème.

Raspberry PI - PANIQUE: VFS Impossible de monter le root fs sur unknown-block (179,2) J'ai ce message après la mise à jour et le redémarrage.

PANIQUE: VFS Impossible de monter le root fs sur un bloc inconnu (179,2) Saisie de kdb (courant = 0xcb846c80, pid 1) en raison de l'entrée au clavier

Le problème est facile à résoudre au moins pour moi.

Je démarre donc sur RescueCD - tout Linux est OK sur un autre PC

Ensuite, j'exécute la réparation du système de fichiers (utilisez le nom correct de votre appareil)

fsck / dev / sdb2

J'ai dû l'exécuter plusieurs fois, puis j'ai forcé la vérification fsck -f / dev / sdb2

Et le système de fichiers a été réparé.

Il existe peut-être une solution temporaire. Ce que je fais, c'est synchroniser le fichier avant de redémarrer. Donc, j'exécute la synchronisation de commande environ 2 ou 3 fois avant le redémarrage de sudo. Depuis, je n'ai pas revu l'erreur.

Update1: Il y a probablement une influence de l'overclock sur l'apparence de la corruption du système de fichiers. Parce que j'ai vu les problèmes toujours après une charge plus élevée comme par exemple la mise à jour et la mise à niveau.

Update2: Oui, quand il n'est pas overclocké alors ce n'est pas un problème. Peut-être qu'avec une autre carte SD, il peut également fonctionner en overclocking.

Update3: Après quelques investigations et tests, j'ai découvert que la boîte d'origine que j'ai utilisée pour Pi n'a des trous de ventilation que vers le bas et donc le pilote IO peut surchauffer et cela a causé des problèmes avec Ethernet, USB et carte SD. Depuis que je l'ouvre, je pouvais même overclocker le médium sans problème.

Update4: Raspberry a échoué Il est envoyé pour échange au fournisseur voir plus d'informations ici.

Update5: Le Raspberry a été échangé par le fournisseur. La nouvelle pièce semble OK. Espérons.

Update6: La nouvelle pièce a environ 12 jours de fonctionnement 7/24 sans aucun problème. Il est même toujours overclocké (moyen). Je suppose que si quelqu'un a encore un problème de stabilité, il devrait demander un échange sous quarantaine. Je l'exécute maintenant dans le boîtier en plastique d'origine acheté sans refroidissement supplémentaire avec la carte SD et l'alimentation électrique comme première. Je n'ai pas utilisé de tweeks au système Raspbian d'origine.

J'ai eu un problème de panique du noyau similaire après la mise à niveau vers linux-raspberrypi 3.18.3 (PAS PLUS de linux-raspberrypi-latest).

Dans mon cas, ce n'était pas des systèmes de fichiers, un chargeur de démarrage ou un firmware corrompus. C'était le paquet du noyau.

Le message d'erreur est

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

Au début, je pensais que la pauvre carte SDHC était morte, mais cela s'est avéré bien. levfat /boot partition et ext4 /et /homeétaient tous les deux très bien.

J'ai passé un peu de temps et à la fin, le linux-raspberrypi-3.18.3-3paquet était le coupable.

Pour une raison quelconque, le package met à jour le /boot/cmdline.txt qui pointe /vers la mauvaise partition/dev/mmcblk0p2 qui devrait être /dev/mmcblk0p5.

REMARQUE: pacman -Qo /boot/cmdline.txt vous dira de quels paquets il provient.

Après avoir branché la SD sur le netbook et restauré au bon cmdline.txt, rebranchez-le sur le Pi, le système est en place et fonctionne bien.