PC kaputt, aber Platte heil: Wie gehe ich vor?

[DonLucio]

Ich schreibe diesen Thread im Anschluß an meinen "OT, hab aber sonst niemand"-Thread. Mein Problem ist wohl ein recht häufiges: Der PC gibt nach Jahren einfach irgendwann mal seinen Geist auf, startet nicht mehr, aber eben nicht aus Gründen, die in einer defekten Platte zu suchen wäre. Diese ist komplett erhalten. Nicht nur mit den reinen Daten, sondern vor allem mit seiner Boot-Partition und all den OS/2-eigenen Einstellungen und individuellen (Desktop-) Konfigurationen. Die ja fast wichtiger sind als die nackten Daten.

Und dieser Umstand, dass die Boot-Platte mit allen Partitionen intakt ist, verleitet mich zu der Hoffnung, dass es keiner großen Anstrengungen bedürfe, mein gewohntes System einigermaßen schnell wieder herzustellen: Einfach das defekte Mainboard ersetzen, durch ein BAUARTGLEICHES! (bei Ebay leicht zu beschaffen), dort die alte, intakte Platte einbauen und starten.

Ich hatte diesen Fall dreimal in den letzten zwei Jahren. Und jedesmal dasselbe ernüchternde Ergebnis:

Es funktioniert nicht!

Regelmäßig, auch jetzt in meinem aktuellen Fall wieder, erhalte ich beim Booten die Meldung: "OS/2 kann nicht auf die Platte zugreifen. Problem beheben und neu starten." und tot. Nur Power-Off-/On möglich. Es ist ein Zustand, wo man nicht einmal mit ALT-F1 in eine Kommandozeile booten könnte.

Nur zur Kontrolle, ob nicht doch irgendwas an der Platte kaputtgegangen ist, baue ich die Platte als zweite Platte in einen anderen OS/2-PC ein. Dort sehe ich dann sämtliche Partitionen vollkommen intakt. Was ich nur nicht sehen kann (z.B. mit LVMGUI) ist die Boot-Partition, besser gesagt: Den Boot-Sektor. Lt. LVMGUI ist kein Bootmanager installiert, was korrekt ist, denn auch nach meinen Erinnerungen ist das System immer über den AirBoot-Manager gestartet.

Wieso wird dieses AirBoot plötzlich nicht korrekt erkannt, nur weil ich das Mainboard ausgetauscht habe? Wie gesagt: Ein identisches Mainboard: Asus P5QL/EPU, auch die CPU ist die gleiche.

Oder verstehe ich den AirBoot-Mechanismus falsch?
Ich gehe davon aus, dass der AirBoot-Code irgendwo im MBR der Platte untergebracht ist. Und da müßte er doch immer noch sein. Wieso startet denn die Platte nicht mit einem anderen, identischen Mainboard?

Und was genau bedeutet es, wenn OS/2 mir sagt: "Kann nicht auf die Platte zugreifen"? Alles ist identisch wie jahrelang zuvor, nur das Mainboard ist physisch ein anderes.

Ich erlebe das jetzt, wie gesagt, zum dritten Mal und muß daraus schließen, dass es ein grundsätzliches Problem gibt.

Aber warum?
Warum läßt sich eine OS/2-Platte nur in dem System booten, in dem es mal installiert wurde? Kann es sein, dass OS/2 beim Installieren sich irgendwelche wichtigen Dinge im BIOS-RAM sichert? Oder per Geheimschrift auf die Mutterplatine aufmalt? Tschuldigung, kleiner blöder Scherz.

Danke,
Lutz W.

Wenn ich noch lange auf dieser Win7-Tastatur herumklimpern muß, kriege ich wieder diese häßliche Windows-Allergie ...

[axelwein]

Hallo,

