Pourquoi le numéro de lecteur / partition est-il toujours utilisé?

Plusieurs fois, en particulier lorsque je joue avec les chargeurs de démarrage, je vois les numéros de lecteur numérique et de partition utilisés. Par exemple, dans mon /boot/grub/grub.cfgje vois set root='hd0,gpt2', mes entrées de démarrage UEFI font souvent référence à des numéros de lecteur / partition, et il semble surgir dans presque tous les contextes où les chargeurs de démarrage sont concernés.

Maintenant que nous avons UUID et PARTUUID, l'adressage des partitions de cette manière semble incroyablement instable (afaik, les lecteurs ne sont pas garantis d'être montés dans le même ordre toujours, un utilisateur peut déplacer l'ordre des lecteurs connectés à leur mobo, etc.)

Mes questions sont donc doubles:

1. Ce schéma d'adressage est-il aussi instable que je l'ai indiqué ci-dessus? Suis-je en train de manquer quelque chose dans la norme qui signifie que ce schéma est beaucoup plus fiable que prévu, ou ce schéma d'adressage rendra-t-il vraiment votre système non amorçable (jusqu'à ce que vous corrigiez vos entrées de démarrage au moins) du fait que vos disques sont simplement reconnus dans un ordre différent ou en les branchant dans différents emplacements de votre carte mère?

2. Si la réponse à la question ci-dessus est oui, alors pourquoi ce schéma d'adressage continue-t-il d'être utilisé? L'utilisation d'UUID ou de PARTUUID pour tout ne serait-elle pas beaucoup plus stable et cohérente?

Le schéma de numérotation simple n'est pas réellement utilisé dans les systèmes récents (avec "récent" étant Ubuntu 9 et versions ultérieures, d'autres distributions peuvent également avoir été adaptées à cette époque).
Vous avez raison d'observer que la partition racine est définie avec le schéma de numérotation simple. Mais ce n'est qu'un paramètre par défaut ou de secours qui est généralement remplacé par la toute prochaine commande, telle que:

search --no-floppy --fs-uuid --set=root 74686973-6973-616e-6578-616d706c650a

Cela sélectionne la partition racine en fonction de l'UUID du système de fichiers.

En pratique, le schéma de numérotation simple est généralement stable (tant qu'il n'y a pas de changement matériel). Le seul cas où j'ai observé une numérotation non prévisible était un système avec de nombreux lecteurs USB qui étaient énumérés sur la base d'un modèle de premier arrivé, premier servi, puis émulés en tant que lecteurs IDE. Aucun de ces processus n'est intrinsèquement chaotique, donc je suppose un problème dans l'implémentation du BIOS de ces systèmes particuliers.

Remarque: "partition racine" dans ce contexte signifie la partition à partir de laquelle il peut démarrer, elle peut être différente de la partition contenant le "root aka. / Système de fichiers".

À strictement parler, l' UUID ne s'adresse pas du tout.

L'adressage est très, très simple: lire le lecteur X secteur Y - ou bien. Lire l'adresse mémoire Z - ou autre. L'adressage est simple, rapide, ne laisse pas beaucoup de place à l'interprétation, et il est partout.

L'UUID ne s'adresse pas. Au lieu de cela, il s'agit de rechercher, de trouver, parfois d'attendre que les appareils apparaissent, et également de comprendre les systèmes de fichiers (★). Et selon le nombre d'appareils, cela peut prendre très longtemps. Et une fois trouvé, retour à l'adressage régulier c'est.

