Daily Archives: 7. March 2014

Munin – nach Opensuse Upgrade wieder herstellen

Posted on by

Ich nutze auf einem Opensuse Server Munin – u.a. auch zur Überwachung von LDAP und MySQL. Nach einem Upgrade des Systems von Opensuse 12.3 auf Opensuse 13.1 funktionierte Munin leider nicht mehr. Im Paketmanager wurde mir angezeigt, dass es keine installierten Pakete mehr gab. Offenbar wurden die beim Upgrade deinstalliert.

Ich musste Munin nachinstallieren und zwingend als nativen “systemd”-Service aktivieren (besser: “enablen”). Im Verzeichnis “/etc/init.d” wird man unter OS 13.1 keine Munin-Startup-Datei mehr finden. Man erhält Munin für OS13.1 über das Repository
http://download.opensuse.org/repositories/server:/monitoring/openSUSE_13.1

Dann die Pakete “munin” und “munin-node” per Yast2’s Software Management installieren. Der RPM Paket-Manager legt Sicherungskopien der Konfigurationsdateien

/etc/munin/munin.conf
/etc/munin/munin-node.conf
/etc/munin/plugin-conf.d/munin-node

an. Diese kann man nutzen, um die alten Konfigurationseinstellungen in die neuen Dateien zu übernehmen.

Danach

systemctl enable munin-node.service

Und schon läuft die Sache wieder. Die alten Daten bzw. Plots unter “/srv/wwww/htdocs/munin” und dort unter dem konfigurierten Munin-Tree sind nicht verloren, sondern werden weitergeführt. Auf aktualisierte Wochenplots muss man nach der Neuinstallation natürlich aber noch etwas warten ….

KVM – Problem nach Upgrade Opensuse 12.3 auf 13.1

Posted on by

Habe vor ein paar Tagen einen KVM-Host von Opensuse 12.3 auf Opensuse 13.1 upgegradet. Wie immer habe ich gleich auch noch ein Update aller relevanten System-RPMs auf den aktuellen Stand gemäß Opensuses Standard-Repositories vorgenommen. Danach gingen KVM, virt-manager und Konsorten nicht mehr. Fehler über Fehler …. im besonderen endet der Start von virt-manager mit Fehlern. Auch der testweise Versuch, neue virtuelle Maschinen anzulegen, endet mit Fehlermeldungen. “systemd” zeigt nach dem Start des Service “libvirtd” Fehler der Art

libvirtError: unknown OS type hvm

an.

Ich habe dann die kvm-Pakete, libvirt-Pakete etc. deinstalliert und die erneute Installation über die YaST2-Module “Install Hypervisor and Tools” vornehmen lassen. Erneut ergab sich ein negatives Resultat. Offenbar testet z.Z. bei SuSE niemand die KVM-Funktionsfähigkeit unter OS 13.1!

Als nächstes habe ich dann versucht, die von YaST2 installierten Pakete über das Repository
http://download.opensuse.org/repositories/Virtualization/openSUSE_13.1/
upzudaten. Erneut ein Fehlschlag!

Bevor man nun in Verzweiflung gerät:

Nach einigem Probieren habe ich eine Variante gefunden, die aktuell funktioniert. Der Clue ist, dass man statt des Paketes “kvm” besser “qemu-kvm” installieren sollte. Dann läuft alles wieder wie geschmiert. Man kann sich dann auch mit dem aktuellen Layout von “virt-manager” anfreunden. Die Liste der von mir installierte Pakete aus dem oben genannten Repository sieht aktuell wie folgt aus:

kvm

Man beachte, wie gesagt, dass das Paket “kvm”, das Opensuse standardmäßig vorsieht, durch “qemeu-kvm” ersetzt ist.

dd und YaST – unterschiedliche Speicherplatzangaben ?

Posted on by

Manchmal will man ganze Partitionen sichern. Bei mir trat eine solche Situation auf, als ich einen produktiven KVM- und LDAP-Host von Opensuse 12.3 auf OS 13.1 upgraden wollte. Das ist bei Opensuse leider immer ein Spiel mit dem Feuer. Von anderen Systemen weiß ich bereits, dass es dabei Probleme mit Apache2 geben wird und auch mit dem LDAP-System geben kann. Ferner ist das Upgrade von KVM mehr als kritisch. (Es funktioniert nämlich nicht, wenn man die Standard SuSE-Repositories nutzt. Dazu mehr in einem anderen Beitrag.) Viele Gründe, um die alte, bestens laufende Serverinstallation in keinem Fall verlieren zu wollen.

