OVH Community, your new community space.

Bootmechanismus RPS


pinky
18.06.08, 21:28
Ich habe das Ganze inzwischen noch mal untersucht und meine Vermutung hat sich bestätigt. Es wird über PXE ein Etherboot/gPXE Modul geladen, was wiederum per DHCP als Rootpath das iSCSI-Target mitgeteilt bekommt und dann über eine Int13h Plattenemulation das lokale System bootet. Da sollte sich dann auch ein FreeBSD booten lassen. Das klappte bei mir zwar im vKVM Modus, aber das ist das auch keine Kunst, da das ja wohl nur ein Qemu ist. Im hd Modus hatte ich noch keinen Erfolg. Da man keinerlei Fehlermeldungen sehen kann, ist da wohl auch schwerlich weiterzukommen. Als mögliche Probleme sehe ich im Moment
  • boot2 und/oder loader kommt mit der Zuordnung des Bootlaufwerks nicht klar (kann man zwar fest verdrahten, man muß aber wissen, was zugeordnet ist)
  • Probleme mit Zusammenspiel BTX (protected mode/real mode Umschaltungen und Speicherbereiche) und Etherboot modul
  • Netzwerkkartentreiber


Ich denke ohne Sicht auf die Fehlermeldungen beim Booten kommt man hier schwer weiter und wir werden auf die angekündigte offzielle Unterstützung von FreeBSD warten müssen. Oder es fällt einem noch was anderes ein, booten via Grub ohne loader wäre auch noch einen Versuch wert...

pinky
30.05.08, 13:54
Zitat Zitat von u338457
Das kann bei einem RPS aber nur funktionieren, wenn der
NAS sich dem BIOS als Bootdisk präsentiert. Bei einem
PXE-Boot müsste man eine andere Strategie wählen...
Eine Alternative wäre, daß per PXE-Boot ein iSCSI-Initiator geladen wird, der dann eine int13h Emulation macht und darüber den Bootsektor lädt. Der kann dann int13h zum Nachladen des Betriebsystems (ggf. vorher Lader) nutzen. Das dürfte dann dateisystem- und betriebssystemunabhängig sein und sollte auch mit einem BSD funktionieren.

u338457
09.04.08, 12:29
Zitat Zitat von sledge0303
Der RPS hat eine NIC für den Connect mit SAN und der Außenwelt und 2 IP Adressen (FoIP mit 87.98... wird als eth0:0 bzw dummy0 bei Gentoo) und einer IP 91.121.... (eth0) konfiguriert.
Die virtuellen IPs auf dem Ethernet Interface kenne ich von BSD. Dort
baue ich mir damit immer virtuelle Server in Jails (eine Art VM-Light).

Zitat Zitat von sledge0303
Wie das BIOS mit den Bootoptionen aussieht, kannst dir Anhand der bisherigen Informationen selbst ausmalen
Leider nicht ganz. Nach meiner Rechereche gibt es anscheinden
durchaus BIOSe, die als iSCSI Initiator arbeiten und damit von
iSCSI LUNs booten können.

Daneben wäre es vorstellbar, dass OVH bei jedem PXE-Boot Request
versucht, die Kunden SAN-LUN zu mounten um dort die
angeforderten Dateien zu lesen und zur Verfügung zu stellen. Damit
gäbe es aber Einschränkungen bezüglich des genutzten Filesystems.
Mit UFS2 geht dann vermutlich nichts.

Welche der Optionen genutzt wird, kann man leider nur indirekt
festestellen. Möchte mal jemand versuchen, den MBR zu sichern
(dd if=/dev/sda of=mbr.img bs=512 count=1) und danach den
GRUB Code (Adresse 0 - 0x01b7) mit Nullen füllen (mbr.img
vorher(!) wegsichern!!!) und wieder auf die Platte schreiben
(dd if=mbr.img of=/dev/sda)?

Wenn der Server danach _nicht_ mehr started, könnte es sein,
dass wirklich ein iSCSI BIOS arbeitet. Ansonsten würde ich auf
PXE-Boot tippen. Einfacher wäre es, wenn jemand eine die Info
von OVH bekommen kann. Mail war bisher erfolglos.

ACHTUNG: Bitte nicht versuchen, wenn der Server wichtige Daten
hält oder sonst irgendwie wichtig ist. Wenn man da einen Fehler
macht braucht man evtl. eine komplette Neuinstallation des Systems.

sledge0303
09.04.08, 11:39
Ahja, verstehe. Soweit hab ich mich (noch!) nicht auseinandergesetzt. Hab bezüglich der 'initrd-iscsi' ein paar Informationen rausgefunden, wie weit diese relevant sind, bzw sein werden, bei einer Image/from scratch Installation, muss man sehen.
Wie schon oben beschrieben, habe ich Gentoo und Debian im Rescuemodus installiert. Bei Gentoo hab ich auch ein eigenes Image, dieses auf der gemounteten 'HDD' entpackt, Netzwerk angepasst, Kernel + Bootloader installiert und anschließend sofort rebootet.
Was zu beachten wäre:

rootdevice ist nicht /dev/sda1 sondern /dev/ram0
Die momentane /initrd kannst lokal auf deine HDD oder auf einen anderen Server kopieren und nutzen, da besteht keine Notwendigkeit eine eigene zu bauen.
Der RPS hat eine NIC für den Connect mit SAN und der Außenwelt und 2 IP Adressen (FoIP mit 87.98... wird als eth0:0 bzw dummy0 bei Gentoo) und einer IP 91.121.... (eth0) konfiguriert.
Wie das BIOS mit den Bootoptionen aussieht, kannst dir Anhand der bisherigen Informationen selbst ausmalen
Was BSD angeht, hab ich es noch nie installiert - geschweige von 'genutzt'. Es sollte aber alles in angepasster Form so funktionieren wie mit den beiden genannten *UNIX Derivaten Gentoo und Debian.

Gruß Thomas

u338457
08.04.08, 20:08
Ich habe BSD bisher auf nicht untertsützten Systemen ohne
Konsole installiert, indem ich eine installation in einer VM gemacht
habe, diese dann an den Server angepasst habe, per Rescue-System
und ssh/dd direkt auf die Platte gepackt und dann neu gestartet.

Das kann bei einem RPS aber nur funktionieren, wenn der
NAS sich dem BIOS als Bootdisk präsentiert. Bei einem
PXE-Boot müsste man eine andere Strategie wählen...

u338457
08.04.08, 19:47
Wieso sollte es mit FreeBSD anders sein?
Naja, idealerweise habe ich meine Bootpartition auf einem
UFS2 Filesystem. Wenn das RPS BIOS direkt vom NAS
bootet, wie von einer lokalen Platte, ist das kein Problem.
Sollte aber ein Netzwerkboot gemacht werden, hängt alles
am Bootserver von OVH.

Bei einem FiberNAS hat man üblicherweise eine Karte, die
sich dem System als SCSI-Kontroller präsentiert. Da ist
das ganze dann transparent für das System. Der RPS
sieht mir aber eher so aus, als ob 1 Netzwerkkarte im
System steckt und diese für iSCSI und IP genutzt wird.
Lädt das BIOS den MBR->Bootloader->Kernel vom NAS
sollte es kein Problem sein. Dazu bräuchte der RPS aber
ein spezielles Boot-BIOS, welches im laufenden Betrieb
durch einen Betriebssystemtreiber ersetzt wird. Das
wäre schon recht speziell. Oder der Server bootet per
Netzwerkboot, was Standard ist, aber ein paar Fragen
aufwirft. Zum Beispiel warum man dann ein
Code:
grub-install /dev/sda
benötigt?

sledge0303
08.04.08, 19:18
Hallo,

ich habe erfolgreich Gentoo Hardened und Debian Etch 'from scratch' erfolgreich installieren können. Wieso sollte es mit FreeBSD anders sein?
Momentan wird es (noch) nicht unterstützt mit einem eigenen Image, aber Windows soll demnächst auch für den RPS angeboten werden - falls diese Intension sich zwischenzeitlich nicht geändert haben sollte.

Um die Funktion der initrd zu erklären, es würde den Zeitrahmen vollkommen sprengen, deswegen such dir mal im Netz die Dokumentation über 'open-iscsi' und 'initrd-iscsi' zusammen. Dann wird dir einiges klarer werden.

HTH und wenn es mit FreeBSD versuchts --> Viel Erfolg und ein schönes Tutorial darüber

u338457
08.04.08, 19:06
Hallo!

Mich würde interessieren, wie der RPS zu seinem Kernel mit initrd
kommt? Wie ich den Informationsfetzen bisher entnehmen konnte,
ist es kein SCSI Chipset mit Ethernet Backend, wie in einem richtigen
NAS. Es Hört sich eher so an, als ob die normale Ethernetkarte mit
einem iSCSI Treiber mitgenutzt wird. Nur frage ich mich, wie die
Maschine dann zu ihrem Kernel kommt. Spricht das BIOS iSCSI,
oder hat OVH einen Server, der die erste NAS-LUN Partition
mounted? Gibt es dann Einschränkungen für das Filesystem
auf sda1 (ext2)? Oder funktioniert die Sache ganz anders?

Hintergrund meiner Frage ist, dass ich gerne FreeBSD auf so einem
Server installieren würde. Das es ein gebastel wird ist klar - die Frage
ist, ob es aussichtslos ist?!