eigentlich müßtest Du bei diesem Fehler von der Wartungskonsole booten können. Bei eCS 2.1 ist es dann ziemlich einfach: Eingabeaufforderung öffnen. Auf Laufwerk Z: wechseln. Folgendes eingeben:
SYSINSTX.COM X:
X: ist Dein Systemlaufwerk. Wenn Du mehrere eCS-Laufwerke hast, machst Du das für die auch gleich.

Schwieriger kann es bei älteren eCS-Versionen sein. Evtl. muß man die SYSINSTX.COM auf ein Nicht-Systemlaufwerk kopieren o.ä. Den Befehl dann von dort aus aufrufen. Das muß man ausprobieren. Auf dem Systemlaufwerk befindet sich diese Datei im Verzeichnis X:\OS2\INSTALL\BOOTDISK.

Das hat aber nichts mit AirBoot zu tun, gleiches kann mit dem IBM Boot-Manager passieren, wenn Operationen am MBR, an den Partitionstabellen, dem Boot-Manager o.ä. ausgeführt wurden, auch unbeabsichtigt. SYSINSTX.COM macht das System startfähig.

Gutes Gelingen
Axel

[wilfried]

Hallo Lutz,

hast Du schon versucht AirBoot erneut zu installieren?
Ich hoffe Du nutzt die AirBoot Version 1.1.0, die älteren Versionen haben hier auch hin und wieder Ärger gemacht.
Seit 1.1.0 sind hier keine Probleme mehr aufgetreten.
Ansonsten ist es einer eCS-/OS/2-Installation ziemlich egal auf welcher Hardware es gestartet wird. Es kann nur sein das dann der eine oder andere Treiber (LAN, Audio, ...) nicht funktioniert und gewechselt werden muss. Beispiel: Ich habe die Platte aus einem T60 in einen T410 gesteckt und konnte zumindest starten, bis zum Desktop kam ich im ersten Versuch allerdings nicht. Es gab aber damals keinen Anlaß diesem Problem weiter auf den Grund zu gehen.

[aschn]

Ansonsten ist es einer eCS-/OS/2-Installation ziemlich egal auf welcher Hardware es gestartet wird.

Genau. Wenn sich aber bei so etwas wie "ACPI erforderlich oder nicht" oder "AHCI erforderlich statt DANIS%06" geändert hat, dann kann die alte Installation nicht mehr funktionieren.

Dein Fall ist aber anders: HDD in neuen Rechner gleichen Typs oder mit Mainboard gleichen Typs eingebaut. Das läuft eigentlich auf Anhieb. (Es kann aber natürlich nicht schaden die TIpps mit sysinstx und AiRBoot zuerst mal auszuprobieren.)

Deshalb tipp ich eher darauf, dass sich die verabschiedende Hardware auch nachteilig auf das ausgewirkt hat, was auf die Platte geschrieben wurde - seien es nur Fehler in den Inis.

Nebenbei: Elektrolytkondensatoren (Elkos, einzige Bauart für hohe Kapazitäten, z.B. für Siebung der Restwechselspannung nach Gleichrichtung verwendet) verlieren an Kapazität. Das kann dazu führen, dass Elektronik nach einigen Jahren wegen zu niedrigem Strom bei höherer Last nicht mehr funktioniert. Wenn sie durchbrennen, dann stinkt es und nichts geht mehr. Folienkondensatoren (am hochwertigsten) sind selbstheilend, Tantalkondensatoren sterben unauffällig und schnell bei zu hoher Spannung, stinken aber wohl nicht. Das Verhalten von Keramikkondensatoren ist unauffällig, sie haben aber große Toleranzen und das Langzeitverhalten kenn ich nicht.

[DonLucio]

Genau. Wenn sich aber bei so etwas wie "ACPI erforderlich oder nicht" oder "AHCI erforderlich statt DANIS%06" geändert hat, dann kann die alte Installation nicht mehr funktionieren.

Bedeutet das, dass ich im BIOS meines neuen Systems grundätzlich die gleichen Einstellungen haben muß wie im alten (nun defekten) System?

