Opensuse 12.3-Upgrade – lvmetad-Warnung nach grub2-mkconfig

Ich bin ja gerade beim Upgraden diverser Seitensysteme (von Kunden wie im eigenen Netz) auf Opensuse Leap 42.2. Dabei kam mir auch ein unter KVM/qemu virtualisierter LAMP-Testserver unter Opensuse 12.3 unter die Finger. Beim Upgrade dieses KVM-Gastes waren zunächst die üblichen Hürden zu überwinden:
– Notwendige Abänderungen der Apache2-Konfiguration auf die aktuelle Syntax bzgl. des Zugangs zu Verzeichnissen (Wechsel zu Apache2-Versionen > 2.4)
– Manuelles Nacharbeiten des Upgrades der Mysql DB bzw. Maria DB zur Version 5.6 bzw. 10.0.30 mittels “mysql_upgrade -u root -p”.

Meldung zu lvmetad

Dann aber stolperte ich im Rahmen der Upgrades über eine mir bislang unbekannte Warnung im Zusammenhang mit der grub2-Konfiguration während der Upgrades:

/run/lvm/lvmetad.socket: connect failed: No such file or directory
WARNING: Failed to connect to lvmetad. Falling back to internal scanning.

Das verhinderte zwar keinen Neustart der Zwischenversionen Opensuse 13.1, 13.2 Leap 42.1; aber sauber erschien mir das dann doch nicht. Ein manueller Test unter Leap 42.2 mittels “grub2-mkconfig -o /boot/grub2/grub.cfg” ergab dieselbe Meldung.

Was ist lvmetad?

lvm2-lvmetad ist offenbar ein Caching-Service für Metadaten (“central metadata cache”), die aus physikalischen Volumes [PV] einer LVM-Volume-Group ausgelesen werden. Siehe hierzu:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Logical_Volume_Manager_Administration/metadatadaemon.html

Das Caching führt zu einer Beschleunigung der Ausführung von LVM bzw. LVM-Kommandos.

Dieser Service bzw. ein zugehöriger Socket sollten auf moderneren Opensuse-Systemen offenbar immer aktiviert sein. Ein Statuscheck auf von Scratch installierten Opensuse-Systemen der Versionen 13.1, 42.1, 42.2-Systemen ergab, dass diese Services/Sockets dort laufen – unabhängig davon, ob tatsächlich “Logical Volume Groups” und ” Logical Volumes [LV]” genutzt werden oder nicht.

Auf meinem alten 12.3-System waren die entsprechenden Services aber offenbar nicht aktiviert (“enabled”). (Oder aber der Upgrade hat da was verbockt.)

Dass ein laufender lvmetad-Dienst/Socket vorausgesetzt wird, gilt offenbar selbst dann, wenn das Opensuse-System – wie in meinem Fall – virtualisiert ist und selbst gar kein LV auf den vom Host per virtio-(blk)-Treiber durchgereichten Blockdevices nutzt (also auch kein sog. “nested” LVM für den Fall, dass das Blockdevice selbst auf einem LV des Hostes beruht).

Problemlösung: Aktivieren von lvmetad

Die Lösung war jedenfalls trivial; es half die Durchführung folgender Kommandos

systemctl enable lvm2-lvmetad.socket
systemctl enable lvm2-lvmetad.service
systemctl start lvm2-lvmetad.socket
systemctl start lvm2-lvmetad.service

auf dem von OS 12.3 auf Leap 42.2 upgegradetem System. Ein “grub2-mkconfig -o /boot/grub2/grub.cfg” lief danach ohne jede Warnung oder Fehlermeldung durch.

Fühlbare Performance-Vorteile habe ich auf dem unter KVM virtualisierten System erwartungsgemäß nicht feststellen können; das nutzt zwar ein LV einer LVM Volume Group des KVM-Hostes als Raw-Device über virtio-(blk)-Treiber. In dieser Situation ist es viel wichtiger, dass lvmetad auf dem KVM-Host selbst läuft.