Revert to Snapshot ist nicht mehr möglich :(

[TheProdigy]

Hallo,

ich habe eine VM, bei der ich einen abgespeicherten Snapshot wiederherstellen muss (muss, weil die VM nicht mehr bootbar ist - aber das ist ein anderes Problem, siehe PS). Diese VM hat zwei Platten: Bootplatte und Zusatzplatte.

Der Snapshot kann jetzt nicht mehr wiederhergestellt werden, weil ich eine andere VM gebootet habe, die ebenfalls auf diese Zusatzplatte zugreift - es kommt die Meldung "... virtual disk has been modified ...".

Kann ich da noch etwas tricksen?

danke und lg,
Gerald




PS: alterantiv könnte man auch folgendes Problem lösen *g*

ich habe meine Entwicklungsumgebung zur Wartung einer alten 16-Bit-Software in einer virtuellen Maschine (VMware) laufen. Das OS ist Windows NT 4.0.

Ich habe schon seit laengerem das Problem, dass diese Installation beim Neustarten immer ein "invalid system disk" bringt. Bis jetzt war das Dank Snapshots und Suspend/Resume kein Problem, aber jetzt muss ich einen Neu-start machen.

Was kann ich tun? ein FDISK /MBR oder aehnliches gibt es leider nicht.

Ich habe bereits eine Reparatur von den Startdisketten versucht (dabei wurden Dateien von der original-CD rueckgesichert).
Das Syste bootet zwar, aber beim Login-Screen erscheint eine Dialogbox "... browser.dll... not found in path ...", die zwar einen OK-Button anbietet, aber nicht mehr wegklickbar ist.
Fazit: ich kann mich nicht einloggen.

Gibt es noch andere Moeglichkeiten, die ich probieren koennte?

Eine Neuinstallation moechte ich vermeiden, da ich dann einen guten Tagvbeschaeftigt bin, um die ganze IDE, Datenbank, Tools etc. aufzusetzen.

[AgentSmith]

kleiner Tip - poste für jedes Problem einen eignen thread!

zu Problem 1:

Wann genau kommt die Meldung? Bei REVERT?

Probiere einfach die RedoLogs der virt. Platten mit Hand zu löschen.
ACHTUNG!!! Alle Änderungen seit dem letzten Sanpshot gehen dabei verloren!

Redologs sehen z.B. so aus:
debian_sys.vmdk.REDO_a00840

Lösche nichts, was NICHT das Wort "REDO" enthält!

Du kannst auch nur die Redos für die betroffene Platte löschen, alle anderen Platten bleiben erhalten!


Sven Ahnert

www.vmaschinen.de

[TheProdigy]

Danke für die Hinweise ... ich war schon soweit, dass er mir beim Booten mit "NTOSKRNL.EXE fehlt oder beschädigt" hängengeblieben ist, aber ich werde dennoch ein neues (sauberes) System aufsetzen ... ist im Endeffekt sinnvoller

[continuum]

Hi
du haettest noch was retten koennen - aber jetzt ist es wahrscheinlich zu spaet.

Code: Alles auswählen

Was kann ich tun? ein FDISK /MBR oder aehnliches gibt es leider nicht.

Wieso gibt es das nicht? Hast du keine 98er Startdisk? Ich haette den MBR neugeschrieben und dann einen NT4 Bootsektor dahin gepatcht.

Code: Alles auswählen

Browser.dll not found in  path

Kannst du nicht einfach die Datei dahin kopieren oder den Pfad erweitern?

@Agentsmith - dein Tip einfach die REDO-logs zu loeschen ist als allerletzte Moeglichkeit vielleicht brauchbar. In diesem Fall aber etwas verfrueht oder?

Ulli

[TheProdigy]

Hallo Ulli,

die VM existiert noch, jedoch nur ein Backup mit einem etwas älteren Stand. Das ist eigentlich nicht das Problem, da ich ja auf die Platte der jetzt komplett kaputten VM zugreifen und somit die Daten sichern kann.

Das Backup ist jedoch vom selben Problem betroffen - ich darf die VM nicht rebooten (das Problem besteht schon seit ca. einem halben Jahr, war aber bis jetzt nicht weiter wichtig - dank Snapshot *g*).

Darf ich ein FDISK /MBR machen, obwohl es sich um eine NTFS-Platte handelt?

Bei der Datei browser.dll dürfte es eher ein Versionkonflikt sein. Die Datei ist vorhanden und sogar ident mit der eines anderen NT4-Systems. Die Reparatur-Installation hat einige Dateien von der Original-CD restauriert (ohne SP). Das installiert NT hat jedoch SP6a - die Probleme werden wohl eher von da her kommen.

Ich habe einmal nur ntldr neu geschrieben, dann ist das System bis zur Meldung "...ntoskrnl.exe invalid..." gekommen. Diese Datei gibt es aber auf der Original-CD nicht. Auch ein Ersetzen mit der Datei eines funktionsfähigen NT-Systems hat nichts gebracht.

Ich werde mal das Backup restaurieren und dann das FDISK drauf los lassen *g*.

danke und schöne Grüße,
Gerald

[TheProdigy]

FDISK /MBR hat tatsächlich geholfen *jodel* ... ich wäre nur die auf die Idee gekommen, dies auf einer NTFS-Platte zu machen ...

[TheProdigy]

Des Rätsels Lösung für das Nicht-Booten nach der Reparatur-Installation hab ich jetzt auch (mit hoher Wahrscheinlichkeit):

Die VM hat eine SCSI-Platte (System) und eine IDE-Platte (Daten). Das Reparatur-Tool hat immer die IDE-Platte aktualisert. Hab auf auf dieser soeben die ganzen Systemdateien (ntldr, ntdetect.com, boot.ini, ...) entdeckt.

[continuum]

Code: Alles auswählen

 ... ich wäre nur die auf die Idee gekommen, dies auf einer NTFS-Platte zu machen ...

? - was hat das denn mit NTFS zu tun?

fdisk /MBR versucht, die Partitionstabelle einer Festplatte zu lesen und zu deuten. Findet es was brauchbares, so wird im MBR eine frische Partitionstabelle geschrieben. Im MBR ist traditionell Platz fuer 4 Partitionen.

fdisk /MBR bei einer fabrikneuen Platte erzeugt etwas in der Art:

0: leer
1: leer
2: leer
3: leer

Ein MBR fuer eine Platte mit einer NTFS-Partition sieht zB so aus:

0: leer
1: von Sektor 63 bis 3456789 - Typ 07 - bootable
2: leer
3: leer

Formatierst du die Platte fuer NetBSD sieht das so aus:

0: leer
1: von Sektor 63 bis 3456789 - Typ A9 - bootable
2: leer
3: leer

Kurz gesagt - dem MBR ist es egal, was in den Partitionen wirklich steht - der Job des MBRs ist nur sich die Groesse zu merken und diese jedem zu sagen, der es wissen will zB dem BIOS.

Ulli

[AgentSmith]

@continuum

Recht haste!
Ich hätte besser lesen sollen! Für mich waren das zwei Probleme, das erste Problem war - es sollte ein REVERT gemacht werden...
... und das geht ja so! :-)

