J'essaie de réinstaller grub à partir d'un lecteur USB. Je lance ce qui suit:
sudo mount /dev/sda6 /mnt
sudo grub-install --root-directory=/mnt /dev/sda
J'obtiens l'erreur suivante:
grub-probe: error: failed to get canonical path of /cow.
quelqu'un peut-il expliquer l'erreur et comment la résoudre?
Éditer
J'essaie de réparer un système à double démarrage cassé, fonctionnant à partir d'un port USB contenant Linux Mint.
Réponses:
Suivez ces étapes:
Démarrez dans une session Live Linux.
Montez la /partition de votre système d'exploitation installé sur/mnt
sudo mount /dev/sda6 /mnt
Mettre en place un chrootenvironnement:
sudo chroot /mnt
Vous êtes maintenant dans une «fausse» installation Linux qui se traite /mntcomme /. Cela signifie que tous les fichiers nécessaires à GRUB se trouvent /bootlà où le système les attend et vous pouvez installer GRUB comme si vous exécutiez réellement votre système installé:
sudo update-grub
sudo grub-install /dev/sda
Redémarrez maintenant et vous devriez voir le menu GRUB apparaître normalement.
root-deviceoption et qu'attendez-vous de cette option? Avez-vous mis en place un chrootenvironnement? Chaque fois que vous posez une question, vous devez expliquer exactement ce que vous essayez de faire, nous ne pouvons pas le deviner.
Si grub dit qu'il n'a pas pu résoudre le chemin canonique de quelque chose, cela signifie qu'il n'existe pas ou a realpath()échoué.
Dans ce cas, essayez:
$ realpath /cow
$ ls -la /cow
Si les deux commandes disent "impossible de trouver le fichier ou le répertoire", vous devez en créer un.
Si la deuxième commande fonctionne, mais pas la première, vérifiez pourquoi realpath()cela ne fonctionne pas. L'une des raisons peut être qu'il /procn'est pas monté. Dans certaines implémentations de libc, /proc/self/fdest utilisé pour obtenir le chemin canonique d'un fichier.
D'après ce qui a été écrit, il semble que vous essayez d'installer GRUB dans / dev / sda. Vous ne souhaitez pas monter le disque.
Vous recherchez probablement:
grub-install /dev/sda
Page de manuel de GRUB pour référence, ou vous pouvez le faire man grub-installdepuis votre système:
http://linux.die.net/man/8/grub-install
Je reçois également cette erreur, et je ne pense pas que cela se produise dans un chroot.
Je pense que c'est lorsque systemd ne peut pas trouver le chemin d'accès car il est monté dans un répertoire. Ainsi, la différence est que lorsque vous configurez un chroot, vous configurez déjà l'accès au matériel, y compris aux lecteurs.
Bien que vous puissiez configurer cet accès dans Systemd, cela ne signifie pas que vous pouvez configurer les autorisations pour ces lecteurs de la même manière.
Par exemple, j'ai créé ce fichier:
/etc/systemd/system/systemd-nspawn@.service.d/override.conf
Et il contient ces paramètres:
[Service]
DeviceAllow=char-usb_device rwm
DeviceAllow=char-usb
[Files]
Bind=/var/cache/apt/pkgcache.bin
Bind=/var/cache/apt/srcpkgcache.bin
Cela ne fonctionne toujours pas lors de l'utilisation grub-install /dev/sdaou update-grubpour un débootstraps USB sur Pi avec Debian Stretch. Même en utilisant grub-uboot et grub-efi-arm, il y a toujours cette erreur qui grub-probene peut pas trouver le chemin canonique.
Non seulement cela, mais update-grubil verra et saura quels sont les systèmes d'exploitation, mais il grub-installn'est pas intéressant de reconnaître que le système d'exploitation Debian est sur USB.
root@raspixmc:/home/pi# grub-install /dev/sda
Installing for arm-uboot platform.
grub-install: warning: no hints available for your platform. Expect
reduced performance.
grub-install: warning: WARNING: no platform-specific install was
performed.
Installation finished. No error reported.
root@raspixmc:/home/pi#
Intéressant, lorsque je crée un chroot et update-grubque je peux exécuter , même si je suis sur le système d'exploitation que j'ai démarré sur l'USB lui-même, il ne voit pas son propre système d'exploitation!
root@raspixmc:/home/pi# mount /dev/sda1 /mnt
root@raspixmc:/home/pi# cd /mnt
root@raspixmc:/mnt# mount --bind /dev dev/
root@raspixmc:/mnt# mount --bind /sys sys/
root@raspixmc:/mnt# mount --bind /proc proc/
root@raspixmc:/mnt# mount --bind /dev/pts dev/pts
root@raspixmc:/mnt# chroot . bin/bash
root@raspixmc:/# update-grub
Generating grub configuration file ...
Found Raspbian GNU/Linux 9 (stretch) on /dev/mmcblk0p2
done
root@raspixmc:/#
Il ne voit que Raspbian. Cela se produit uniquement lorsque vous essayez d'installer et de mettre à jour GRUB à l'intérieur du conteneur, mais lorsque je quitte le chroot.
Regardez comment cela fonctionne maintenant car je n'ai pas démonté les répertoires chroot:
/dev dev/
/sys sys/
/proc proc/
/dev/pts dev/pts
En dehors de l'esprit du conteneur, grub-ubootj'exécute cette commande avec installé sur Raspbian et pas de Grub sur l'USB contenant Debian dépouillé Debian.
root@raspixmc:/mnt# update-grub
Generating grub configuration file ...
Found Raspbian GNU/Linux 9 (stretch) on /dev/mmcblk0p2
Found Debian GNU/Linux 9 (stretch) on /dev/sda1
done
root@raspixmc:/mnt#
Cela ne se produit pas en utilisant l'une des images officieusement disponibles pour Debian ARM , mais il s'agit évidemment d'une personnalisation qui n'est pas encore disponible pour le débootstrapping.
Il y a vraiment des moments où il vaut mieux juste créer un chemin. La seule possibilité suivante (et probable) est simplement d'écrire GRUB. Et pour cela je vais juste lire sur cette page.
https://www.dedoimedo.com/computers/grub-2.html
Une autre chose que je veux partager à propos de ce problème est une solution qui pourrait fonctionner, mais sachez que les cartes microSD sont très sensibles. J'ai construit mes propres images Linux et j'ai appris cela rapidement. La meilleure chose à faire est d'utiliser Qemu chaque fois que vous le pouvez, mais pour essayer d'effacer une ancienne table de partition, vous pouvez essayer de l'exécuter sgdisk --zap-allsur le lecteur.
sgdisk --zap-all /dev/sdd
En fait, parfois, s'il donne une erreur la première fois et que ce n'est pas une erreur en lecture seule, vous pouvez l'exécuter à nouveau et il finira par retrouver toutes les tables de partition nouvelles ou anciennes.
Et vous pouvez utiliser Qemu pour émuler Raspberry Pi sur un PC AMD / Intel standard. Je le recommanderais. Je sais que c'est plus d'informations que ce qui se rapporte au message d'origine, mais je pense que c'est probablement de cette façon que cette erreur est dérivée. C'est l'âge du conteneur.
Pour tous ceux qui luttent avec cela et qui essaient d'utiliser un USB live ou un autre moyen de chroot pour réinstaller ou installer grub - j'ai traité cela plusieurs fois et j'ai oublié de le documenter avant même si je le voulais.
Le problème auquel vous êtes confronté est que grub n'a pas accès au chemin auquel vous faites référence en tant que source (/ boot) ou destination (votre système et chroot peuvent-ils voir /dev/sdapar exemple?) Ou les deux. Lorsque vous vous préparez à chrooter, vous créez des montures de liaison accessibles dans l'environnement chroot, ou vous le faites dans le chroot à l'aide de mount -t. Il y a tellement de guides en ligne qui le font de toute façon.
Vous devez vous assurer de lier / dev ou simplement la ou les partitions spécifiques contenant les fichiers de démarrage dans / boot (par exemple / dev / sda1). / boot est soit une partition distincte, soit un répertoire dans / Le chroot a besoin d'accéder au lecteur sur lequel vous allez (ré) installer grub. Notez également que si vous n'avez pas de partition de démarrage distincte, mais que vous avez un répertoire de démarrage dans / root avec les fichiers de démarrage (pas seulement un point de montage), il vous suffit de monter la partition contenant root. Vous n'avez alors plus rien à monter sur / root / boot.
Vous devez également vous assurer de lier le système de fichiers proc et le système de fichiers sys, mais tous les guides que j'ai vus ont ces deux-là. Je viens de voir / dev parfois raté. Il peut y avoir des cas où vous n'en avez pas besoin, mais je ne les connais pas.
tl; dr: assurez-vous de lier mount / dev
chrootalors que la question n'est pas de `` chroot ''?
sda6? Ma réponse ici est-elle utile?