Kein Booten mit RocketRaid 2720

UCS - Univention Corporate Server
#1

Hallo,

ich habe den UCS ausprobiert und war sofort sehr angetan. Ich möchte den Server als Xen Host verwenden. Soweit war das erstmal auch kein Problem.
In einer VM sollte noch ein Fileserver laufen. Deshalb habe ich einen SAS HBA Highpoint RocketRAID 2720 dazu gesteckt. Auch das war noch kein Problem. Später habe ich dann probehalber zwei Festplatten an den HBA angeschlossen. Die Systemplatte hängt weiterhin am onboard Controller. Ab diesem Punkt konnte ich das System nicht mehr booten.

Ich komme bis zum Grub-Menü. Danach kommen noch die Ausschriften, das das Initrd geladen wird. Danach ein schwarzer Bilderschirm und blinkender Cursor. Kein weiterer Text. An diesem Punkt steht das System dann.
Ein booten des normalen Kernels (ohne Xen) ist ebenfalls nicht möglich. Es endet wie oben beschrieben.

Ich habe dann den ganzen Server noch einmal neu installiert. Und zwar mit bereits am HBA angeschlossenen Platten. Die Installation lief durch. Danach war aber ebenfalls kein Booten mehr möglich.

Ein testmäßig installiertes Ubuntu 13.10 mit Xen-Hypervisor hat das Problem nicht. Es booten ganz normal.

Wo könnte hier mein Problem liegen?
Ich würde UCS sehr gerne einsetzen. U.a. auch wegen der bequemen Verwaltung der VMs über UVMM.

Viele Grüße
Schrauber

#2

Hallo und willkommen im Forum!

Wenn ich mal zusammentrage:
[ul]
[li] eine Platte am Onboard-Controller -> Installieren geht, Booten geht auch[/li]
[li] danach weitere Platte an anderen Controller hängen -> Booten geht nicht mehr[/li][/ul]

Klingt für mich so, als würden die weiteren Platten die bisherigen Plattengerätenamen (/dev/sda usw.) wegschnappen, so daß der bootende Kernel seine Rootplatte nicht mehr findet. Sollte eigentlich schon lange der Vergangenheit angehören, wenn alle Plattenkonfiguration über UUIDs passiert. Um dem Problem näher zu kommen, würde ich:
[ul]
[li] die zusätzlichen Platten wieder abmachen[/li]
[li] dann sollte Booten von der Platte am eingebauten Controller wieder gehen. als Root anmelden und aufrufen blkid das listet die UUIDs aller Partitions; diese Ausgabe aufheben, wird nachher benötigt[/li]
[li] /etc/fstab kontrollieren, ob alle Platten mit UUID=........ eingebunden sind und nicht mit /dev/sd...[/li]
[li] Wenn da Platten sind, die nicht mit UUID eingebunden sind, entsprechend korrigieren (die UUIDs muß die vorherige Ausgabe geliefert haben) und danach update-grub aufrufen, dann sollte auch die Boot-Konfiguration das wiederspiegeln.[/li]
[li] Gucken ob jetzt booten immer noch geht -> sollte funktionieren.[/li]
[li] zusätzliche Platte dranhängen und nochmal booten -> sollte gehen.[/li][/ul]

Ach so, mir fällt noch was ein. Am Boot-Prompt kann man die Taste “e” (für EDIT) drücken und anschauen was da gebootet werden soll. Die ganz lange Zeile die mit “linux” anfängt so korrigieren, daß die Wörter “quiet” und “splash” nicht mehr drin vorkommen, und dann gibt es wahrscheinlich auch einen “loglevel” Parameter, den man auf “1” setzen kann. Wenn man fertig ist mit editieren, kann man mit Ctrl-X (glaube ich, es steht aber nochmal unter dem Edit-Fenster) die geänderte Konfiguration booten, dann sollte der Bootvorgang etwas gesprächiger sein. Vielleicht sieht man dann schon, woran es hängt, ich würde mal tippen, die letzte Meldung heißt “waiting for root device”.

Viele Grüße
Frank Greif.

#3

Hallo Frank,

ja Du hast alles richtig verstanden.

Leider ist die Lösung nicht so einfach. UUID wird verwendet. Nur bei LVM nicht. Ich glaube mit einem LV als root Partition geht das auch nicht. Jedenfalls führte eine Umstellung dessen auf UUID nicht zum Erfolg. Ich habe dann noch einmal eine Installation ohne LVM gemacht. Also abweichend von den Defaults. Damit ist überall die UUID drin. Leider auch das ohne Erfolg.
Einzig ist es so, das nun der Standard-Kernel ohne Xen problemlos bootet.
Leider mit Xen immer noch nicht. Auch ein Entfernen von quiet und splash führte nicht zu mehr Text. Direkt nach dem Grub-Menü gibts einen blinkenden Cursor und das wars.

Interessanter Weise funktioniert es mit Ubuntu auch mit Xen.

Mit fehlen etwas die Ideen was ich da noch checken könnte.

Viele Grüße
Maik

#4

Hallo,

In einem anderen Thread wurde bereits empfohlen, bei Bootproblemen mit der Rootplate auf LVM ein

rootdelay=5

zur Grub-Kommandozeile hinzuzufügen, und außerdem noch

verbose loglevel=1 nosplash -quiet

damit man eventuell sieht, wo es hängt.

Außerdem wäre es interessant zu erfahren, ob es mit einem aktuellen UCS 3.2 auch dieses Problem gibt. Da ist der Kernel ja gleich viel neuer (3.10).

viele Grüße
Frank Greif.

Mastodon