Das LVM-Volume ist nach dem Neustart von CentOS inaktiv

Ich habe einen Linux-Server von CentOS 6 auf 7 neu installiert. Der Server verfügt über 3 Laufwerke - ein System-SSD-Laufwerk (es hostet alles außer /home) und zwei 4-TB-Festplattenlaufwerke, auf denen gehostet wird /home. Alles benutzt LVM. Die beiden 4-TB-Laufwerke werden gespiegelt (mithilfe der RAID-Option in LVM selbst) und sind vollständig mit der Partition / home gefüllt.

Das Problem ist, dass die 4-TB-Festplatten zwar gut erkannt werden und LVM das Volume problemlos erkennt, es jedoch nicht automatisch aktiviert. Alles andere wird automatisch aktiviert. Ich kann es manuell aktivieren und es funktioniert.

Ich habe ein Image des alten Systemlaufwerks in / home. Das enthält auch LVM-Volumes. Wenn ich es mit montiere kpartxund LVM diese aufnimmt und aktiviert. Aber ich kann keinen Unterschied zwischen diesen und den inaktiven Volumes erkennen.

Das Root-Dateisystem ist ebenfalls LVM, und das wird einwandfrei aktiviert.

Ich sehe jedoch eine Besonderheit: Beim Ausführen muss lvchange -aayich angeben, welche Laufwerke ich aktivieren möchte. Es macht es auch nicht automatisch. Wenn ich spezifiziere lvchange -ay lv_home- das funktioniert.

Ich kann nichts finden, was für dieses Verhalten verantwortlich sein könnte.

Hinzugefügt: Ich habe festgestellt, dass das alte System (das init verwendet hat) vgchange -aay --sysinitin seinen Startskripten enthalten ist. Der neue verwendet systemd, und ich sehe den vgchangeAufruf nicht in seinen Skripten. Aber ich weiß auch nicht, wo ich es hinstellen soll.

Hinzugefügt 2: Beginnen, systemd herauszufinden. Ich fand heraus, wo sich die Skripte befinden, und begann zu verstehen, wie sie aufgerufen werden. Fand auch, dass ich die ausgeführten Skripte mit sehen konnte systemctl -al. Das zeigt mir , dass nach dem Start lvmetadruft es pvscanfür jedes bekanntes udev Blockgerät. Zu diesem Zeitpunkt gibt es jedoch nur ein registriertes udev-Blockgerät, und das ist eines der erkannten lvm-Volumes. Die Festplatten sind auch da, aber unter verschiedenen Pfaden und viel längeren Namen. Das erkannte Blockgerät ist so etwas wie 8:3, während die Festplatten so sind /device/something/. Ich bin nicht mehr am Server, daher kann ich es nicht genau schreiben (wird später behoben).

Ich denke, dass es etwas mit udev und Geräteerkennung / -zuordnung zu tun hat. Ich werde abends weitermachen und dann udev lernen.

Wenn alles andere fehlschlägt, habe ich das aufrufende Skript gefunden pvscanund überprüft, ob ich es so ändern kann, dass alle Geräte ständig gescannt werden. Das behebt das Problem, aber es sieht nach einem ziemlich hässlichen Hack aus, also werde ich versuchen, die wahre Grundursache herauszufinden.

Hinzugefügt 3 : OK, ich weiß immer noch nicht, warum dies passiert, aber zumindest habe ich eine ziemlich passable Problemumgehung gemacht. Ich habe einen anderen systemd-Dienst erstellt, der den pvscaneinmaligen Aufruf direkt nach dem Start aufruft lvmetad. Der andere Anruf für das bestimmte Gerät ist immer noch da, und ich denke, es ist tatsächlich der Anruf udev(das ist der einzige Ort, an dem ich einen Hinweis darauf gefunden habe). Warum es nicht für die anderen Festplatten heißt - ich habe keine Ahnung.

Ich habe es gemacht! Ich habe es gemacht! Ich habe es richtig repariert (glaube ich).

Hier ist die Geschichte:

Nach einiger Zeit stellte sich heraus, dass der Server fehlerhaft war und verschrottet werden musste. Ich habe Festplatten behalten und alles andere neu bekommen. Dann habe ich CentOS erneut auf der SSD installiert und dann die Festplatten angeschlossen. LVM funktionierte gut, die Festplatten wurden erkannt, die Konfiguration beibehalten. Aber das gleiche Problem kam wieder - nach einem Neustart, das Volumen war inaktiv.

Diesmal bemerkte ich jedoch möglicherweise etwas anderes - der Bootloader übergibt die folgenden Parameter an den Kernel:

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

Hmm, Moment mal, die sehen FAMILIAR aus !

Schnelle Google-Abfrage, und da sind wir :

rd.lvm.lv =

Aktivieren Sie nur die logischen Volumes mit dem angegebenen Namen. rd.lvm.lv kann in der Kernel-Befehlszeile mehrmals angegeben werden.

Na dann. Das erklärt es!

Die Auflösung lautete also (aus mehreren weiteren Google-Abfragen):

1. Ändern Sie /etc/defaults/grub, um das zusätzliche Volume in die Parameter aufzunehmen:crashkernel=auto rd.lvm.lv=centos/root rd.lvm.lv=centos/swaprd.lvm.lv=vg_home/lv_homerhgb quiet
2. Grub mit neu konfigurieren grub2-mkconfig -o /boot/grub2/grub.cfg
3. Konfigurieren Sie initramfs mit neu mkinitrd -f -v /boot/initramfs-3.10.0-327.18.2.el7.x86_64.img 3.10.0-327.18.2.el7.x86_64. Hinweis: Ihre Werte können variieren. Verwenden uname -rSie diese Option, um diese Kernelversion abzurufen. Oder lesen Sie einfach weiter mkinitrd. (Ehrlich gesagt, ich weiß nicht, warum dieser Schritt benötigt wird, aber anscheinend ist es das - ich habe es ohne versucht und es hat nicht funktioniert)
4. Und zum Schluss installieren Sie grub neu: grub2-install /dev/sda
5. Natürlich neu starten.

TA-DA! Das Volume ist beim Neustart aktiv. Fügen Sie es hinzu fstabund genießen Sie! :) :)

Kleinere Aktualisierung (für RHEL 7 auf EFI - Computern (ohne BIOS) ):

Ich habe Erfolg mit diesen Schritten:

1. Ändern Sie /etc/defaults/grub, um das zusätzliche Volume in die Parameter aufzunehmen: rd.lvm.lv=rhel/home(zusätzlich zu rhel/rootund rhel/swap)

2. Grub mit neu konfigurieren

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

   ( Anmerkung: ein anderer Weg!)

3. Konfigurieren Sie initramfs mit neu

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

4. Neuinstallation von Grub überspringen : grub2-install /dev/sda(weil ich ein leeres Verzeichnis habe /usr/lib/grub/)
5. Natürlich neu starten.

Ich hatte auch dieses Problem. In meinem Fall war es eine Kombination aus iscsi, multipath und lvm und der Reihenfolge der Sitzungserstellung usw. Ich habe das Problem gelöst, indem ich einen Aufruf an hinzugefügt /sbin/vgchange -a yhabe /etc/rc.local.

Also habe ich die Einstellung rd.lvm.lv = in / etc / default / grub ausprobiert und das hat nicht funktioniert

Ich brauchte beide logischen Volumes in der Volume-Gruppe ssd_vg, um beim Booten aktiv zu sein. Sowie das logische Volume home_lv auf dem kubuntu-vg aktiv sein

Was funktionierte, war die Bearbeitung von /etc/lvm/lvm.conf. Im Abschnitt "Volume-Liste" geben Sie dies in volume_list = ["ssd_vg", "kubuntu-vg / home_lv"] ein.

Ergebnis nach dem Neustart

$ sudo lvscan inaktiv Original '/ dev / kubuntu-vg / root' [50.00 GiB] erben

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

Ich für meinen Teil habe diese Zeile in /etc/lvm/lvm.conf kommentiert

auto_activation_volume_list = [ "vg00", "vg01" ]

Denn wenn es aktiv ist, sind beim Booten nur die Volumes vg00 und vg01 aktiv.

Die Dokumentation von 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" ]