¿Por qué todavía se usa el número de unidad / partición?

Muchas veces, especialmente al jugar con los cargadores de arranque, veré que se usan unidades numéricas y números de partición. Por ejemplo, en mi /boot/grub/grub.cfgopinión set root='hd0,gpt2', mis entradas de arranque UEFI a menudo hacen referencia a números de unidad / partición, y parece surgir en casi cualquier contexto en lo que respecta a los gestores de arranque.

Ahora que tenemos UUID y PARTUUID, el direccionamiento de las particiones de esta manera parece increíblemente inestable (afaik, no se garantiza que las unidades se monten siempre en el mismo orden, un usuario puede mover el orden de las unidades que están conectadas a su mobo, etc.)

Por lo tanto, mis preguntas son dobles:

1. ¿Es este esquema de direccionamiento tan inestable como he descrito anteriormente? ¿Me estoy perdiendo algo en el estándar que significa que este esquema es mucho más confiable de lo que esperaba, o este esquema de direccionamiento realmente hará que su sistema no se pueda arrancar (hasta que arregle sus entradas de arranque al menos) como resultado de que sus unidades simplemente se reconozcan en un diferente orden o enchufarlos en diferentes ranuras en su placa base?

2. Si la respuesta a la pregunta anterior es sí, entonces, ¿por qué se sigue utilizando este esquema de direccionamiento? ¿No usar UUID o PARTUUID para todo sería mucho más estable y consistente?

El esquema de numeración simple en realidad no se usa en sistemas recientes (con "reciente" siendo Ubuntu 9 y posterior, otras distribuciones también pueden haberse adaptado en esa época).
Está en lo correcto al observar que la partición raíz se establece con el esquema de numeración simple. Pero esto solo es una configuración predeterminada o alternativa que generalmente se anula con el siguiente comando, como:

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

Esto selecciona la partición raíz en función del UUID del sistema de archivos.

En la práctica, el esquema de numeración simple suele ser estable (siempre que no haya cambios de hardware). La única instancia que observé una numeración no predecible fue el sistema con muchas unidades USB que se enumeraron en base a un patrón de primer orden de llegada y luego se emularon como unidades IDE. Ninguno de estos procesos es inherentemente caótico, por lo que supongo un problema en la implementación de BIOS de ese sistema en particular.

Nota: "partición raíz" en este contexto significa la partición desde la que arrancar, puede ser diferente de la partición que contiene el "sistema raíz / sistema de archivos".

Estrictamente hablando, UUID no se dirige en absoluto.

El direccionamiento es muy, muy simple: lea la unidad X del sector Y, o bien. Lea la dirección de memoria Z, o bien. El direccionamiento es simple, rápido, no deja mucho espacio para la interpretación, y está en todas partes.

UUID no se dirige. En cambio, busca, encuentra, a veces espera que aparezcan los dispositivos y también comprende los sistemas de archivos (★). Y dependiendo de cuántos dispositivos haya, puede llevar mucho tiempo. Y una vez encontrado, volver a abordarlo regularmente es.

En GRUB, esto se llama search(★★) y solo está disponible cuando GRUB ya ha desarrollado alas (la búsqueda es un módulo, al igual que todos los sistemas de archivos que admite, por lo tanto, solo está disponible después de cargar el núcleo). En Linux, se llama (por ejemplo) findfs, findfs buscará los dispositivos de bloque en el sistema buscando un sistema de archivos o partición .

Atraviesa todos los dispositivos de bloque, los despierta del modo de espera, lee los datos y el resultado puede incluso ser aleatorio si el UUID no es único como debería ser (después de un ddaccidente o similar), o no obtiene ningún resultado si el UUID cambió: Los UUID también son propensos a errores de configuración.

En general, los UUID son geniales y, por supuesto, debe usarlos en todas partes si están disponibles, especialmente cuando el direccionamiento tradicional falla porque el orden de las unidades es aleatorio en Linux; pero comprenda que la complejidad está más allá de lo que se supone que debe hacer el direccionamiento simple. Y especialmente en las primeras etapas de los gestores de arranque, es posible que todavía no sea una opción. El direccionamiento viene primero, las alas en crecimiento vienen después.

Para el gestor de arranque, puede que simplemente no sea necesario hacer el esfuerzo (no todos los gestores de arranque admiten una amplia gama de sistemas de archivos como GRUB). Si hd0se garantiza que es "el disco desde el que arrancamos" debido a las circunstancias (el BIOS lo proporciona) y, por lo tanto, si puede descartar problemas de orden de unidades aleatorias, puede que no sea necesario revisar una lista potencialmente enorme de otras particiones en buscar UUID.