Also was ACPI und AHCI angeht, habe ich immer die Maninboard-defaults verwendet.

Dein Fall ist aber anders: HDD in neuen Rechner gleichen Typs oder mit Mainboard gleichen Typs eingebaut. Das läuft eigentlich auf Anhieb. (Es kann aber natürlich nicht schaden die TIpps mit sysinstx und AiRBoot zuerst mal auszuprobieren.)

Der Meinung war ich ja bisher auch. Bis jetzt. Aber ich werde mal die besagten Tipps ausprobieren.

Weiß jemand, wo AirBoot gespeichert ist? Im MBR? Oder?
Kann man AirBoot nachinstallieren, ohne die ganze Systempartition neu zu installieren?

Deshalb tipp ich eher darauf, dass sich die verabschiedende Hardware auch nachteilig auf das ausgewirkt hat, was auf die Platte geschrieben wurde - seien es nur Fehler in den Inis.

Ich hoffe nicht! Glaube ich auch eigentlich nicht. Denn soweit erkennbar sind alle Partionen und die darauf gespeicherten Daten unversehrt (hab natürlich nicht alle zentrillionen Dateien einzeln überprüft).

Ansonsten ist es einer eCS-/OS/2-Installation ziemlich egal auf welcher Hardware es gestartet wird.

Ist das so? Das wäre für mich ein wichtiger Punkt des Verständnisses. Ich glaubte bisher, dass immer ein identisches oder zumindest familenähliches Mainboard nötig sei, um eine Boot-Platte in ein neues System einzuhängen in der Erwartung, dass diese Platte genauso booten würde wie in dem vorigen System.

Ein Freund von mir hat da eine andere These: Er meint, dass OS/2 beim erstmaligen Installieren auf einem PC sich dessen technische Eigenschaften im Detail merkt und so eine Art technischen / elektronischen Fingerprint erstellt und bei sich wegschreibt (OS2SYS.INI). Mit der Folge, dass diese Platte in einem anderen System, das zu einem abweichenden Fingerprint führt, nicht mehr korrekt booten kann.

Was ist von dieser Theorie zu halten? Ich halte sie eher für fragwürdig...

Gruß,
Lutz W.

[hneubert]

Genau. Wenn sich aber bei so etwas wie "ACPI erforderlich oder nicht" oder "AHCI erforderlich statt DANIS%06" geändert hat, dann kann die alte Installation nicht mehr funktionieren.

Bedeutet das, dass ich im BIOS meines neuen Systems grundätzlich die gleichen Einstellungen haben muß wie im alten (nun defekten) System?

Also was ACPI und AHCI angeht, habe ich immer die Maninboard-defaults verwendet.

Bei verschiedenen BIOS-Versionen könnte es sein, dass je nach BIOS-Version andere Defaults vorliegen. Um sicherzugehen, sollte man diejenigen Einstellungen, die die Plattenansteuerung direkt betreffen, auf dem neuen Mainboard im BIOS _manuell_ so einstellen wie beim alten.

Wesentlich ist, wenn AHCI beim alten Board AUS war, dies auch auf dem neuen Board auf AUS zu stellen bzw. EIN, falls es EIN war.

Beim "guten alten" OS/2 war die installierte Platte direkt umzubauen - _keine_ Bindung an die konkrete Mainboard-Hardware etwa durch "digitalien Fingerabdruck" ...

[morcvomorc]

Hallo,

erhalte ich beim Booten die Meldung: "OS/2 kann nicht auf die Platte zugreifen. Problem beheben und neu starten."

meinem Verständnis nach passiert das ja nach Airboot, also wenn OS2 bereits versucht zu booten. Ich hatte ähnliche Probleme auch schon, wenn das System nicht sauber heruntergefahren war. Bisher immer geholfen hat von CD Booten, Wartungskonsole oder Kommandozeile und dann ein "chkdsk.exe x: /f" - danach reboot.