Das zweite Problem habe ich gar nicht mit dem ersten in Verbindung gebracht.

Nicht für umsonst sag ich immer: RedoLogs nur anfassen, wer weiss was er tut! ;-)

Sven

[TheProdigy]

Hast eigentlich recht - aber nachdem bei NT4 kein fdisk dabei ist, hab ich geglaubt, dass es u.U. etwas kaputt machen kann

[AgentSmith]

@theprodigy


musst dich nicht entschuldigen, damit meinte ich eigentlich mich! :-)

>>>Nicht für umsonst sag ich immer: RedoLogs nur anfassen, wer weiss >>>was er tut! ;-)

Sven

[franzkat]

fdisk /MBR versucht, die Partitionstabelle einer Festplatte zu lesen und zu deuten. Findet es was brauchbares, so wird im MBR eine frische Partitionstabelle geschrieben. Im MBR ist traditionell Platz fuer 4 Partitionen.

fdisk /MBR bei einer fabrikneuen Platte erzeugt etwas in der Art:

0: leer
1: leer
2: leer
3: leer

Also das stimmt so nicht. Der Befehl fdisk/mbr für DOS bzw. fixmbr von einer XP-CD aus macht nichts anderes als folgendes : Er schreibt den Code-Teil des MBR und läßt die Partitionstabelle völlig unberührt. Deshalb ist es für eine Partitionstabelle auch völlig ungefährlich, wenn der Befehl fdisk /mbr (fixmbr) ausgeführt wird. Der Code-Teil des MBR besteht aus Assembler-Code, der dann seinerseits die Partitionstabelle (64 Byte) interpretiert.
Der Code (die Master Boot Routine) umfaßt z.B. bei einem fdisk /mbr unter Win 98 nur 139 Byte Assembler-Code, 80 Byte sind für Fehlermeldungstext reserviert; d.h. 227 Byte bleiben frei (hier können sich dann z.B. Boot-Manager verewigen), nach der Partitionstabelle kommen dann noch die beiden Kennungs-Byte als Abschluss dazu.

Das gilt natürlich genauso für VMs.

[continuum]

Code: Alles auswählen

Deshalb ist es für eine Partitionstabelle auch völlig ungefährlich, wenn der Befehl fdisk /mbr (fixmbr) ausgeführt wird.

Einspruch

Ich habe es bei mir selber schon erlebt, dass fdisk/mbr eine Partitionstabelle voellig unbrauchbar macht .
Wenn du willst schick ich dir ein konstruiertes Beispiel.
Au ja - franzkat - lass uns mal ein bisschen kontrovers diskutieren - das kommt hier so selten vor

Ulli (in Eile)

[franzkat]

Au ja - franzkat - lass uns mal ein bisschen kontrovers diskutieren - das kommt hier so selten vor

Lol. Sind hier alle so konfliktscheu ?

fdisk /mbr(fixmbr : Wenn du ein GRUB/LILO als Bootloader aus dem MBR loswerden willst, dann hast du doch auch keine andere Möglichkeit als mit diesen Befehlen zu arbeiten. Wäre ja schlimm, wenn da jedesmal die Partitionstabelle in Gefahr geriete. Es gibt seltene Fälle, wo der Code sich nicht schreiben lassen will. Da muss man dann mit einem Tool wie killmbr o.ä. die Brechstange einsetzen. Wenn man aber vorher die Partitionstabelle mit einem Tool wie ped.exe sichert, ist das kein Problem, weil man sie dann immer zurücksichern kann.