Si tiene la suficiente confianza en su configuración para decir que hd0,gpt2es lo que desea, y tiene que serlo, y no puede ser de otra manera, entonces no hay nada de malo en usarlo de esa manera. A veces, el direccionamiento simple y llano funciona bien.

(★) Ya expliqué esto para las ETIQUETAS aquí ...

No existe un estándar genérico para las etiquetas, todo está tejido a mano, consulte, por ejemplo, esta implementación de formatos de superbloques en util-linux . Si inventa un nuevo sistema de archivos mañana, incluso si tiene una etiqueta, no aparecerá hasta que se agregue el soporte.

... y es muy similar para los UUID.

(★★) En realidad, GRUB searchtiene una --hintopción, y ... ahora no he verificado el código fuente, y ni siquiera está documentado en su manual, pero esa opción tendría sentido para darle lo mejor de ambos mundos: la indirecta debe decirle searcha comprobar que la partición primero , y si los partidos UUID como se espera, el dispositivo identificado con el mínimo esfuerzo , y si no coincide, todavía va a caer de nuevo a la plena soplado de búsqueda de trabajo para mantener las cosas de alguna manera .

Además de eso, los UUID encontrados anteriormente tienden a almacenarse en caché, por lo que no tiene que pasar por todos los dispositivos una y otra vez, y esto también funciona muy bien, siempre que el UUID que está buscando realmente exista en algún lugar para hazlo en el caché en primer lugar.

Tampoco olvides las etiquetas. No son tan únicos como los UUID, pero son mucho más informativos y hacen que su fstab sea legible para los humanos. Si se trata de su computadora de escritorio o de una pequeña empresa; en otras palabras, está administrando de unas a unas pocas unidades, es posible que prefiera etiquetas a UUID.

Reflexionando sobre la excelente respuesta de @frostschutz a su pregunta, un escenario en el que probablemente preferiría el direccionamiento de enlace de dispositivo "clásico" es la configuración de VM, especialmente en las nubes VM-for-Hire (abreviadas, confusamente, "IaaS"). Suponga que desea personalizar una imagen de Ubunzima 04.18 . Cree una máquina virtual (desechable) con 2 discos: uno será la unidad del sistema (desechable) y el segundo el que montará y personalizará. Presumiblemente, también monta su partición de arranque UEFI, si desea obtener una nueva versión en su nuevo disco. Suponiendo que haya elegido puntos de montaje para las particiones de destino debajo /mnt, la tabla de montaje deseada se ve como

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

Entonces, crea 2 unidades idénticas a partir de la imagen existente, proporcionada por el proveedor y preparada para la nube, las conecta a una nueva máquina virtual y la inicia. Naturalmente,

• Todas las distribuciones modernas del sistema operativo, nuestra Ubunzima 04.18 imaginaria no es una excepción, se basan en monturas con nombre UUID.
• Todos los discos duros lanzados desde la misma imagen tienen el mismo UUID. Los UUID son únicos, entonces, ¿qué podría salir mal?

Ya ves a dónde va todo esto.

La primera vez que se inició esta frankencontraption, se seleccionó sda9como la partición de inicio EFI, pero Linux decidió volver a montarla sdb1como FS raíz:

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

Y dado que mi script de lanzamiento no estaba preparado para eso, al final tengo una imagen de arranque no arrancable, ¡sin una sola herramienta quejándose en el registro durante el frankenbuild!

Por supuesto , imprimí la mesa de montaje en los registros. Y, por supuesto, el desorden es muy difícil de detectar, ya que el soporte (8) imprime los soportes en el orden medio entre aleatorio y aquel en el que se montaron los dispositivos, por lo que no es sorprendente que no lo haya detectado de inmediato. E imagine, el mismo guión (pero con discos de diferentes imágenes) funcionaba tan bien como Glenfiddich, de 15 años. ¿Adivina cuántas horas pasé peinándome sobre el tronco tratando de resolver el problema?

No existen reglas estrictas y rápidas adecuadas para cualquier situación, desde una PC de escritorio hasta un Linux integrado en un enrutador, desde su teléfono Android hasta un centro de datos en la nube. Se supone que una respuesta SO es objetiva, y mis experiencias o preferencias, por supuesto, no lo son. Prefiero mostrar ejemplos de razonamiento lógico al seleccionar entre diferentes métodos de identificación de particiones:

• Déjalo en paz si no tienes razón para no hacerlo. El UUID es el predeterminado para la mayoría de las distribuciones modernas. Si se trata de agregar una segunda unidad, intente y decida. Lo más probable es que nunca necesite saberlo. Si su sistema aún se inicia y puede ver y particionar el nuevo dispositivo, formatee y agréguelo a fstab (por UUID, por LABEL o por un /devenlace, se aplican las mismas consideraciones). Es solo cuando su sistema se niega a arrancar después de enchufar la unidad adicional, entonces tiene un problema (y tal vez cambiar el orden de arranque en el BIOS UEFI es la salida más rápida).

  Pragmáticamente, etiquetar qué conector SATA va a qué unidad en su propio escritorio puede ser la solución más rápida y fácil, mientras que cambiar la forma en que se inicia el sistema y recuperarse de una falla de arranque bastante probable es, posiblemente, el peor momento. Pero si lo logra para 50 programadores que piensan que tirar una unidad adicional no es un problema digno de molestarlo, al menos no pruebe los límites de su suerte y asegúrese de que sus unidades de arranque iniciales sean vistas por grub como hd0y el sistema como sda.

• Etiquetas para administrar sus propias unidades y particiones en su escritorio o tres, o un pequeño entorno (una sala de estar de una casa llena de ingenieros de software que curiosamente llaman al lugar su "oficina de inicio"). Si extrae un disco físico de la máquina de alguien, sabe de dónde proviene si usa etiquetas de manera consistente.

  Si lsblk (8) dice LABEL=bubba-boot, usted sabe que se ha extraído de la máquina llamada bubba ; además, el bubba-boot me pasa por la lengua mucho más fácilmente que 6864c4ea-f9b9-46db-b875-4d7fc2981007 , que, para mi gusto mimado, es francamente un rompecorazones. Asegurarse de que las etiquetas sean únicas ahora te afecta, pero lo que obtienes a cambio es el significado de la etiqueta.

• /devnomenclatura basada en enlaces cuando comanda un batallón de máquinas virtuales de vida relativamente corta y bajo mantenimiento que son el engendro de la misma imagen, y no apostaría su salario semanal a que todos sus UUID cumplen con la promesa de UU. Cualquier cuerdo servicio CV, ya sea Vyper-H en su propio servidor físico o nube Kugel ni nada, nunca se deberá llamar a la unidad de arranque sde, y el segundo y el único otro sdc². En una máquina física, por otro lado, puede obtener fácilmente esa misma disposición conectando creativamente los cables SATA.

  Ahora estoy divagando, pero en este escenario, sigo la misma ruta con el llamado nombre de interfaz Ethernet "consistente": deshabilítelo en las máquinas virtuales. No me malinterpreten, el nombre es realmente consistente siempre que la NIC que coloque en la ranura PCI 4 no salte repentinamente a la ranura 5 por sí misma mientras no esté mirando (o tal vez incluso mientras lo esté; NIC) no tengas vergüenza) Desafortunadamente, en el medio del "batallón de máquinas virtuales", de hecho lo hacen. En este caso, contra-intuitivamente, eth0es más consistente queenp0s4f6. El proveedor de VM no prometió poner siempre su NIC virtual número 1 en la ranura 4 en el bus PCI 0 (y ninguna de las 3 entidades mencionadas son físicamente reales), y que siempre será la Función 6. Pero puede muchos confían en la primera interfaz que va antes que la segunda, considerando que normalmente tienen el mismo módulo de controlador, comúnmente de la familia virtio (y si la primera NIC no es siempre eth0, la misma nota² todavía se aplica).

  ---

¹ Figurativamente, por supuesto. He estado en este negocio durante demasiado tiempo como para que me quede algo.
² Si lo hicieran, consideraría seriamente huir gritando de ellos cambiando el proveedor o el software del hipervisor VM.

Ambos esquemas se pueden combinar y combinar con la mayoría de las distribuciones de Linux.

Las consecuencias pueden ser deseables o indeseables dependiendo del caso de uso; por ejemplo, uno podría preferir el esquema anterior (e incluso deshabilitar los hacks de persistencia de estilo udev) si el reemplazo activo de unidades (hardware virtual o hardware real) sin tener que modificar los archivos de configuración es querido.

La respuesta a su segunda pregunta ("¿por qué se sigue usando este esquema de direccionamiento?") Es, supongo, inercia. Sí, es totalmente posible usar solo UUID en discos con particiones GPT. Puede usar UUID en lugar de /dev/xxxnombres en /etc/fstab. Y ahora que tenemos la Especificación de particiones detectables , en muchos casos ya ni siquiera tiene que especificar los UUID, solo particione su disco con el tipo de partición y las particiones se recogerán automáticamente. En mi máquina root=falta la entrada por completo de la línea de comando del kernel.

Y hablando de cargadores de arranque: GRUB es superfluo en las PC modernas de UEFI, en el sentido de que tiene muy poco que ver con el arranque de la máquina. Hoy en día, GRUB simplemente funciona como un programa de selección de kernel, para cuya tarea hay alternativas más simples y mejores disponibles, como systemd-boot.