Hoffe du hast damit ebenfalls Erfolg

[DonLucio]

...von CD Booten, Wartungskonsole oder Kommandozeile und dann ein "chkdsk.exe x: /f" - danach reboot.

Diese Idee scheint mir tatsächlich sehr plausibel (da hätte ich auch eigentlich selbst drauf kommen müssen )

Immerhin war es ja in meinem Fall so, dass deine Formulierung "nicht sauber heruntergefahren" eine milde Untertreibung wäre für das, was mir passiert ist: Der PC stürzte ab, fiel urplötzlich wie ein Stein vom Himmel, aufgrund eines bisher nicht näher identifizierten Versagens irgendeiner Mainboard-Komponente (vermutlich). Von daher dürfte wohl zwingend das "dirty flag" auf der Systemplatte (und nicht nur dort) gesetzt sein.

Morgen wird mein neues Mainboard geliefert, dann kann ich sagen, ob dein Tip geholfen hat.

Danke einstweilen,
Lutz W.

[wilfried]

Weiß jemand, wo AirBoot gespeichert ist? Im MBR? Oder?
Kann man AirBoot nachinstallieren, ohne die ganze Systempartition neu zu installieren?

Ja und ja.

[DonLucio]

Weiß jemand, wo AirBoot gespeichert ist? Im MBR? Oder?
Kann man AirBoot nachinstallieren, ohne die ganze Systempartition neu zu installieren?

Ja und ja.

MBR ist imho physischer Bestandteil der Festplatte.
Wenn das so ist:
Wieso startet dann diese Platte nicht, wenn ich sie in einen anderen PC als alleinige Platte reinhänge? PC mit identischem Mainboard-Modell.
Platte selbst ist ok. Kann sämtliche Partitionen zugreifen (wenn ich sie als Nicht-Boot-Platte reinhänge, d.h. von einer anderen Platte boote). Auch die C-Partition der fraglichen Platte ist vollkommen intakt

Also ehrlich gesagt, ich stehe vor einem Rätsel. Die fragliche Platte hat in dem alten PC sauber gebootet, via AirBoot. Bis dieser PC seinen Geist aufgab. Dann habe ich einen neuen PC gebaut, identisches Mainboard, alte Platte reingehängt, gestartet, und dann Fehlermeldung: "OS/2 kann nicht auf die Festplatte zugreifen". Nicht einmal auf eine Kommandozeile kann ich booten (Alt-F1, Alt-F2).

Seltsamerweise startet der PC anfänglich, mit dem altbekannten OS/2-Bootlogo, um dann kurz darauf die o.a. Fehlermeldung auszugeben. Vorher bootete die Platte direkt in das AirBoot-Menü, um dann zum "normalen" OS/2-Bootvorgang (mit OS/2-Bootlogo) überzugehen.

Ob es hilft, den MBR komplett zu löschen? Ich glaube DFSee kann das.

[wilfried]

Wenn Du schon das OS/2-Bootlogo siehst hast Du kein Problem mit dem MBR.
Kannst Du den Rechner mit einer ecs-Installations-CD starten und einen Checkdisk auf die C:-Platte machen?
Stichwort: Wartungskonsole

[Sigurd]

Nur zur Kontrolle, ob nicht doch irgendwas an der Platte kaputtgegangen ist, baue ich die Platte als zweite Platte in einen anderen OS/2-PC ein. Dort sehe ich dann sämtliche Partitionen vollkommen intakt. Was ich nur nicht sehen kann (z.B. mit LVMGUI) ist die Boot-Partition, besser gesagt: Den Boot-Sektor. Lt. LVMGUI ist kein Bootmanager installiert, was korrekt ist, denn auch nach meinen Erinnerungen ist das System immer über den AirBoot-Manager gestartet.