Dans GRUB, cela s'appelle search(★★) et il n'est disponible que lorsque GRUB a déjà développé des ailes (la recherche est un module, comme tous les systèmes de fichiers qu'il prend en charge, donc uniquement disponible après le chargement du noyau). Sous Linux, il s'appelle (par exemple) findfs, findfs recherchera les périphériques de bloc dans le système à la recherche d'un système de fichiers ou d'une partition .

Il passe par tous les périphériques, les sort du mode veille, lit les données et le résultat peut même être aléatoire si l'UUID n'est pas unique comme il se doit (après un ddaccident ou similaire), ou vous n'obtenez aucun résultat si l'UUID a changé - Les UUID sont également sujets à des erreurs de configuration.

En général, les UUID sont excellents, et bien sûr, vous devriez les utiliser partout si disponibles, en particulier lorsque l'adressage traditionnel est voué à l'échec car l'ordre des lecteurs est aléatoire sous Linux; mais comprenez que la complexité est au-delà de ce que l'adressage simple est censé faire. Et surtout aux tout premiers stades des chargeurs de démarrage, ce n'est peut-être pas encore une option. L'adressage vient en premier, la croissance des ailes vient plus tard.

Pour le chargeur de démarrage, il pourrait tout simplement ne pas être nécessaire de faire l'effort (tous les chargeurs de démarrage ne prennent pas en charge une large gamme de systèmes de fichiers comme GRUB). Si hd0est garanti "le disque sur lequel nous avons démarré" en raison des circonstances (le BIOS fournit), et donc si vous pouvez exclure des problèmes d'ordre de lecteur aléatoire, il n'est peut-être pas nécessaire de parcourir une liste potentiellement énorme d'autres partitions dans rechercher des UUID.

Si vous êtes suffisamment confiant dans votre configuration pour dire que hd0,gpt2c'est celle que vous voulez, et qu'elle doit l'être, et il ne peut en être autrement, alors il n'y a rien de mal à l'utiliser comme ça. Parfois, un adressage clair et simple fonctionne très bien.

(★) J'ai déjà expliqué cela pour les ÉTIQUETTES ici ...

Il n'y a pas de standard générique pour les étiquettes, tout est tricoté à la main, voir par exemple cette implémentation de formats de superblocs dans util-linux . Si vous inventez un nouveau système de fichiers demain, même s'il a une étiquette, il n'apparaîtra que lorsque le support sera ajouté.

... et c'est à peu près la même chose pour les UUID.

(★★) En fait, GRUB searcha une --hintoption, et ... maintenant je n'ai pas vérifié le code source, et ce n'est même pas documenté dans leur manuel, mais une telle option aurait du sens pour vous donner le meilleur des deux mondes: l'indication devrait indiquer searchde vérifier cette partition en premier , et si l'UUID correspond comme prévu, il a identifié le périphérique avec un effort minimal , et s'il ne correspond pas, il reviendra toujours à la recherche complète pour que les choses fonctionnent d'une manière ou d'une autre .

En plus de cela, les UUID trouvés précédemment ont tendance à être mis en cache, de sorte qu'il n'a pas à parcourir tous les appareils encore et encore et encore - et cela fonctionne également très bien, à condition que l'UUID que vous recherchez existe réellement quelque part pour faire dans le cache en premier lieu.

N'oubliez pas non plus les étiquettes. Ils ne sont pas aussi uniques que les UUID, mais ils sont beaucoup plus informatifs et rendent votre fstab lisible par l'homme. Si c'est votre bureau ou une petite entreprise - en d'autres termes, vous gérez quelques à quelques dizaines de disques, vous pouvez préférer les étiquettes aux UUID.

Réfléchissant à l' excellente réponse de @ frostschutz à votre question, un scénario où vous préféreriez probablement l'adressage de lien d'appareil "classique" est la configuration de la machine virtuelle, en particulier dans les nuages ​​de machines virtuelles à louer (en abrégé, confus, "IaaS"). Supposons que vous souhaitiez personnaliser une image Ubunzima 04.18 . Vous créez une machine virtuelle (jetable) avec 2 disques: l'un sera le lecteur système (jetable) et le second celui que vous monterez et personnaliserez. Vraisemblablement, vous montez également sa partition de démarrage UEFI, si vous souhaitez supprimer un nouveau grub sur votre nouveau disque. En supposant que vous avez choisi des points de montage pour les partitions cibles sous /mnt, votre table de montage souhaitée ressemble à

/dev/sda1    /
/dev/sda9    /boot/efi
/dev/sdb1    /mnt/root
/dev/sdb9    /mnt/efi

Vous créez donc 2 disques identiques à partir de l'image existante, fournie par le fournisseur et prête pour le cloud, les connectez à une nouvelle machine virtuelle et démarrez-la. Naturellement,

• Toutes les distributions de systèmes d'exploitation modernes, notre imaginaire Ubunzima 04.18 n'étant pas une exception, s'appuient sur des montures nommées UUID.
• Tous les disques durs déployés à partir de la même image ont le même UUID. Les UUID sont uniques, alors qu'est-ce qui pourrait mal tourner?

Vous voyez déjà où tout cela va.

La première fois que cette frankencontraption a démarré, elle a été choisie sda9comme partition de démarrage EFI, mais Linux a décidé de remonter en sdb1tant que FS racine:

/dev/sda1    /mnt/root
/dev/sdb1    /
/dev/sda9    /boot/efi
/dev/sdb9    /mnt/efi

Et comme mon script de déploiement n'était pas préparé à cela, j'ai une image ratée non amorçable à la fin, sans qu'un seul outil ne se plaint dans le journal pendant la construction de frankenbuild!

Bien sûr, j'ai imprimé la table de montage dans les journaux. Et bien sûr, le gâchis est très difficile à repérer, car mount (8) imprime les montages dans l'ordre à mi-chemin entre le hasard et celui dans lequel les appareils ont été montés, il n'était donc pas surprenant de ne pas l'avoir repéré tout de suite. Et imaginez, le même script (mais avec des disques d'images différentes) fonctionnait auparavant aussi bien que Glenfiddich, 15 ans. Devinez combien d'heures j'ai passé à tirer mes cheveux¹ sur la bûche pour essayer de comprendre le problème?

Il n'y a pas de règles strictes et rapides adaptées à toutes les situations, d'un ordinateur de bureau à un Linux intégré dans un routeur à votre téléphone Android à un centre de données cloud. Une réponse SO est censée être objective, et mes expériences ou préférences ne le sont bien sûr pas. Je préfère donc montrer des exemples de raisonnement logique lors de la sélection parmi différentes méthodes d'identification des partitions:

• Laissez-le tranquille si vous n'avez aucune raison de ne pas le faire. Les UUID sont la valeur par défaut pour la plupart des distributions modernes. S'il s'agit d'ajouter un deuxième lecteur, essayez alors et décidez. Les chances sont que vous n'aurez même jamais besoin de savoir. Si votre système démarre toujours et que vous pouvez voir et partitionner le nouveau périphérique, le formater et l'ajouter à fstab (par UUID, par LABEL ou par un /devlien, les mêmes considérations s'appliquent). Ce n'est que lorsque votre système refuse de démarrer après avoir branché le lecteur supplémentaire, que vous avez un problème (et peut-être que changer l'ordre de démarrage dans le BIOS UEFI est la solution la plus rapide).

  De manière pragmatique, étiqueter quel connecteur SATA va vers quel lecteur sur votre propre bureau peut être la solution la plus rapide et la plus simple, tout en modifiant la façon dont le système démarre et en récupérant après une défaillance de démarrage très probable est, sans doute, le pire gobeur de temps. Mais si vous le gérez pour 50 programmeurs qui pensent que jeter un disque supplémentaire n'est pas un problème digne de vous déranger, au moins ne testez pas les limites de votre chance et assurez-vous que leurs disques de démarrage initiaux sont tous vus par grub comme hd0et le système comme sda.

• Des étiquettes pour gérer vos propres disques et partitions dans votre bureau ou trois, ou dans un petit milieu (un salon d'une maison remplie d'ingénieurs logiciels qui appellent drôlement l'endroit «leur bureau de démarrage»). Si vous retirez un lecteur physique de la machine de quelqu'un, vous savez d'où il provient si vous utilisez régulièrement des étiquettes.

  Si lsblk (8) le dit LABEL=bubba-boot, vous savez qu'il a été retiré de la machine appelée bubba ; de plus, le bubba-boot roule sur ma langue beaucoup plus facilement que 6864c4ea-f9b9-46db-b875-4d7fc2981007 , qui, à mon goût gâté, est carrément un briseur de mâchoire. Faire en sorte que les étiquettes soient uniques vous incombe désormais, mais ce que vous obtenez en retour, c'est la signification de l'étiquette.

• /dev-nom basé sur les liens lorsque vous commandez un bataillon de machines virtuelles à durée de vie relativement courte et à faible maintenance qui sont le germe de la même image, et vous ne parieriez pas votre salaire hebdomadaire que tous leurs UUID sont à la hauteur de la promesse de UU. N'importe quel service VM sain , que ce soit Vyper-H sur votre propre serveur physique ou Kugel Cloud ou quoi que ce soit, ne doit jamais appeler votre lecteur de démarrage sde, et le second et le seul autre sdc². Dans une machine physique, d'autre part, vous pouvez facilement obtenir le même arrangement en connectant de manière créative des câbles SATA.

  Je m'éloigne maintenant, mais dans ce scénario, je vais dans le même sens avec la dénomination de l'interface Ethernet dite «cohérente»: désactivez-la dans les machines virtuelles. Ne vous méprenez pas, la dénomination est vraiment cohérente tant que la carte réseau que vous placez dans l'emplacement PCI 4 ne sautera pas soudainement à l'emplacement 5 par son propre caprice pendant que vous ne regardez pas (ou peut-être même pendant que vous êtes; les cartes réseau n'ayez aucune honte). Malheureusement, dans le milieu du «bataillon de VM», c'est effectivement le cas. Dans ce cas, contre-intuitivement, eth0est plus cohérent queenp0s4f6. Le fournisseur de VM n'a pas promis de toujours mettre son NIC virtuel numéro 1 dans l'emplacement 4 sur le bus PCI 0 (et aucune des 3 entités mentionnées n'est physiquement réelle), et que ce sera toujours la fonction 6. Mais vous pouvez assez beaucoup dépendent de la première interface qui précède la seconde, étant donné qu'ils ont normalement le même module de pilote, généralement de la famille virtio (et si le premier NIC n'est pas toujours eth0, la même note² s'applique toujours).

  ---

¹ Au figuré, bien sûr. Ça fait trop longtemps que je suis dans cette affaire pour en avoir.
² S'ils le faisaient, j'envisagerais sérieusement de fuir en criant en changeant de fournisseur ou de logiciel d'hyperviseur VM.

Les deux schémas peuvent être mélangés et adaptés à la plupart des distributions Linux.

Les conséquences peuvent être souhaitables ou indésirables selon le cas d'utilisation - par exemple, on pourrait préférer l'ancien schéma (et même désactiver les hacks de persistance de style udev) si le remplacement à chaud des disques (matériel virtuel ou matériel réel) sans avoir à modifier les fichiers de configuration est voulait.

La réponse à votre deuxième question ("pourquoi ce schéma d'adressage continue-t-il d'être utilisé?") Est, je suppose, l'inertie. Oui, il est totalement possible d'utiliser uniquement des UUID sur des disques partitionnés GPT. Vous pouvez utiliser des UUID au lieu de /dev/xxxnoms dans /etc/fstab. Et maintenant que nous avons la spécification des partitions détectables , dans de nombreux cas, vous n'avez même plus besoin de spécifier les UUID, partitionnez simplement votre disque avec le type de partition et les partitions seront récupérées automatiquement. Sur ma machine, l' root=entrée est complètement absente de la ligne de commande du noyau.

Et en parlant de chargeurs de démarrage: GRUB est surtout superflu sur les PC UEFI modernes, dans le sens où il a très peu à voir avec le démarrage de la machine. De nos jours, GRUB fonctionne simplement comme un programme de sélection de noyau, pour laquelle il existe des alternatives plus simples et meilleures disponibles, comme systemd-boot.