CHROOT > GRUB : "WARNING: Device /dev/sda not initialized in udev database..." Le sujet est résolu

[dezix]

Bonjour,

Je reprends le cours de mon expérimentation sur un VPS d'OVH ....


Le contexte :

Le but est de reconfigurer Buster installé automatiquement par OVH sur /dev/sda1 uniquement
sur LVM en :

• conservant /boot sur /dev/sda1 (réduit à 200Mo)
• le reste sur un jeux de Volumes Logiques (LV) :
  • lv_racine
  • lv_home
  • lv_usr
  • lv_var-cache
  • lv_var-log
  • lv_tmp
  • lv_svr-http
  • lv_svr-ftp
  • lv_svr-mail

Je procède par étapes afin de pouvoir vérifier à chaque étape si des problèmes surgissent, afin de les circonscrire plus facilement.

La situation :

/boot sur /dev/sda1
/ sur /dev/sda2 sda2 créé pour étape intermédiaire ⇒ clone DD de sda1 initial (système complet)
OK! vérifié

Création /dev/sda3 pour LVM et création des LV décrits plus haut
OK! vérifié

En session Live de maintenance,
tout le contenu de la racine sauf celui de /boot copié sur : lv_racine
avec :

/dev/sda2 monté sur /mnt/sda2
/dev/vg/lv_racine monté sur /mnt/lv_racine

Code : Tout sélectionner

# cd /mnt/sda2
# cp -afv * /mnt/lv_racine
# cd /mnt/lv_racine/boot
# rm -rf *

À ce stade dans la session Live de maintenance,
je veux réinstaller grub dans un chroot
pour rebooter le système afin de vérifier son fonctionnement avant de poursuivre le déplacement des sous-répertoires de la racine vers leurs destinations finales.

j'ai donc fait :

/dev/vg/lv_racine est déjà monté sur /mnt/lv_racine

Code : Tout sélectionner

# mount --bind /dev /mnt/lv_racine/dev
# mount -t proc /proc /mnt/lv_racine/proc
# mount -t sysfs /sys /mnt/lv_racine/sys

# chroot /mnt/lv_racine

# mount /dev/sda1 /boot
# update-grub

C'est là que survient le problème ⇒ update-grub n'aboutit pas.

Comme os-prober ne l'était pas, je l'ai installé et :

Code : Tout sélectionner

# os-prober
  WARNING: Device /dev/sda not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/vg0/vg0_lv_racine not initialized in udev database even after waiting 10000000 microseconds.
  WARNING: Device /dev/sda1 not initialized in udev database even after waiting 10000000 microseconds.
.....
ça tourne en boucle après avoir afficher tous les volumes
puis [Ctrl+C] pour en sortir
^C
grep: /tmp/os-prober.38wJ2n/raided-map: No such file or directory
grep: /tmp/os-prober.38wJ2n/swaps-map: No such file or directory
grep: /tmp/os-prober.38wJ2n/mounted-map: No such file or directory
....

UDEV >> ça dépasse mes connaissances :((

Comment doi-je procéder pour débloquer cette situation et faire la MàJ de grub.cfg et réinstaller GRUB ?

J'ai trouvé 2 rapports de bugs :

Red Hat Bugzilla – Bug 1676612 |
lvm tools expect access to udev, even when disabled in the configuration



Debian Bug report logs - #918590 |
WARNING: Device /dev/md0 not initialized in udev database even after waiting 10000000 microseconds



Et peut-être une solution (ArchLinux):

LVM on LUKS, grub-mkconfig hangs - grub-probe gives error / Installation / Arch Linux Forums

mais comme je n'en comprends pas les finesses,
je ne sais pas comment l'adapter à ma situation (si c'est possible?)


Merci.

[PascalHambourg]

lv_usr
lv_var-cache

1) Est-il utile de séparer /usr ?
2) Je déconseille l'utilisation du tiret "-" dans les noms de LV et VG, ça fait un résultat pas très joli (double tiret) dans /dev/mapper/.
Ne pas oublier que l'initramfs a besoin que les volumes logiques soient spécifiés sous leur forme /dev/mapper/vg-lv et non /dev/vg/lv pour savoir que ce sont des volumes logiques LVM et les activer.

