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

Question

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.cfg Je vois set root='hd0,gpt2', mes entrées de démarrage UEFI font souvent référence à des numéros de lecteur/partition, et elles semblent apparaître dans presque tous les contextes concernant les chargeurs de démarrage.

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:

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 lecteurs sont simplement reconnus dans un ordre différent ou en les branchant dans différents emplacements de votre carte mère?
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?

Hermann · Accepted Answer

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 changements matériels). 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 la mise en œuvre 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".

frostschutz · Answer

À strictement parler, 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 aussi de comprendre les systèmes de fichiers (★). Et selon le nombre d'appareils, cela peut prendre très longtemps. Et une fois trouvé, il revient à l'adressage régulier.

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 pris en charge, donc uniquement disponible après le chargement du noyau.) Sous Linux, il est (par exemple) appelé 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 de bloc, 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 dd accident ou similaire), ou vous n'obtenez pas résultat si l'UUID a changé - les UUID sont également sujets aux erreurs de configuration.

En général, les UUID sont excellents, et bien sûr, vous devez les utiliser partout s'ils sont 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 hd0 est garanti d'être "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 à la recherche d'UUID.

Si vous êtes suffisamment confiant dans votre configuration pour dire que hd0,gpt2 est celui que vous voulez, et il 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.

(★) Je l'ai expliqué précédemment 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 des 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, search de GRUB a un --hint option, 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'indice devrait dire search à vérifiez d'abord cette partition , et si l'UUID correspond comme prévu, il a identifié le périphérique avec minimal effort , 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.

kkm · Answer

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 sur @ frostschutz excellente réponse à votre question, un scénario où vous préféreriez probablement l'adressage de lien de périphérique "classique" est la configuration VM, en particulier dans la machine virtuelle à louer (en abrégé , confusément, "IaaS") nuages. Supposons que vous souhaitiez personnaliser une image Ubunzima 04.18 . Vous créez un (jetable) VM 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 à un nouveau VM et démarrez-le. Naturellement,

Toutes les distributions OS 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 choisi sda9 Comme partition de démarrage EFI, mais Linux a décidé de remonter sdb1 En tant 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 aléatoire et celui dans lequel les appareils ont été montés, il était donc pas étonnant que je ne l'ai pas 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. L'UUID est 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, formatez-le et ajoutez-le à fstab (par UUID, par LABEL ou par un lien /dev, 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 changeant la façon dont le système démarre et en récupérant d'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, ne testez pas au moins les limites de votre chance et assurez-vous que leurs disques de démarrage initiaux sont tous vus par grub comme hd0 Et le système comme sda.
Étiquettes pour gérer vos propres lecteurs et partitions sur votre bureau ou trois, ou un petit milieu (un salon d'une maison remplie d'ingénieurs logiciels qui appellent de façon amusante le lieu de leur "startup office"). Si vous retirez un lecteur physique de la machine de quelqu'un, vous savez d'où il provient si vous utilisez des étiquettes de manière cohérente.

Si lsblk (8) dit LABEL=bubba-boot, Vous savez qu'il a été retiré de la machine appelée bubba ; en outre, bubba-boot roule sur ma langue beaucoup plus facilement que 6864c4ea-f9b9-46db-b875-4d7fc2981007 , qui, à mon avis, goût gâté, est carrément un briseur de mâchoire. S'assurer que les étiquettes sont uniques vous incombe désormais, mais ce que vous obtenez en retour, c'est la signification de l'étiquette.
/dev - dénomination basée sur les liens lors du commandement d'un bataillon de machines virtuelles à durée de vie relativement courte et nécessitant peu d'entretien, qui sont le point de départ de la même image , et vous ne parieriez pas votre salaire hebdomadaire que tous leurs UUID respectent la promesse UU. Tout service sain VM, 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 sdc². Dans une machine physique, en revanche, 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 VM. Ne vous méprenez pas, la dénomination est vraiment cohérente tant que le NIC que vous mettez dans le slot PCI 4 ne sautera pas soudainement au slot 5 sur son propre caprice pendant que vous ne regardez pas (ou peut-être même pendant que vous êtes; les cartes réseau n'ont aucune honte). Malheureusement, dans le milieu du "bataillon de VM", c'est effectivement le cas. Dans ce cas, contre-intuitivement, eth0 Est plus cohérent que enp0s4f6. Le fournisseur VM n'a pas promis de toujours mettre son numéro virtuel NIC 1 dans l'emplacement 4 du bus PCI 0 (et aucune des 3 entités mentionnées n'est physiquement réelle), et qu'il le sera toujours la fonction 6. Mais vous pouvez à peu près compter sur la première interface avant 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, je considérerais sérieusement ~~fuir en criant d'eux~~ changer de fournisseur ou de logiciel d'hyperviseur VM.

rackandboneman · Answer

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.

Johan Myr&#233;en · Answer

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/xxx noms 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, il vous suffit de partitionner votre disque avec le type de partition et les partitions seront récupérées automatiquement. Sur ma machine, le root= l'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, en ce sens qu'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 du noyau, pour lequel il existe des alternatives plus simples et meilleures, comme systemd-boot.