Comment réparer le démarrage dans initramfs Prompt et "mount: ne peut pas lire '/ etc / fstab': Aucun fichier ou répertoire" et "Aucun init trouvé"?
Installation d'un nouveau système à l'aide d'un GPT disque partitionné dédié à une seule partition, ext4 formaté, extlinux (version 4.05) en tant que chargeur de démarrage, Ubuntu Core version 13.10 AMD64 en tant que rootfs et Ubuntu linux-image-3.11.0-18-generic en tant que noyau, et extlinux-update pour générer la configuration du chargeur de démarrage.
Le résultat après le redémarrage (toujours à l'intérieur d'une machine virtuelle basée sur KVM) est une invite (initramfs) et ces messages:
mount: can't read '/etc/fstab': No such file or directory
mount: mounting /dev on /root/dev failed: No such file or directory
mount: mounting /sys on /root/sys failed: No such file or directory
mount: mounting /proc on /root/proc failed: No such file or directory
The filesystem doesn't have requested /sbin/init.
No init found. Try passing init= bootarg.
BusyBox est v1.20.2.
Régression:
- le système de fichiers a été vérifié avec
fsck.ext4
Vérifier l'existence de la racine
(initramfs) ls -l /dev/[hs]da*
ls: /dev/[hs]da*: No such file or directory
Argument de démarrage racine
(initramfs) cat /proc/cmdline
initrd=/boot/initrd.img-3.11.0-18-generic ro quiet BOOT_IMAGE=/boot/vmlinuz-3.11.0-18-generic
Vérifier les modules chargés
(initramfs) cat /proc/modules
e1000 145368 0 - Live 0xffffffffa0000000
/ contenu du dossier de démarrage
$ Sudo ls -l boot
-rw------- 1 root root 3296162 Feb 18 22:37 System.map-3.11.0-18-generic
-rw-r--r-- 1 root root 1007681 Feb 18 22:37 abi-3.11.0-18-generic
-rw-r--r-- 1 root root 163258 Feb 18 22:37 config-3.11.0-18-generic
drwxr-xr-x 2 root root 4096 Mar 17 20:13 extlinux
-rw-r--r-- 1 root root 4995000 Mar 16 23:35 initrd.img-3.11.0-18-generic
-rw------- 1 root root 5634192 Feb 18 22:37 vmlinuz-3.11.0-18-generic
Comment faire démarrer ce système à l'invite bash attendue par défaut?
Modifiez votre paramètre de démarrage du noyau en définissant le root=/dev/sdaX option. sdaX serait votre / ou root partition. Au prochain démarrage, vous verrez que votre initramfs essaie de monter la partition avant d'essayer d'accéder à /etc/fstab et le montage des systèmes de fichiers.
Voir la question " initramfs utilise-t-il/etc/fstab? " pour plus de détails.
Ce que vous devez comprendre initramfs, c'est qu'il s'agit d'un système de fichiers. Depuis le noyau 2.6, il est, fondamentalement, le seul système de fichiers imposé par le noyau (en laissant de côté VFS, qui est sans doute également un système de fichiers) sur votre machine. Votre initramfs image est une image disque.
Dans votre initramfs image correspondra aux fichiers dont la distribution a décidé qu'ils étaient suffisamment cruciaux pour que votre disque racine soit trouvé. Il s'agit généralement de Busybox et des modules de noyau dont vous avez besoin pour trouver et monter votre périphérique racine. Cela ne fonctionne pas pour vous.
Il n'y a pas de vrai mystère ici, tout bien considéré. Si vous pouvez vous repérer dans une invite de terminal, vous pouvez naviguer dans le initramfs. Mais d'abord, vous devez le démystifier.
D'abord et avant tout - encore une fois - c'est juste /. C'est la racine Linux qui fait des choses de type racine Linux. En fait, s'il se trouve dans un fichier distinct de votre noyau, il s'agit en fait déjà de votre deuxième périphérique racine. Chaque noyau Linux contient un essentiellement vide / tout propre qu'il monte d'abord avant de retirer votre initramfs.
De plus initramfs est la racine réelle . C'est là que le noyau Linux initialise l'espace utilisateur en exécutant init et en renonçant ensuite à toute responsabilité pour tout problème que vous pourriez rencontrer par la suite. Votre init semble être Busybox, comme beaucoup, ce qui signifie que le contrôle de ses actions devrait être aussi simple que la modification des scripts Shell qui l'accompagnent.
Alors pourquoi l'erreur de ne pas trouver init? Il s'agit presque certainement d'un programme nommé init dont votre réel init a été chargé via le script Shell de s'exécuter dans.
Le plus frappant pour moi est que les pseudo-systèmes de fichiers du noyau - dev sys proc - ne pas monter. C'est très troublant ou un très bon indice. Vous mentionnez KVM ce qui m'amène à remettre en question les capacités du noyau, mais avant d'aller sur cette route sombre et défoncée, pouvons-nous d'abord essayer autre chose?
cd /root || mkdir /root
Il me semble que le message d'erreur est répété:
Aucun fichier ou répertoire de ce nom
A défaut, vous devez reconstruire votre image initramfs. Démarrez sur un disque live pour le faire et exécutez tout outil fourni par votre distribution pour atteindre cet objectif. Oh, et s'il vous plaît assurez-vous que ce disque en direct est chargé dans [~ # ~] efi [ ~ # ~] mode.
Voici donc la seule chose vraiment hors du commun à propos de initramfs - switchroot.
Le noyau Linux fournit un appel système très spécial destiné aux premiers utilisateurs et gérant le déplacement de initramfs vers votre périphérique de disque racine. Cela fonctionne en montant d'abord votre disque racine dans un point de montage dans initramfs, puis en y faisant pivoter le système de fichiers racine. Je suppose que votre initramfs's le point de montage cible est root basé sur la façon dont il continue de gémir à ce sujet. Pourquoi ne pas vous assurer qu'il est là?
Pour une enquête plus approfondie, vous devrez obtenir un peu de gravier. Ajustez votre bootloader pour passer ...
init=/bin/sh
... comme paramètre du noyau.
J'ai eu le même problème. Ce que Alex a dit est correct. J'ai d'abord ajusté mon fstab mais cela n'a pas aidé. J'ai donc vérifié mon GRUB. Si vous avez la possibilité d'accéder au menu GRUB.
- Sélectionnez Linux, ce que vous voulez démarrer et ce qui pose problème.
- Appuyez sur 'e' et recherchez 'boot_image' ou 'boot ... root'.
- Vérifiez le 'id'.
- Dans mon cas, c'était faux. Je fais une image dans
initramfsen tapant 'blkid' et je prends l'uuid sur quelle partition mon linux est installé. - Collez l'uuid correct de blkid vers grub -> boot_image.
Cela a résolu mon problème. Après le redémarrage, mon Linux avait besoin de plus de temps pour commencer à vérifier le disque. Mais maintenant ça marche à nouveau.
J'espère que je pourrais t'aider.
Cordialement