Le volume LVM est inactif après le redémarrage de CentOS

J'ai réinstallé un serveur Linux de CentOS 6 à 7. Le serveur a 3 disques - un disque SSD système (il héberge tout sauf /home) et deux disques durs 4 To qui hébergent /home. Tout utilise LVM. Les deux disques de 4 To sont mis en miroir (en utilisant l'option raid dans LVM lui-même), et ils sont complètement remplis avec la partition / home.

Le problème est que bien que les disques de 4 To soient reconnus correctement et que LVM voit le volume sans problème, il ne l’active pas automatiquement. Tout le reste est activé automatiquement. Je peux l'activer manuellement et cela fonctionne.

J'ai une image de l'ancien lecteur système dans / home. Cela contient aussi des volumes LVM. Si je le monte avec kpartx, et LVM les prend et les active. Mais je ne vois aucune différence entre ces volumes et les volumes inactifs.

Le système de fichiers racine est également LVM, et cela s'active très bien.

Je vois cependant une chose particulière: l'exécution lvchange -aayme dit que je dois spécifier quels disques je veux activer. Il ne le fait pas automatiquement non plus. Si je précise lvchange -ay lv_home- cela fonctionne.

Je ne trouve rien qui pourrait être responsable de ce comportement.

Ajouté: j'ai remarqué que l'ancien système (qui utilisait init) avait vgchange -aay --sysinitdans ses scripts de démarrage. Le nouveau utilise systemd, et je ne vois pas l' vgchangeappel dans ses scripts. Mais je ne sais pas non plus où le mettre.

Ajouté 2: Commencer à comprendre systemd. J'ai trouvé où se trouvent les scripts et j'ai commencé à comprendre comment ils étaient appelés. J'ai également constaté que je pouvais voir les scripts exécutés avec systemctl -al. Cela me montre qu'après le démarrage, lvmetadil appelle pvscanchaque périphérique de bloc udev connu. Cependant, à ce stade, il n'y a qu'un seul périphérique de bloc udev enregistré, et c'est l'un des volumes lvm reconnus. Les disques durs sont là aussi, mais sous des chemins différents et des noms beaucoup plus longs. Le périphérique de bloc reconnu est quelque chose comme 8:3, tandis que les disques durs sont comme /device/something/. Je ne suis plus sur le serveur, je ne peux donc pas l'écrire avec précision (corrigera cela plus tard).

Je pense que cela a quelque chose à voir avec udev et la détection / cartographie des périphériques. Je continuerai le soir et étudierai alors udev.

Si tout le reste échoue, j'ai trouvé le script qui appelle pvscanet vérifié que je peux le modifier pour analyser tous les appareils tout le temps. Cela résout le problème, mais cela ressemble à un hack plutôt laid, donc j'essaierai de comprendre la véritable cause profonde.

Ajouté 3 : OK, je ne sais toujours pas pourquoi cela se produit, mais au moins j'ai fait une solution de contournement assez passable. J'ai fait un autre service systemd qui appelle pvscanune fois, juste après le démarrage lvmetad. L'autre appel pour le périphérique spécifique est toujours là, et je pense que c'est en fait udevcela qui l'appelle (c'est le seul endroit où j'ai trouvé une référence). Pourquoi il ne l'appelle pas pour les autres disques durs - je n'en ai aucune idée.

Je l'ai fait! Je l'ai fait! Je l'ai réparé correctement (je pense).

Voici l'histoire:

Après un certain temps, le serveur s'est révélé défectueux et a dû être mis au rebut. J'ai gardé des disques et obtenu tout le reste nouveau. Ensuite, j'ai réinstallé CentOS à nouveau sur le SSD, puis j'ai attaché les disques durs. LVM a bien fonctionné, les disques ont été reconnus, la configuration a été conservée. Mais le même problème est revenu - après un redémarrage, le volume était inactif.

Cependant, cette fois, j'ai remarqué autre chose - le chargeur de démarrage transmet les paramètres suivants au noyau:

crashkernel = auto rd.lvm.lv = centos / root rd.lvm.lv = centos / swap rhgb quiet

Hmm, attendez une minute, ceux qui ont l'air FAMILIER !

Requête Google rapide, et nous y sommes :

rd.lvm.lv =

activez uniquement les volumes logiques avec le nom donné. rd.lvm.lv peut être spécifié plusieurs fois sur la ligne de commande du noyau.

Bien maintenant. Ceci explique cela!

Ainsi, la résolution était (recueillie à partir de plusieurs autres requêtes Google):