Wieso wird dieses AirBoot plötzlich nicht korrekt erkannt, nur weil ich das Mainboard ausgetauscht habe? Wie gesagt: Ein identisches Mainboard: Asus P5QL/EPU, auch die CPU ist die gleiche.

Was mir zu "Zwei Platten" in den Sinn kommt:

Meine Erfahrung mit dem Airbootmanager bei zwei Platten im PC ist, dass dieser nur erkannt wird, wenn die Platte, auf der er installiert ist, auch als erste im BIOS als "bootbare" eingetragen ist. Wenn die Platte, auf der der Airboot installiert ist, auf der zweiten Platte ist, die also auch vom BIOS als zweite Platte erkannt wird, dann kann man auf den nicht zugreifen. Es hat dann bei mir zum Beispiel geholfen, die Platten auch "physisch" zu vertauschen.

Also:
- die Platte ohne Airboot war an SATA 0 (oder IDE 0)
- die Platte mit Airboot war an SATA 1 (oder IDE1)
Folge: Airboot wird nicht erkannt bzw. startet nicht

Abhilfe:
- Platte von SATA 0 (oder IDE 0) an SATA 1 (oder IDE1)
- Platte von SATA 1 (oder IDE 1) an SATA 0 (oder IDE0)

Das ThinkPad W700 hat zum Beispiel 2 Laufwerksschächte für Platten, und da ist mir das passiert. Da reichte es (wenn mich meine Erinnerung nicht täuscht) nicht aus, nur im BIOS die Startreihenfolge der Platten zu ändern, diese mussten auch physisch umgesteckt werden.

Ich hoffe, ich konnte mich verständlich ausdrücken und ebenso das es Dir weiterhilft.

[axelwein]

Also offen gestanden, ich verstehe Dich nicht!

Du willst Hilfe. Aber wenn man Dir antwortet, was Du machen solltest, machst Du es nicht, obwohl ich es doch wohl ganz klar erklärt habe (wenn nicht, dann frage nochmal nach). Und das Vorgehen ist doch wirklich einfach durchführbar. Und ungefährlich für Deine Daten.

MBR ist imho physischer Bestandteil der Festplatte.
Wenn das so ist:
Wieso startet dann diese Platte nicht, wenn ich sie in einen anderen PC als alleinige Platte reinhänge?

Ja warum wohl? - Weil es nicht am MBR und nicht am Boot-Manager liegen kann, sonst würde AirBoot gar nicht hochkommen und das Bootlogo erst recht nicht.

Seltsamerweise startet der PC anfänglich, mit dem altbekannten OS/2-Bootlogo, um dann kurz darauf die o.a. Fehlermeldung auszugeben.

Das ist nicht "seltsamerweise", sondern das ist logisch, weil die Platte nicht mehr bootfähig ist.

Ich wechsle öfters meine Platten zwischen meinen unterschiedlichen Boards, jedesmal erhalte ich nach dem eCS-Bootlogo die von Dir angegebene Meldung. Und jedesmal mache ich die Platte anschließend mit SYSINSTX.COM wieder bootfähig (oben beschrieben), und alles funktioniert wieder. Das hatte ich bestimmt schon 40 bis 50 Mal.

Wenn Du es probiert hast, und es geht wirklich nicht, dann kannst Du wieder fragen. Aber jetzt tu es erst Mal!

Axel Wein

[DonLucio]

Also offen gestanden, ich verstehe Dich nicht!
Du willst Hilfe. Aber wenn man Dir antwortet, was Du machen solltest, machst Du es nicht, obwohl ich es doch wohl ganz klar erklärt hab

Ja, warum habe ich es nicht gemacht?
Weil du schriebst:
"eigentlich müßtest Du bei diesem Fehler von der Wartungskonsole booten können. Bei eCS 2.1 ist es dann ziemlich einfach: Eingabeaufforderung öffnen. Auf Laufwerk Z: wechseln. Folgendes eingeben:
SYSINSTX.COM X:"

