Inversion des disques

Support Debian
#1

Bonjour,
Sur une machine avec 4 disques NVME( nvme0n1, nvme0n2, nvme0n3, et nvme0n4), j’ai une installation preseed qui installe Debian sur le 3ème disque nvme0n3, et dont un script de post installation, lancé au premier redémarrage finalise en intégrant le disque nvme0n4 dans le volume group LVM.
Mon problème c’est qu’ensuite, en redémarrant, je me retrouve avec les installations sur les disques nvme0n1 et nvme0n2. Je n’arrive pas à identifier le mécanisme qui produit cette inversion.

Si je démarre avec une live, je retrouve bien mon installation sur les disques nvme0n3 et nvme0n4.

EDIT: j’ai refait un test, et il semble que ce soit l’installation de l’UKI (Unified Kernel Image) qui provoque cette bascule. Je n’en ai pas découvert la cause pour le moment. Cela étant durant l’installation j’ai quand mêmle une inversion lors de l’intégration du deuxième disque.: nvme0n3 est le disque installé, et nvme0n4 celui qui est ajouté. Mais au final, ils échangent leur place.

#2

Grub est installé sur les 4 disques, pas d’ancienne installation de grub ?

Il me semble que la détection des controlleur est parallélisé durant l’installation, ça va être coton de gérer ça de façon reproductible.

#3

Je pars de disque entièrement wipés pour mes tests. Et je n’utilise pas grub mais systemd-boot.

En fait c’est reproductible à 100%. A chaque test le résultat est le même.

Effectivement j’avais identifié cette parallélisation. Je ne sais pas pourquoi elle se fait différemment dans un cas plutôt qu’un autre.

#4

Ne connaissant pas le sujet, je me permets juste une question :

N’y-a-t-il pas des identifiants, tel les UUID, pour déclarer les disques et s’assurer ainsi de toujours avoir bien la « chaîne » de déclarations et son ordonnance ?

#5

Tu ne peux pas avec les commandes telles que cryptsetup, l’UKI ou même update-init-ramfs (hors ce qui est mis dans le /etc/cryptab.

Attention, les UUID sont bien conservées. Seuls les noms changent; mais la partie cryptsetup n’utilise que des device nommés, je me retrouve a à avoir une installation qui ne permet pas la suivante (je fait deux installations successives, l’une sur les deux premiers disques, l’autre sur les 2 derniers).

C’est parce que l’installation doit être capable de respecter absolument l’utilisation des deux disques prévus pour éviter, lors de l’utilisation reéelle de détruire une installation existante.

En clair, j’ai une installation actuelle sur u ne machine sur les disques 3 et 4. Et je veux refaire complètement l’installation sur les disque 1 et , mais sans toucher d’aucune façon aux disques 3 et 4.
Dans mes tests, les disques sont complètement vides, ils n’ont pas de UUID. Je fait une premier install sur deux disque.
Ensuite je refait une installation sur les deux autres en vérifiant que les deux premier n’ont pas été impactés.

#6

Donc, si je comprends bien la pertinence des informations que tu nous transmets :

  • tu as bien une identification matérielle
  • mais tu ne peux pas t’en servir, car le setup se sert plutôt des noms de matériels ; (ceci ne me semble pas être une information fiable, non pas ce que tu transmets ici, mais le fonctionnement)

Ça, c’est un « handicap » !
Il n’y a aucun moyen de transmettre aux disques ces fameux UUID sur lesquels se baser ?!

J’écris que c’est un handicap ; je m’explique :
Comme tu le sais, en sus de Debian (particulièrement la Sid), j’affectionne OpenBSD. Une des raisons pour lesquelles est l’identification matérielle sur laquelle tu peux absolument te baser, et surtout dans le contexte de chiffrement logiciel. Un disque dur te lâche, ou tu veux reproduire les mêmes paramètres d’installation, tu peux changer l’identification matérielle des disques avant, et zou l’installation se fait sans plus de soucis.

Et pour avoir testé, c’est agréable de pouvoir changer de disque, de lui transmettre un DUID nécessaire, et de procéder au fonctionnement attendu.
(ce n’est pas l’objet, mais si tu veux en savoir plus… tu sais où me trouver) :wink:

#7

Quand les disques sont « neuf », il n’y a pas de label (gtp, msdos), pas d’uuid non plus; comme on peut le constater avec un simple lsblk -f, ou même blkid

Donc je ne peux pas déterminer un identifiant autre que /dev/nvme* pour faire mon installation.

Pour ça il faut une partition existante.

C’est effectivement un handicap. Cela étant, tant qu’il n’y a pas de partitions formatée; car une fois des partitions créées et formatée, il y a alors des uuid existants.
Si la partition est juste crée, il n’y a qu’un PARTUUID, l’UUID lui arrive avec le formattage.

Comme mon installation est déterministe quand aux disques visés par l’installation (normal avec un preseed), si les noms change alors le prédéterminisme conduit à l’écrasement de l’installation précédente.

Cela étant je pourrais me contenter de faire une installation sur un seul disque et ajouter le second ensuite. Ce problème est du au fait que Debian ne sait pas faire d’installation chiffrée correcte sur deux disques dans un même LVM autrement qu’en manuel.
En manuel il me faut 2h au moins pour que l’installation soit faite. Il ne m’en faut que 30 à 40mn en preseed.parted

+1 :slight_smile:

#8

Je comprend.

Alors que sous OpenBSD, l’identifiant matériel est vraiment indépendant et accessible au-travers de la commande disklabel, et ça, ça change tout :wink:

#9

et c’est d’autant plus difficile à tester qu’il n’y a qu’un seul contrôleur nvme sur une virtualbox, alors que j’en ai deux sur ma carte mère :slight_smile:

#10

pfff !
Tu aimes les défis, toi :wink:

1 J'aime
#11

Mais j’ai peut être trouvé une piste avec les identifiants matériel et les information bus, tels qu’on peut les voir dans lshw :smiley: