Nach manueller Installation von 2.6.32 - vg_ucs not found

Guten Tag,

Wir wollten ein relativ altes Systemupdate (von UCS 2.2 nach 3.0) einspielen in Vorberitung der Migration der OXASE nach OXSE for UCS.
Dabei erscheint aber leider folgende Meldung:

[code]WARNING: This system uses kernel 2.6.18. With UCS 3.0
only kernel 2.6.32 is supported. To prevent update conflicts you
should upgrade to 2.6.32 before the update.

This check can be disabled by setting the Univention Configuration
Registry variable “update/kernel/check” to “no”.
Error: Update aborted by pre-update script of release 3.0-0
exitcode of univention-updater: 1
ERROR: update failed. Please check /var/log/univention/updater.log[/code]

Wir haben also zunächst versucht den kernel 2.6.32 mittels apt-get zu installieren.
Das hat soweit auch geklappt.
Beim reboot mit dem neuen Kernel aber bleibt das System mit der Fehlermeldung:

mounting root file system ... Beginning Running /scripts/local-top ... Volume group "vg_ucs" not found

stehen.

Wir haben bereits in der /etc/fstab die UUIDs eingetragen, doch auch das hat nicht geholfen.
Der alte Kernel 2.6.18 bootet weiterhin sauber, nur können wir dann eben nicht updaten.

Fehlt noch irgendeine Unterstützung für LVM im manuell installierten 2.6.32?

Danke für die Hilfe
Sascha Zucca

Hallo,

was mich hier zuerst wundert, ist die Meldung an sich.
Wenn man den normalen Upgradepfad mit allen Zwischenschritten geht, sollten nach meiner Erfahrung alle Kernelupdates und damit verbundenen Systemänderungen automatisch eingespielt werden.
“apt-get” ist auf UCS nicht immer erste Wahl, dafür wurden “univention-install” und “univention-upgrade” eingeführt-

Viele Grüße,
Dirk Ahrnke

Hallo,

ja ich finde das auch seltsam, aber so ist es jetzt nun mal…
Ich habe das Update so nicht gefahren, sondern die Sachlage war schon so, als ich dazu kam.
Vielleicht sollten wir den neuen Kernel mal komplett wieder entfernen und dann mit univention-install neu installieren?
Wäre das evtl. einen Versuch wert?

Und wie würde man das dann am besten angehen?

Danke für die Hilfe
Sascha Zucca

Hallo,

man würde das vielleicht auch mit diesem Kernel hingebastelt bekommen, aber wie angedeutet, ist der unterstützte Upgradepfad über die UCS-Methoden.
“univention-install” gibts erst ab 2.4.
Die Updates bei UCS 2 waren, wenn ich mich recht erinnere, mit “univention-updater” entweder über die Update-ISOs von http://apt.univention.de/download/ucs-cds/ oder übers Netz zu erledigen. Wenn der letztere Weg nicht geht, müssten Sie bitte noch mal beim Univention-Support anfragen, ob Sie die fehlenden Update ISOs bis Version 2.4 bekommen können.

Viele Grüße,
Dirk Ahrnke

Noch ein paar Ergänzungen:
Die zuerst zitierte Meldung vom Pre-Update zeigt, dass auf 3.0 aktualisert werden sollte. An dieser Stelle sollte vom besagten Skript bereits geprüft worden sein, welche Vorgängerversion läuft. Das müsste somit schon 2.4 sein.

Anstelle des reinen Kernel-Paketes muß bei UCS das passende Meta-Paket installiert werden. Falls Sie das nicht genommen haben, sollten Sie zunächst das Kernel-Paket entfernen und dann “univention-kernel-image-2.6.32” installieren.

Viele Grüße,
Dirk Ahrnke

Hallo!
Erstmal vielen Dank für Ihre freundliche Hilfe.
Leider hat das das Problem so nicht lösen können…
Auch nach univention-install univention-kernel-image-2.6.32 ist der Kernel nicht bootfähig.
Vielleicht sollten wir uns auch nicht zu sehr auf dem neueren Kernel austoben.
Eventuell läuft alles besser durch, wenn wir manuell das Update auf 3.0 antriggern?
Vielleicht auch direkt in der konsole mit univention-updater?

Danke
Sascha Zucca

Update:
ein einfaches univention-upgrade aus der Konsole führt zum selben Fehler…
Sollen wir die Registry variable “update/kernel/check” auf “no” setzen?
Würde dann nicht auch der Kernel aktualisiert?

Ich bin etwas ratlos jetzt…
Gruß
Sascha Zucca

Keine Ideen mehr?
Wir kommen hier nicht wirklich weiter…

Würde mich freuen