Und weil in meinem Fall eben diese Wartungskonsole NICHT erscheint, trotz mehrfachen Versuchen mit Alt-1 und Alt-F2.

Aber ich habe jetzt (erst) begriffen, dass du mit "Wartungskonsole" nicht eine gewöhnliche Kommandozeile meinst, sondern: "Starte eine Installations-CD und öffne dort die Wartungskonsole."

Ok. Habe ich jetzt nachgeholt.

Und was soll ich sagen: Nix kann ich sagen, ich bin sprachlos. Besoffen vor Glück. Es funktioniert!

Seit Jahren habe ich nach einer Lösung für dieses Problem gesucht. Immer wieder passiert es mal (im Abstand von Jahren, ok), dass mein eingespieltes System aufgrund von Hardware-Fehlern nicht mehr bootet. Und ich dann dieses Problem habe, meine (noch intakte) Platte mit gewachsener Umgebung einfach in eine neue Hardware reinhängen möchte, OHNE alles neu installieren zu müssen. Und regelmäßig daran scheitere. Weil ich diesen Sysinstx-Befehl nicht kannte.

Ja, es ist alles ganz einach, man muß nur Bescheid wissen ...

Also ich danke dir für den Tipp, und vor allem dafür, dass du noch mal hartnäckig nachgesetzt hast.

Gruß,
Lutz Wagner


P.S.
Also meine neue Hardware bootet jetzt, mit meinem alten eCS-System und der ganzen Umgebung. Super. Nur ein kleiner Schönheitsfehler ist noch zu beklagen: Mein Desktop ist total durcheinander gewürfelt. Alle Icons haben ihre ursprüngliche x,y-Position verloren. Es ist - wie gesagt - nur ein kleiner Schönheitsfehler, ich kann das wieder beheben. Aber woran kliegt das? Offenbar hat meine OS2SYS.INI Schaden genommen? Gibt es auch dafür Abhilfe?

[wilfried]

Mein Desktop ist total durcheinander gewürfelt. Alle Icons haben ihre ursprüngliche x,y-Position verloren.

Wenn das bei mir auftritt habe ich mit einer anderen Auflösung gestartet.

[Andi B.]

Wenn das bei mir auftritt habe ich mit einer anderen Auflösung gestartet.

Wenn dass der Grund ist, dann braucht man aber im Gegensatz zu Windoze bei OS/2 nur mit der richtigen Auflösung starten und alle Objekte sind wieder am richtigen Platz. Außer die os2.ini ist wirklich zerschossen.

[DonLucio]

[Problem durcheinandergewürfelte Icon-Positionen] ... Außer die os2.ini ist wirklich zerschossen.

Die OS2.INI sowie OS2SYS.INI habe ich ja wiederhergestellt (aus einer Datensicherung; unter Umgehung der RASH-Attribute, die ein "normales" Kopieren unmöglich machen).
Das hat aber meine verlorenen x,y-Positionen nicht zurückgebracht.

Was mich zu der Frage führt: Wo eigentlich genau merkt sich OS/2 diese Positionen? In den INIs offenbar nicht. Vielleicht in den EAs? Weiß da jemand Genaueres drüber?

Gruß,
Lutz W.

[aschn]

Wo eigentlich genau merkt sich OS/2 diese Positionen? In den INIs offenbar nicht. Vielleicht in den EAs?

Dazu hab ich doch in Deinem anderen Tread zu diesem Thema etwas geschrieben. Damit ich nichts falsches texte, hatte ich extra vorher nachgesehen, AFAIR. Dazu bin ich jetzt zu faul. Nur so viel, weil leicht zu merken: Solche Einstellungen, die man nirgendwo anders findet, von Dateisystemobjekten werden in den .CLASSINFO EAs gesichert, Einstellungen von abstrakten Objekten u.a. in OS2.INI -> PM_AbstractObjects. Beides ist undokumentiert.

