Pb ALERT! /dev/disk/by-uuid/xxx does not exist. Dropping to a shell.
1 réponse
Yann Cohen
Bonjour,
Donc on se retrouve sur un shell minimaliste dans initramfs (busybox).
Cela est survenu sur une machine =E9loign=E9e de chez moi sur laquelle je
n'ai pas la main hors une t=E9l=E9commande par t=E9l=E9phone du dit "tapes =
ce
que je te dis et dis-moi ce que tu vois".
Donc mes questions :
- existe-t-il un moyen depuis le minishell de s'en sortir ?
(monter /boot et aller modifier le menu de grub, trouver le uuid du
disque, etc.).
- le cd d'install peut-il nous =EAtre d'un secours ? un truc comme
sysrescuecd ?
- D'o=F9 cela peut-il provenir ? la derni=E8re install qui s'est mal
termin=E9e, un disque qui flanche ?
Merci de vos r=E9ponses...
--
Yann.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20110919195535.70d898ed@yan.ianco.homelinux.org
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Yann Cohen
Bonjour,
Voici la procédure utilisée pour effectuer à distance le diagnostique et la réparation.
1- identification du message exacte : le noyau ne trouve pas le root fs sous UUID gnagnagna ;
2- envoi par la poste d'un cd sysrescuecd (voir )
3- attendre la réception du colis postal et la disponibilité de l'utilisateur...
4- mise en place avec une autre machine d'une connexion skype avec vidéo (pour voir l'écran)
5- démarrage de la machine, modification de l'ordre des recherche de boot dans le bios, lancement de sysrescuecd
6- sur la console de sysrescuecd, mettre en place un mot de passe à root et démarré le serveur ssh.
7- connexion à distance puisque cela avait été prévu sur la box internet qui laisse entrer le ssh.
8- depuis le shell distant : - vérification que la structure lvm est opérationnelle et détectée par sysrescuecd (lvdisplay montre tous les volumes logiques) ; - montage de la partition boot (qui ne PEUX pas être sur lvm pour le moment) /dev/sda1 sur /mnt/sda1 ; - edition de /mnt/boot/grub/grub.cfg et modification des lignes linux ou apparaît "root=UUID=xxxxx" par root=/dev/mapper/vg0-root - montage de /dev/mapper/vg0-root sur /mnt/root pour vérifier comment est écrit fstab => avec les /dev/mapper et non les UUID, donc pas de soucis (de toute façon a ce moment là udev à fait son boulot et je pense que les deux fonctionneraient).
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Bonjour,
Voici la procédure utilisée pour effectuer à distance le diagnostique
et la réparation.
1- identification du message exacte : le noyau ne trouve pas le root fs
sous UUID gnagnagna ;
2- envoi par la poste d'un cd sysrescuecd (voir )
3- attendre la réception du colis postal et la disponibilité de
l'utilisateur...
4- mise en place avec une autre machine d'une connexion skype avec
vidéo (pour voir l'écran)
5- démarrage de la machine, modification de l'ordre des recherche de
boot dans le bios, lancement de sysrescuecd
6- sur la console de sysrescuecd, mettre en place un mot de passe à
root et démarré le serveur ssh.
7- connexion à distance puisque cela avait été prévu sur la box
internet qui laisse entrer le ssh.
8- depuis le shell distant :
- vérification que la structure lvm est opérationnelle et détectée par
sysrescuecd (lvdisplay montre tous les volumes logiques) ;
- montage de la partition boot (qui ne PEUX pas être sur lvm pour le
moment) /dev/sda1 sur /mnt/sda1 ;
- edition de /mnt/boot/grub/grub.cfg et modification des lignes linux
ou apparaît "root=UUID=xxxxx" par root=/dev/mapper/vg0-root
- montage de /dev/mapper/vg0-root sur /mnt/root pour vérifier comment
est écrit fstab => avec les /dev/mapper et non les UUID, donc pas de
soucis (de toute façon a ce moment là udev à fait son boulot et je
pense que les deux fonctionneraient).
9- reboot de la machine et c'est fini.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20111002122342.72ab7b4d@yan.ianco.homelinux.org
Voici la procédure utilisée pour effectuer à distance le diagnostique et la réparation.
1- identification du message exacte : le noyau ne trouve pas le root fs sous UUID gnagnagna ;
2- envoi par la poste d'un cd sysrescuecd (voir )
3- attendre la réception du colis postal et la disponibilité de l'utilisateur...
4- mise en place avec une autre machine d'une connexion skype avec vidéo (pour voir l'écran)
5- démarrage de la machine, modification de l'ordre des recherche de boot dans le bios, lancement de sysrescuecd
6- sur la console de sysrescuecd, mettre en place un mot de passe à root et démarré le serveur ssh.
7- connexion à distance puisque cela avait été prévu sur la box internet qui laisse entrer le ssh.
8- depuis le shell distant : - vérification que la structure lvm est opérationnelle et détectée par sysrescuecd (lvdisplay montre tous les volumes logiques) ; - montage de la partition boot (qui ne PEUX pas être sur lvm pour le moment) /dev/sda1 sur /mnt/sda1 ; - edition de /mnt/boot/grub/grub.cfg et modification des lignes linux ou apparaît "root=UUID=xxxxx" par root=/dev/mapper/vg0-root - montage de /dev/mapper/vg0-root sur /mnt/root pour vérifier comment est écrit fstab => avec les /dev/mapper et non les UUID, donc pas de soucis (de toute façon a ce moment là udev à fait son boulot et je pense que les deux fonctionneraient).