Comme os-prober ne l'était pas, je l'ai installé et

Pourquoi as-tu besoin d'os-prober ? Il ne sert qu'à détecter les autres OS installés.
Sur un système mono-OS, j'aurais plutôt tendance à le désinstaller ou le désactiver dans /etc/default/grub pour gagner du temps lors de l'exécution d'update-grub.

WARNING: Device /dev/sda not initialized in udev database even after waiting 10000000 microseconds

D'après le rapport de bug Debian, il pourrait être nécessaire de monter /run en bind dans la racine du chroot, comme /dev.

Note que update-grub ne fait que regénérer le fichier grub.cfg. C'est grub-install qui installe le chargeur GRUB lui-même. Contrairement à update-grub, pas besoin de chroot, il suffit de spécifier --boot-directory= (et --efi-directory dans le cas d'un amorçage EFI). Mais si l'emplacement de /boot n'a pas bougé, grub-install ne devrait pas être utile.

[dezix]

1) Est-il utile de séparer /usr ?

Ce n'est pas certain, je l'ai ajouté le temps de voir si vraiment utile.
Mais si tu as des doutes alors les miens se dissipent.

Je déconseille l'utilisation du tiret "-"

... ok, je vais corriger.

Pourquoi as-tu besoin d'os-prober ?

Comme update-grup semblait tourner en boucle,
j'ai pensé qu'il était peut-être en recherche des OS.
Donc j'ai installé pour voir ce qui en sortait,
c'est comme cela que j'ai vu le WARNING.....

update-grup n'a pas d'option --verbose mentionnée dans le manuel, ni grub-mkconfig


========= SOLUTION ===========

D'après le rapport de bug Debian, il pourrait être nécessaire de monter /run en bind dans la racine du chroot, comme /dev.

OUI ! en passant avant le chroot la commande :

# mount --bind /run /mnt/lv_racine/run

le problème est réglé.

Merci

[dezix]

Ne pas oublier que l'initramfs a besoin que les volumes logiques soient spécifiés sous leur forme /dev/mapper/vg-lv et non /dev/vg/lv pour savoir que ce sont des volumes logiques LVM et les activer.

Pourrais-tu expliquer un peu ou donner des pistes pour comprendre comment cela se fait,
afin de connaître le(s) point(s) à ne pas négliger pour éviter des problèmes de ce côté ?

Merci.

[PascalHambourg]

Il y a plusieurs façons de désigner un volume logique LVM :
- par son nom de fichier de périphérique canonique /dev/dm-N (qui peut changer à chaque démarrage, donc on oublie)
- par l'UUID ou le LABEL de son contenu, comme on le fait pour les partitions
- par son alias /dev/vg/lv
- par son alias /dev/mapper/vg-lv

Les deux alias sont des liens symboliques persistants qui pointent vers le fichier de périphérique canonique /dev/dm-N (non persistant). Tu sembles utiliser la forme /dev/vg/lv qui est celle que je préfère car elle est plus courte et plus lisible. Mais d'après ce que j'avais vu, l'initramfs, dont le rôle principal est de monter la racine, se base sur la forme /dev/mapper/vg-lv pour déterminer si la racine (et probablement le swap de l'hibernation et /usr) est un volume logique et effectuer les actions nécessaires pour l'activer. Donc si on utilise une autre forme dans /etc/fstab ou dans le paramètre root= de la ligne de commande du noyau passée par le chargeur d'amorçage, il y a un risque que le montage de la racine échoue.

[dezix]

Donc la forme /dev/mapper/vg-lv est celle à privilégier pour une fiabilité maxi.

Encore merci pour ta disponibilité.

Je te souhaite un excellent Dimanche