10
XenServer bootet nicht mehr nach Hotfix Update
Hallo zusammen,
ich habe heute auf unserem Dell PE 2950, auf dem seit langer Zeit XenServer 6.2.0 lief einen Hotfix eingespielt und wollte anschließend den Server zum Übernehmen des Hotfixes rebooten. Nach dem Reboot hängt der Dell nun in der Bootsequenz mit "No bootable device" fest. Hardwareseitig habe ich alle kontrolliert. Der Server hat einen Perc5/i RAID Controller mit 1x RAID 1 und 1x RAID 5, wobei die RAID 1 Disk die Bootdisk ist und auch so geflagt ist.
Ich vermute also eher dass beim Hotfix Upgrade irgendeine Beschädigung an der Partition Table aufgetreten ist.
Wie könnte ich hier vorgehen, ohne dass ich einen Datenverlust erleide?
Danke vorab!
Gruß,
Fabian
ich habe heute auf unserem Dell PE 2950, auf dem seit langer Zeit XenServer 6.2.0 lief einen Hotfix eingespielt und wollte anschließend den Server zum Übernehmen des Hotfixes rebooten. Nach dem Reboot hängt der Dell nun in der Bootsequenz mit "No bootable device" fest. Hardwareseitig habe ich alle kontrolliert. Der Server hat einen Perc5/i RAID Controller mit 1x RAID 1 und 1x RAID 5, wobei die RAID 1 Disk die Bootdisk ist und auch so geflagt ist.
Ich vermute also eher dass beim Hotfix Upgrade irgendeine Beschädigung an der Partition Table aufgetreten ist.
Wie könnte ich hier vorgehen, ohne dass ich einen Datenverlust erleide?
Danke vorab!
Gruß,
Fabian
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 273890
Url: https://administrator.de/contentid/273890
Printed on: April 20, 2024 at 13:04 o'clock
10 Comments
Latest comment
Moin,
klingt erstmal nicht schlimm, aktuelle Backups gibt's auch? - erstmal in Sicherheit bringen...
Booten von Live-CD, z.B. SystemrescueCD, die sollte dieses Hardware-RAID als ganz normale SCSI-Laufwerke /dev/sda (RAID1) und /dev/sdb (RAID5) erkennen,
man kann die Partitionen dann mounten (erst nachgucken: fdisk -l ):
mkdir /mnt2; mount /dev/sda1 /mnt2
wenn das klappt, kann man in /mnt2 z.B. mit
less /mnt2/etc/fstab
nach den Parametern gucken, hierin könnte die Änderung sein (Partitions-ID statt fester Zuordnung /dev/sda)
andere denkbare Erklärung:
beim Patch wurde ein neuer Kernel eingespielt, der hat aber in einer kleinen Partition keinen Platz mehr gehabt, man könnte jetzt die alten entsorgen und vmlinuz-AKTUELLE-VERSION und initrd-AKTUELLE-VERSION von einem anderen System übertragen.
Falls keine Sicherung da ist: die sdb1 (z.B.) mounten und auf USB-Platte (anschließen und mounten) erstmal wegsichern.
Eher die Frage nach Zeit und Kenntnis (Linux) - muß es bis Montag wieder laufen?
HG
Mark
klingt erstmal nicht schlimm, aktuelle Backups gibt's auch? - erstmal in Sicherheit bringen...
Booten von Live-CD, z.B. SystemrescueCD, die sollte dieses Hardware-RAID als ganz normale SCSI-Laufwerke /dev/sda (RAID1) und /dev/sdb (RAID5) erkennen,
man kann die Partitionen dann mounten (erst nachgucken: fdisk -l ):
mkdir /mnt2; mount /dev/sda1 /mnt2
wenn das klappt, kann man in /mnt2 z.B. mit
less /mnt2/etc/fstab
nach den Parametern gucken, hierin könnte die Änderung sein (Partitions-ID statt fester Zuordnung /dev/sda)
andere denkbare Erklärung:
beim Patch wurde ein neuer Kernel eingespielt, der hat aber in einer kleinen Partition keinen Platz mehr gehabt, man könnte jetzt die alten entsorgen und vmlinuz-AKTUELLE-VERSION und initrd-AKTUELLE-VERSION von einem anderen System übertragen.
Falls keine Sicherung da ist: die sdb1 (z.B.) mounten und auf USB-Platte (anschließen und mounten) erstmal wegsichern.
Eher die Frage nach Zeit und Kenntnis (Linux) - muß es bis Montag wieder laufen?
HG
Mark
Hi Mark,
das ist sehr hilfreich
Ich habe die wichtigste VM bereits auf einem anderen Host zurückgesichert und um die anderen beiden wäre es zwar schade, aber nicht ganz so schlimm. Werde das morgen mit der Rescue CD mal angehen. Was mich so ärgert ist, dass das Remote Board der Dells nicht ansprechbar ist. Es holt sich zwar brav per DHCP seine Adresse aber per Browser kann ich es nicht aufrufen
Gruß,
Fabian
das ist sehr hilfreich
Ich habe die wichtigste VM bereits auf einem anderen Host zurückgesichert und um die anderen beiden wäre es zwar schade, aber nicht ganz so schlimm. Werde das morgen mit der Rescue CD mal angehen. Was mich so ärgert ist, dass das Remote Board der Dells nicht ansprechbar ist. Es holt sich zwar brav per DHCP seine Adresse aber per Browser kann ich es nicht aufrufen
Gruß,
Fabian
ich kenne mich mit Dell nur rudimentär aus, aber gab's das iDRAC nicht in Entry und Enterprise - und KVM erst bei Enterprise?
sprich: liefert es denn über die IP SNMP aus?
sprich: liefert es denn über die IP SNMP aus?
Hi,
das mit dem idrac hatte ich auch mal. Bei mir war es eine zu aktuelle Java Version auf meinem Client.
Entweder also idrac aktualisieren oder eine ältere Java drauf.
http://en.community.dell.com/techcenter/systems-management/w/wiki/3206. ...
Gruß
das mit dem idrac hatte ich auch mal. Bei mir war es eine zu aktuelle Java Version auf meinem Client.
Entweder also idrac aktualisieren oder eine ältere Java drauf.
http://en.community.dell.com/techcenter/systems-management/w/wiki/3206. ...
Gruß
Aber dann müsste ich es ja zumindest pingen können oder ? Aber das Update werde ich auf jeden Fall mal durchführen
wie jetzt?
oben hat er doch via DHCP seine IP gezogen? - oder nach Update nicht mehr?
gleich mit prüfen:
nmap IDRACIP
und
nmap IDRACIP -sU
HG
Mark
oben hat er doch via DHCP seine IP gezogen? - oder nach Update nicht mehr?
gleich mit prüfen:
nmap IDRACIP
und
nmap IDRACIP -sU
HG
Mark
Ja, IP hat er gezogen (sagt zumindest der PE während des Bootvorgangs). Nur pingen lässt sie sich nicht. Prüfe ich nachher mal ... Wollte evtl. eh noch einmal reinfahren um die Firmwareupdates einzuspielen.
So, also IDRAC läuft nach dem Upgrade wieder.
Zu den beiden Partitionen. Ich habe den Server nun mit der SysRescueCD gebootet und geparted drüber laufen lassen. Die erste Disk (RAID 1) enthält keine Partition und diese lässt sich auch nicht mehr herstellen. Die Datenpartition mit den VMDKs scheint soweit okay zu sein.
Gibt es noch eine Chance mit wenig Aufwand die VMs zu recovern oder eher nicht?
Zu den beiden Partitionen. Ich habe den Server nun mit der SysRescueCD gebootet und geparted drüber laufen lassen. Die erste Disk (RAID 1) enthält keine Partition und diese lässt sich auch nicht mehr herstellen. Die Datenpartition mit den VMDKs scheint soweit okay zu sein.
Gibt es noch eine Chance mit wenig Aufwand die VMs zu recovern oder eher nicht?
wenn von den VMs die Disks ("VMDKs") noch da sind, würde man ja diese auch einzeln wieder herstellen können, einfach an eine ansonsten leere VM hängen, so gesehen ist der Aufwand, den XEN-Server wieder einzurichten, auf Netzwerk-IPs, vielleicht Switch-Einstellungen usw. beschränkt.
Sind es Linux-VMs? (dann sind Seriennummern, MACs nicht wichtig) und/oder liegt die Definition der VMs evt. sogar auch auf dem RAID5? - sonst Default in /etc des Hosts, somit jetzt vermutlich verloren?
HG
Mark
Sind es Linux-VMs? (dann sind Seriennummern, MACs nicht wichtig) und/oder liegt die Definition der VMs evt. sogar auch auf dem RAID5? - sonst Default in /etc des Hosts, somit jetzt vermutlich verloren?
HG
Mark
Naja.. es handelt sich um Windows VMs... Im schlimmsten Fall muss ich sie neu aktivieren. Nur bin ich mal gespannt, ob ich den SR wieder einbinden kann. Auch wenn der intakt ist, kennt der XEN die LVM Volumes nicht mehr, die die Daten beinhalten .. Wir werden sehen 