Danke
Sascha

Hallo Sascha,

hast du mal versucht, direkt das Paket “linux-image-2.6.32” zu installieren, also ohne das von Drik genannte Meta Paket?

Viele Grüße

ja hab ich.
Leider mit dem gleichen Resultat.
irgendwie wird danach die vg nicht gefunden beim Reboot.

Hi,

es könnte sein das Grub die Module für LVM nicht schnell genug laden kann und daher die vg nicht findet.

Ein vgchange -ay sollte dazu führen, dass du wieder eine Login Möglichkeit bekommen solltest. Die Volumes sollte dann auch wieder unter /dev/mapper zu finden sein. Wenn dem so ist, müsstest du deine grub.cfg bearbeiten und dort eine Zeile anpassen oder einfügen:

GRUB_CMDLINE_LINUX="rootdelay=n" Hierbei steht das “n” für Sekunden. Irgendwas zwischen 1-5 sollte passen. Dann noch ein update-grub und der Kernel sollte normal booten.

Viele Grüße

Hallo,

Nach reboot im neuen Kernel und einem vgchange -ay ist leider unter /dev/mapper nichts dazu gekommen.
Eine grub.cfg gibt es (noch) nicht. Das hat also erstmal nicht geholfen.

Hier noch ein wenig mehr Information:

Version 3.0.113-1.528.201109281807
Build 28.09.2011(golden beech)
Lokale Installation UCS Version 2.4-4-9

Versionsinformationen
Die aktuell installierte UCS-Releaseversion ist 2.4-4 sec9.
Die Verbindung zum Repository-Server ist fehlgeschlagen. Bitte überprüfen Sie die Repository-Konfiguration und die Netzwerkverbindung.

Sehr seltsam…
Danke Euch im Voraus
Sascha

Hallo,

generell ist uns dieses Verhalten nicht bekannt und daher vermutlich ein umgebungsspezifisches Problem.

[quote=“tafkaz”]Sollen wir die Registry variable “update/kernel/check” auf “no” setzen?[/quote]Das würde ich nicht so ohne weiteres machen, der darauf folgende Zustand wäre undefiniert und damit nicht viel anders als der jetzige.

Um das Setup beurteilen zu können, helfen evtl. die Ausgaben der folgenden Befehle:univention-baseconfig dump | grep grub cat /proc/partitions cat /etc/fstab pvdisplay vgdisplay lvdisplay grub-mkdevicemap -m - cat /boot/grub/device.map dpkg -l "*grub*" | grep ^ii dpkg -C

Diese Ausgaben des laufenden Systems (Kernel 2.6.18) könnten Sie dann mit denen vergleichen die Sie beim booten des Kernel 2.6.32 erhalten (ggf. rootdelay wie von vector beschrieben).

Mit freundlichen Grüßen
Janis Meybohm

Hallo,

Ich glaube die grub.cfg gobt es erst in grub2 oder?
Das scheint hier aber noch gar nicht drauf zu sein.
Kann ich denn
GRUB_CMDLINE_LINUX=“rootdelay=n”
dann woanders einpflegen?

Danke
Sascha Zucca

Hallo,

Ändern der Grub-Argumente geht immer. Zuerst ein temporärer Weg, der in jedem Grub geht: beim Booten wenn das Grub Menu erscheint die Taste ‘e’ (für “edit”) drücken, Kommandozeile editieren und ich glaube Ctrl-X für sofortiges Booten drücken. Hat auch den Vorteil, wenn man sich vertan hat, beim nächsten Boot sind die Änderungen vergessen.

Ansonsten wenn es keine grub.cfg gibt, ist es die /boot/grub/menu.lst, die man editieren muß. Es geht um die Zeile ‘kopt’:

## DO NOT UNCOMMENT THEM, Just edit them to your needs

## ## Start Default Options ##
## default kernel options
## default kernel options for automagic boot options
## If you want special options for specific kernels use kopt_x_y_z
## where x.y.z is kernel version. Minor versions can be omitted.
## e.g. kopt=root=/dev/hda1 ro
##      kopt_2_6_8=root=/dev/hdc1 ro
##      kopt_2_6_8_2_686=root=/dev/hdc2 ro
# kopt=root=/dev/cciss/c0d0p1 ro

und danach muß man noch

update-grub

aufrufen.

viele Grüße
Frank Greif

Hallo zusammen!

Wir konnten durch das rootdelay jetzt tatsächlich den neuen Kernel booten.
Jetzt laufen die Univention Updates erstmal durch… Weitere kleinere Probleme versuchen wir erstmal wieder alleine zu lösen :wink:

Danke für den großartigen support hier im Forum!

lg
Sascha

Mastodon