Ich hab jetzt doch mal weiter nachgesehen: Der Desktop speichert die Position seiner Objekte natürlich im EA .ICONPOS. Wenn Du mit Alt+F1 ein WPS-Archiv wieder hergestellt hast, dann wird auch der Desktop ersetzt. Das bedeutet: Die Eas sind schon fehlerhaft in der Sicherung enthalten.

Noch zwei Hinweise: Mach lieber vor Experimenten eine vollständige Sicherung der Systempartition, auch wenn nicht alles OK ist. Das geht super mit ZIP. Öffne nie mit der aktuellen WPS den Desktop einer anderen Systempartition oder Objekte davon. Das gilt auch für die Archivdateien. (Z.B. mit FM/2 ist das kein Problem.) AFAIR führt das mit Sicherheit zur Verdoppelung vieler Schablonen.

[axelwein]

Hallo,

gut, daß es jetzt geht.

Die Arbeitsoberfläche wiederherstellen kannst Du so mit dem Copy-Befehl nicht machen. Zunächst einmal muß zum Sichern der Arbeitsoberfläche diese Funktion eingeschaltet sein. Dies geschieht mit rechtem Mausklick auf die blanke Arbeitsoberfläche, dann wählst Du "Einstellungen" und dann den Tab-Reiter "Archivieren". Dort muß "Arbeitsoberfläche archivieren" markiert sein. Ich habe alle '1' Tage eingetragen/markiert. und "Behalte '5' Archive bei" ausgefüllt (weil die vorgegebenen '3' Archive bei Problemen sehr knapp sein können). Die Bootpartition muß allerdings groß genug sein.

Wenn das nicht schon eingeschaltet war, hast Du jetzt im Nachhinein schlechte Karten.

Im Fehlerfall kannst Du dann beim Booten eine funktionierende Arbeitsoberfläche wiederherstellen: Nach dem Boot-Manager erscheint links oben das weiße Rechteck mit der Schrift ECS. In diesem Moment drückst Du ALT + F1. Auf der folgenden Tafel kannst Du ganz unten die gespeicherten Archive auswählen. Normalerweise wählt man das neueste, wenn das nicht gut ist, kann man es nochmal mit dem nächsten probieren. Während dem weiteren Bootvorgang wird dann das ausgewählte Archiv automatisch wiederhergestellt.

Man könnte wohl auch die INIs sichern, damit habe ich aber schon schlechte Erfahrungen gemacht.

Viele Grüße
Axel Wein

[DonLucio]

Die Arbeitsoberfläche wiederherstellen kannst Du so mit dem Copy-Befehl nicht machen. Zunächst einmal muß zum Sichern der Arbeitsoberfläche diese Funktion eingeschaltet sein. Dies geschieht....

Ok, diese Funktion kenne ich, habe sie auch von Zeit zu Zeit (leider nicht täglich) eingeschaltet.
Ich bin aber der Meinung - korrigiere mich bitte, falls nötig - dass mit dieser Archivierungsfunktion nicht nur die Arbeistoberfläche wieder hergestellt werden kann, sondern es werden ggf. auch Config.sys, Treiber und weitere Einstellungen des Systems wieder auf den Zeitpunkt der Sicherung zurückgesetzt. Und das würde ich nicht wollen.

Also Frage: Werden mit der Archivierungsfunktion wirklich nur die Paramter (x,y-Positionen, Farben, Schriften etc.) der Arbeitsoberfläche gesichert?

Gruß,
Lutz W.

[DonLucio]

Wo eigentlich genau merkt sich OS/2 diese Positionen? In den INIs offenbar nicht. Vielleicht in den EAs?

Der entscheidende Teil deiner Antwort ist dieser Satz:

Öffne nie mit der aktuellen WPS den Desktop einer anderen Systempartition oder Objekte davon.