1. Modifiez /etc/defaults/grubpour inclure le volume supplémentaire dans les paramètres:crashkernel=auto rd.lvm.lv=centos/root rd.lvm.lv=centos/swaprd.lvm.lv=vg_home/lv_homerhgb quiet
2. Reconfigurez grub avec grub2-mkconfig -o /boot/grub2/grub.cfg
3. Reconfigurez initramfs avec mkinitrd -f -v /boot/initramfs-3.10.0-327.18.2.el7.x86_64.img 3.10.0-327.18.2.el7.x86_64. Remarque: vos valeurs peuvent varier. Utilisez uname -rpour obtenir cette version du noyau. Ou lisez simplement mkinitrd. (Franchement, je ne sais pas pourquoi cette étape est nécessaire, mais apparemment c'est le cas - j'ai essayé sans et cela n'a pas fonctionné)
4. Et enfin, réinstallez grub: grub2-install /dev/sda
5. Redémarrez, naturellement.

TA-DA! Le volume est actif au redémarrage. Ajoutez-le fstabet profitez-en! :)

Mise à jour mineure (pour RHEL 7 sur une machine EFI (non BIOS) ):

J'ai du succès en utilisant ces étapes:

1. Modifiez /etc/defaults/grubpour inclure le volume supplémentaire dans les paramètres: rd.lvm.lv=rhel/home(en plus de rhel/rootet rhel/swap)

2. Reconfigurez grub avec

   grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
   

   ( note: un autre chemin!)

3. Reconfigurez initramfs avec

   mkinitrd -f -v /boot/initramfs-$(uname -r).img $(uname -r)
   

4. Ignorer la réinstallation de grub: grub2-install /dev/sda(car j'ai un répertoire vide /usr/lib/grub/)
5. Redémarrez, naturellement.

J'ai aussi eu ce problème. Dans mon cas, c'était une combinaison de iscsi, multipath et lvm et de l'ordre de création de session, etc. J'ai résolu le problème en ajoutant un appel /sbin/vgchange -a yà /etc/rc.local.

J'ai donc essayé le paramètre rd.lvm.lv = dans / etc / default / grub et cela n'a pas fonctionné

J'avais besoin que les deux volumes logiques du groupe de volumes ssd_vg soient actifs au démarrage. Ainsi que le volume logique home_lv sur le kubuntu-vg pour être actif

Ce qui a fonctionné, c'était d'éditer /etc/lvm/lvm.conf Dans la section de la liste des volumes, mettez ceci dans volume_list = ["ssd_vg", "kubuntu-vg / home_lv"]

résultat après le redémarrage

$ sudo lvscan inactif Original '/ dev / kubuntu-vg / root' [50.00 Gio] hérite

inactive          '/dev/kubuntu-vg/swap_1' [7.88 GiB] inherit

ACTIVE            '/dev/kubuntu-vg/home_lv' [1000.00 GiB] inherit

inactive Snapshot '/dev/kubuntu-vg/root_snap11' [50.00 GiB] inherit

inactive Snapshot '/dev/kubuntu-vg/root_snap12' [50.00 GiB] inherit

ACTIVE            '/dev/ssd_vg/root' [224.02 GiB] inherit

ACTIVE            '/dev/ssd_vg/swap_1' [7.88 GiB] inherit

Pour ma part, j'ai commenté cette ligne dans /etc/lvm/lvm.conf

auto_activation_volume_list = [ "vg00", "vg01" ]

Parce que s'il est actif, seuls les volumes vg00 et vg01 sont actifs au démarrage.

La documentation de lvm.conf:

If auto_activation_volume_list is defined, each LV that is to be
activated with the autoactivation option (--activate ay/-a ay) is
first checked against the list. There are two scenarios in which
the autoactivation option is used:

  - automatic activation of volumes based on incoming PVs. If all the
    PVs making up a VG are present in the system, the autoactivation
    is triggered. This requires lvmetad (global/use_lvmetad=1) and udev
    to be running. In this case, "pvscan --cache -aay" is called
    automatically without any user intervention while processing
    udev events. Please, make sure you define auto_activation_volume_list
    properly so only the volumes you want and expect are autoactivated.

  - direct activation on command line with the autoactivation option.
    In this case, the user calls "vgchange --activate ay/-a ay" or
    "lvchange --activate ay/-a ay" directly.

By default, the auto_activation_volume_list is not defined and all
volumes will be activated either automatically or by using --activate ay/-a ay.

N.B. The "activation/volume_list" is still honoured in all cases so even
if the VG/LV passes the auto_activation_volume_list, it still needs to
pass the volume_list for it to be activated in the end.

If auto_activation_volume_list is defined but empty, no volumes will be
activated automatically and --activate ay/-a ay will do nothing.

auto_activation_volume_list = []

If auto_activation_volume_list is defined and it's not empty, only matching
volumes will be activated either automatically or by using --activate ay/-a ay.

  "vgname" and "vgname/lvname" are matched exactly.
  "@tag" matches any tag set in the LV or VG.
  "@*" matches if any tag defined on the host is also set in the LV or VG


Only activate vg00 and vg01 automatically.
auto_activation_volume_list = [ "vg00", "vg01" ]