Comment corriger le démarrage dans l'invite initramfs et «mount: impossible de lire '/ etc / fstab': Aucun fichier ou répertoire de ce type» et «Aucun init trouvé»?

Installation d'un nouveau système à l'aide d'un disque partitionné GPT dédié à une seule partition, formaté ext4 , extlinux (version 4.05) comme chargeur de démarrage, Ubuntu Core version 13.10 amd64 comme rootfs et Ubuntu linux-image-3.11.0-18-generic comme 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 l' root=/dev/sdaXoption. sdaXserait votre partition /ou root. Au prochain démarrage, vous verrez que vous initramfsessayez de monter la partition avant d'essayer d'accéder /etc/fstabet de monter les systèmes de fichiers.

Voir la question " Est-ce que initramfs utilise / etc / fstab? " Pour plus de détails.

Ce que vous devez comprendre, initramfsc'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 aussi un système de fichiers) sur votre machine. Votre initramfs imageest une image disque.

Dans votre initramfs imagevolonté, vous trouverez tous les 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 la démystifier.

D'abord et avant tout - encore une fois, c'est simplement /.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 élément fondamentalement vide /qu'il monte d'abord avant de retirer votreinitramfs.

De plus, initramfsc'est la vraie racine. C'est là que le noyau Linux initialise l'espace utilisateur en exécutant initpuis en renonçant à toute responsabilité pour tout problème que vous pourriez rencontrer par la suite. Votre initsemble être Busybox, comme beaucoup d'autres, 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?presque certainement cela fait référence à un programme nommé dans initlequel votre réel inita été chargé via un script shell de s'exécuter.

Le plus frappant pour moi est que les pseudo-systèmes de fichiers du noyau - dev sys proc- ne se montent pas. 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 initramfsimage. Démarrez sur un disque live pour le faire et exécutez tout outil fourni par votre distribution pour atteindre cet objectif. Oh, et assurez- vous que ce disque en direct est chargé en mode EFI .

Voici donc la seule chose vraiment hors de l'ordinaire initramfs - switchroot.

Le noyau Linux fournit un appel système très spécial destiné aux premiers utilisateurs et gérant le passage de initramfsvotre périphérique de disque racine. Cela fonctionne en montant d'abord votre disque racine dans un point de montage initramfs, puis en y faisant pivoter le système de fichiers racine. Je suppose que votre initramfs'spoint de montage cible est rootbasé 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é. Alors, j'ai 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 « uuid ».
• Dans mon cas, c'était faux. Je fais une image dans initramfs en tapant 'blkid' et je prends l'uuid sur quelle partition mon linux est installé.
• Passé le bon uuid de blkid à 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