Ein Mittel, um Partitionen relativ schnell zu sichern, ist das blockweise Klonen der ganzen Partition mit dem Befehl “dd”. Siehe z.B.
http://wiki.ubuntuusers.de/dd
http://www.techrepublic.com/blog/linux-and-open-source/drive-and-partition-backups-with-dd/
https://wiki.archlinux.org/index.php/Disk_Cloning
http://konstantin.filtschew.de/blog/2007/07/22/partitionen-mit-dd-unter-linux-sichern-und-auch-mal-per-ssh-uber-das-netzwerk/

Natürlich muss man vor dem Backup checken, dass die Zielpartition mindestens die Größe der zu sichernden Partition hat. Meine zu sichernde Partition liegt auf einem mit GPT (hybrid) formatierten Platten-System als ext4-Partition “/dev/sda4” und weist lt. YaST2’s “Partitioner” eine Größe von

120,01 GB

auf. Auf dem Plattensystem für das Backup gibt es ebenfalls eine ext4-Partition “/dev/sdb2” mit exakt der gleichen Größe.

Mit

tune2fs -l /dev/sda4″ und
tune2fs -l /dev/sdb2

kann und sollte man zudem die Blöcke und die Blocksize vergleichen. Die Partitionen sollten beim Klonen natürlich nicht gemountet sein. Auf “/dev/sda2” meiner Server liegt immer ein funktionstüchtiges Mini-Opensuse, mit dem ich jederzeit solche Wartungsaufgaben durchführen kann. nach dem Booten dieses Systems kann man dann folgenden Befehl absetzen:

dd if=/dev/sda4 of=/dev/sdb2 bs=4M

Die “bs”-Option dient der Beschleunigung des ganzen Vorgangs. Siehe hierzu die “man”-Seiten zu “dd”. Diese Option hat keine Konsequenzen für die Blockgrenzen. Nach Abschluss des Kopiervorgangs meldet “dd” dann, dass

128,86 GB

geschrieben wurden. Wieso das denn ? Wieso wurde mehr geschrieben als lt. YaST2 vorhanden?

Hier kann man schon nervös werden. Denn die Partition “/dev/sb2” auf der Zielplatte wird von mehreren anderen Partitionen gefolgt. Wurde also durch den Kopiervorgang größerer Schaden angerichtet? Ein

fsck -f /dev/sdb2
fsck -f /dev/sdb3

zeigt aber, dass alles in Ordnung ist. Woher also die unterschiedlichen Größenangaben? Als nächstes sehe ich mir die Größen der Partitionen auf “/dev/sda” mit “parted” an:

xserv:~ # parted -l /dev/sda
Model: AMCC 9650SE-4LP DISK (scsi)
Disk /dev/sda: 4000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt_sync_mbr
 
Number Start End Size File system Name Flags
…..
4 238GB 367GB 129GB ext4 primary
…..
 
Model: AMCC 9650SE-4LP DISK (scsi)
Disk /dev/sdb: 4000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt_sync_mbr
 
Number Start
End Size File system Name Flags
…..
2 138GB 267GB 129GB ext4 primary
…..

Aha, “parted” sagt was anderes als YaST ! Ok, dann nochmal Daten mit “tune2fs -l” abgefragt und nachgerechnet:

tune2fs -l /dev/sda4
tune2fs 1.42.8 (20-Jun-2013)
Filesystem volume name:
Last mounted on: /root
Filesystem UUID: 265ea396-f23a-45f2-b3a2-eea7d417db18
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 7872512
Block count: 31459328
Reserved block count: 1572966
Free blocks: 25875909
Free inodes: 7547984
First block: 0
Block size: 4096
……

Block count * Block Size = 31459328 * 4096 = 128 857 407 488

Aha, “parted” hat also recht ! Was zeigt also YaST an ? Evtl. GiB? Siehe zum Unterschied zwischen GB und GiB
http://en.wikipedia.org/wiki/Gigabyte
Zitat:

“For example, a memory capacity of 1073741824bytes is conveniently expressed as 1 GiB rather than as 1.074 GB. The former specification is, however, almost always quoted as 1 GB when applied to internal memory.”

Also mal nachgerechnet:

128857407488 / 1073741824 = 120,0078125

YaST gibt die Speichergröße von Partitionen in GiB an, “parted” und “dd” dagegen in echten GB.
Erkenntnis: Wenn man verschiedene Linux-Tools nutzt, erhält man ggf. unterschiedliche Angaben zur Größe von Speicherplatz.
Also nicht verwirren lassen ! “dd” arbeitet schon so wie erwartet !