Genau das habe ich getan! Als ich die Platte in ein anderes eCS-System eingehängt habe (als reine Datenplatte), habe ich von diesem anderen Desktop aus das Dateiobjekt "Arbeitsoberfläche" geöffnet (um zu sehen, ob noch alle Daten intakt sind).
Mir leuchtet jetzt ein: Damit habe ich die Icon-Positionen selber durcheinandergebracht.

Solche Einstellungen, die man nirgendwo anders findet, von Dateisystemobjekten werden in den .CLASSINFO EAs gesichert, Einstellungen von abstrakten Objekten u.a. in OS2.INI -> PM_AbstractObjects.

Zumindest die EAs sollte man doch mit einem Rexx-Dreizeiler relativ einfach sichern können, oder? (Naja, vielleicht ein 5Zeiler...).

Danke für die Erläuterungen.

Gruß,
Lutz W.

[Andi B.]

Das hat aber meine verlorenen x,y-Positionen nicht zurückgebracht.

Es gibt auch die Arbeitsplatz - Einstellungen - Befehle Anordnen und Sortieren. Einmal angeklickt oder das entsprechende Tastenkürzel gedrückt und alle Icons werden verschoben. Tastenkürzel weiß ich jetzt nicht auswendig und ich probiere das jetzt auch nicht aus.

Ich weiß nur, manchmal passiert mir das halt weil grad die Arbeitsoberfläche den Focus hat und ich tippe. Dann schalte ich den Rechner hart aus (Power Knopf nachdem ich ev. offene Dateien geschlossen habe). Ist aber nicht jedermanns Sache. Oder ich spiele einfach ältere os2.ini und os2sys.ini zurück (von der Wartungspartition, oder dem Destop Archiver, oder eins der DMT backups, oder ...).

[aschn]

Dann schalte ich den Rechner hart aus (Power Knopf nachdem ich ev. offene Dateien geschlossen habe).

2x Ctrl+Alt+Del reicht. Dann werden wenigstens die Dateisysteme abgeschlossen.

Oder ich spiele einfach ältere os2.ini und os2sys.ini zurück (von der Wartungspartition, oder dem Destop Archiver, oder eins der DMT backups, oder ...).

So ähnlich mach ich das auch. Wenn auf dem Desktop etwas nicht stimmt oder z.B. irgendein Objekt fehlt, dann drücke ich 2x Ctrl+Alt+Del zum Neustarten. Danach boote ich von der Wartungspartition (nur Befehlszeile mit Alt+F1 ist mir zu unkomfortabel) und kopiere ältere Inis über die aktuellen. Die kommen dann entweder von XWP oder DMT, das ja bei ArcaOS in IFX umbenannt wurde. WPS-Archive musste ich seit etwa 10 Jahren nicht mehr wiederherstellen, die Inis haben immer gereicht.

[LotharS]

2x Ctrl+Alt+Del reicht.

Oder auch (Ctr+Alt)halten+2xDel
Nachtrag: ... bzw. Ctrl rechts + 2xDel in VM unter Virtualbox.
Eine härtere Methode war (Ctr+Alt) + 2x NumLock (falls vorhanden), tat im absoluten Hänger-Fall immer, hab's aber lange nicht mehr benutzt.

[aschn]

Eine härtere Methode war (Ctr+Alt) + 2x NumLock (falls vorhanden), tat im absoluten Hänger-Fall immer

Das will dann einen Prozessdump auf Disketten schreiben. Ein Überbleibsel aus der Steinzeit. Trotzdem ist diese Funktion mit das sicherste an Systemfunktionen, was sich aufrufen lässt. Machmal geht auch das nicht mehr und nur noch der Reset-Taster hilft. Wenn's aber geht (bei mir in 90 % aller Fälle), dann lässt sich danach Ctrl+Alt+Del drücken und die Kiste startet neu.