Arrière-plan :
- Ubuntu Xenial
- ZFS installé pour le disque système (donc, vous savez :rpool/ROOT)
- Le système fonctionne bien, mais lors de la mise à jour du noyau,
grub-probeaboie l'erreur mentionnée ci-dessus - Je préfère ne pas redémarrer maintenant
Il y a une discussion ici à propos de grub-probe et comment ça devrait "juste être mieux", mais cela aide jusqu'à ce que cela se produise. J'ai eu l'idée de cette discussion.
Plus de détails :une instance complète de l'erreur (pour mon système) ressemble à :
/usr/sbin/grub-probe: error: failed to get canonical path of `/dev/ata-ADATA_SP550_2G1520009135-part1'.
Ceci est enfoui dans une multitude de détails jaillis d'une commande apt pour installer les pilotes graphiques (mais ce n'est pas important).
Ce disque correspond à une de mes partitions ZIL. J'ai ajouté ZIL et le cache une fois l'installation terminée, donc je suppose que c'est pourquoi je n'ai pas vu le problème auparavant. Je n'ai pas encore redémarré, et c'est pourquoi je vois le problème du tout. Oui, vous pouvez redémarrer pour résoudre tout cela, mais en supposant que vous ne vouliez pas faire cela, lisez la suite :
Si je regarde dans /dev, je vois des liens vers tous mes disques ZFS qui ressemblent à :
lrwxrwxrwx 1 root root 4 Sep 16 23:31 ata-WDC_WD10EARS-00Y5B1_WD-WMAV51436394-part1 -> sdc1
lrwxrwxrwx 1 root root 4 Sep 16 23:31 ata-WDC_WD20EZRX-00D8PB0_WD-WCC4MK86SWX7-part1 -> sdd1
lrwxrwxrwx 1 root root 4 Sep 16 23:31 ata-WDC_WD20EZRX-00D8PB0_WD-WCC4N1085683-part1 -> sde1
lrwxrwxrwx 1 root root 4 Sep 16 23:31 ata-WDC_WD2500JS-22MHB0_WD-WCANK4053187-part1 -> sda1
… mais notamment aucun pour les partitions ZIL.
Je peux tester la situation en exécutant :
$ sudo grub-probe /
grub-probe: error: failed to get canonical path of `/dev/ata-ADATA_SP550_2G1520009135-part1'.
Donc la question est :comment résoudre ce problème donc grub-probe se comporte ?
Réponse acceptée :
Il existe une variable d'environnement qui corrige cela. Le problème de ma lecture semble être que Grub aime l'idée de "soutenir" zfs mais pas l'idée de résoudre les problèmes liés à zfs dans Grub. En particulier, sa mauvaise gestion des erreurs en termes de recherche de choses.
Par exemple, les outils grub livrés avec Ubuntu 16.x ne parviendront pas à trouver /boot sur un volume ZFS sans intervention de l'utilisateur, puis écriront avec plaisir certains (mais pas tous) les fichiers nécessaires en sortie de l'utilitaire que vous utilisez sur le /boot dossier qu'il vient de vous dire qu'il n'a pas pu trouver.
En tout cas…
http://list.zfsonlinux.org/pipermail/zfs-discuss/2016-June/025765.html
To check if you have commit (should see full paths):
ZPOOL_VDEV_NAME_PATH=1 zpool status
If so you can do:
ZPOOL_VDEV_NAME_PATH=1 grub-whatevs ....
Vous pouvez transmettre la variable en tant qu'entrée aux utilitaires grub nécessaires, ou vous pouvez la spécifier en tant que variable shell dans le .bashrc ou le .profile de root ou quelque chose du genre avec…
export ZPOOL_VDEV_NAME_PATH=YES
La variable oblige zpool à signaler les chemins complets, plutôt que les chemins relatifs /dev vers les disques qui peuvent ou non fonctionner correctement avec zfs. Les utilitaires Grub vérifient l'état de zpool pour les pools zfs afin de trouver les disques qui les contiennent. Par conséquent, la modification de la sortie de zpool status corrige grub.
Connexe :Comment supprimer les entrées EFI inutiles de GRUB ?Je suis d'accord que les utilisateurs ne devraient pas avoir à faire face à cela, en référence au commentaire de femulator. La vraie solution ? Comme tous les autres projets open source qui languissent dans des bogues qui ne sont jamais corrigés. Forkez-le, corrigez-le vous-même et arrêtez d'utiliser le projet source/la bibliothèque/peu importe. La façon FOSS de « virer » quelqu'un, en d'autres termes;). Apparemment, Debian était au courant de ce bogue particulier il y a sept ans.
C'était la seule chose qui m'empêchait de migrer avec succès un pool de démarrage FreeBSD RaidZ vers Ubuntu. Si quelqu'un d'autre tente quelque chose de similaire, le processus est relativement simple, tant que vous comprenez suffisamment bien ZFS pour ignorer les parties de la documentation de Grub et zfsonlinux qui sont erronées (comme la configuration de votre ensemble de données racine pour qu'il ne soit pas monté automatiquement, hein… ? Comment va-t-il exactement démarrer alors ?). Il est quelque peu ironique qu'Ubuntu souligne dans sa documentation que le chargeur de démarrage est la "fonctionnalité" la moins sécurisée de Linux, ce qui est vrai je suppose, mais dans ce cas, c'est aussi le défaut flagrant d'Ubuntu. Il m'aurait fallu une heure ou deux pour migrer un pool BSD ZFS vers un autre système d'exploitation si j'avais pu le faire en utilisant les utilitaires Sun/Solaris qui fonctionnent réellement. Le problème est que j'ai dû utiliser des utilitaires Linux (comme Grub) qui ne fonctionnent pas (ou à peine) à un moment donné, donc c'est la faute des deux autres jours que j'ai passés à résoudre ce problème. Ubuntu serait bien meilleur s'il n'avait pas besoin de grub pour démarrer...