VOICE Homepage: http://de.os2voice.org
[Inhaltsverzeichnis]
[Vorherige Seite] [Nächste Seite]
[Artikelverzeichnis]
|
VOICE Homepage: http://de.os2voice.org |
April 2003
[Inhaltsverzeichnis]
|
| Von Peter Hinckley © April 2003, Übersetzung: Philhard Ackermann |
Wenn es Ihnen geht wie mir, dann gehören Sie zu den OS/2-Anwendern, die aufgrund der unvergleichlichen Stabilität dieses Systems sowie der weitestgehenden Unabhängigkeit von fortlaufenden Systemupgrades, die es mit sich bringt, dabeigeblieben sind. Anders als der durchschnittliche Windows-Anwender haben Sie sich ein recht fundiertes Wissen über seine grundlegende Arbeitsweise verschafft und sind sich der Möglichkeiten bewußt, die OS/2 uns zur Verfügung stellt, um das System so zu konfigurieren, daß es tut, was Sie möchten, und nicht nur das, was irgendein Programmierer im 'Betriebssystemwunderland' für das beste für Sie gehalten hat. Dieser Artikel ist der Versuch einer Schilderung der Erfahrungen, die ein Anwender bei seinen Installations- und Konfigurationsversuchen sowie bei der Übernahme eines bestehenden Systems auf eine größere Festplatte (als Master am primären IDE-Kanal) gemacht hat, und richtet sich an alle, die so etwas nicht oft genug durchexerzieren, um sich selbst zu der Art Systemingenieur auszubilden, für die solche Vorgänge zum Tagesgeschäft gehören.
Meine Master-Platte am primären IDE-Kanal (D1) war eine 10-GB-Platte von Western Digital, auf welcher ich Warp 4.50 mit FixPak 15 installiert hatte. Vor einigen Monaten hatte ich dieses System auf den Releasestand 4.52 der SoftwareChoice gebracht, und erst vor kurzem begann ich mich für Linux zu interessieren. Das ganze stellte ohnehin schon eine Multisystemumgebung dar (OS/2, DOS 6.22 und W98, s. Abbildung 1), und ich nahm an, daß ich einfach nur ein paar Partitionen verkleinern müßte, um Platz für das neue Betriebssystem zu schaffen. Schließlich hatte ich das vor einigen Jahren beim Aufbau dieser Umgebung genau so mit Fdisk und PartitionMagic gemacht. Das neue Plattenverwaltungsprogramm LVM jedoch, welches mit V4.51 ff und eComStation eingeführt worden war, weigerte sich beharrlich, irgendwelche Änderungen im MBR wegzuschreiben. Ich steckte also fest, und mir stand eine komplette Repartitionierung samt Reinstallation bevor, also eine sehr umfangreiche Wiederherstellungsoperation. Da mein örtlicher Computerhändler gerade Festplatten im Sonderangebot hatte, entschloß ich mich, eine neue D1 einzubauen und alles von der 10GB-Platte 'hinüberzuklonen'.
Bevor wir fortfahren ist es jedoch angebracht, ein paar Fachbegriffe zu erläutern, von denen einige hier benutzt und andere mit voller Absicht vermieden werden. Festplatte, Laufwerk x:, Platte, primäre Master-Einheit, primäre Slave-Einheit, primäre Partition, erweiterte Partition, logische Partition, Platteneinheit, Kompatibilitätsplatteneinheit, LVM-Platteneinheit, erweiterte Platteneinheit - das wird alles recht verwirrend, zumal diese Begriffe häufig verwechselt oder synonym verwendet werden, was man aber wirklich vermeiden sollte.
Eine Festplatte, im folgenden als 'Platte' bezeichnet, ist eine in sich abgeschlossene Einheit mit mehreren 'Plattentellern' sowie Schreib- und Leseköpfen. Eine solche Platte ist in Bereiche aufgeteilt, die man 'Partitionen' nennt, und welchen vom Betriebssystem [üblicherweise] ein Laufwerksbuchstabe zugewiesen wird. Programme zur Verwaltung von Partitionen wie LVM nummerieren alle Platten, die sie im System vorfinden, durch; die erste Platte wird Platte 1 (abgekürzt D1 aus dem englischen 'Disk 1'), die nächste Platte 2 (abgekürzt D2) und so weiter, unabhängig davon, ob es sich um IDE-, SCSI- oder PCMCIA-Platten handelt (man möge mir vergeben, aber ich habe keinerlei Erfahrung mit USB-Platten). Bei Mischsystemen (also z.B. gleichzeitig IDE und SCSI usw.) wird es dabei etwas schwierig, vorherzusagen, welche Platte welche Nummer erhalten wird, weil dies sehr von der jeweiligen Hardware- und Systemkonfiguration abhängig ist.
Im Falle des IDE-Busses hat man üblicherweise zwei IDE-Controller (bisweilen auch 'Kanäle' genannt) auf der Hauptplatine. Jeder Controller ist in der Lage, zwei Festplatten zu betreiben, wobei eine davon als 'Master' und die andere als 'Slave' bezeichnet wird - dies ergibt eine maximale Anzahl von 4 Platten, die hier angeschlossen werden können (hinzu kommen solche, die z.B. an Erweiterungskarten angeschlossen sind). Man nennt diese Platten 'Primärer Master' (im LVM als D1 oder Disk 1 angezeigt) und 'Primärer Slave' (D2 bzw. Disk 2 im LVM). LVM bezeichnet den sekundären Master sowie den sekundären Slave als D3 und D4. Wird der SCSI-Bus verwendet, dann ist D1 die Startplatte, wobei diese unter anderem durch die Einstellungen im BIOS des Rechners sowie des SCSI-Adapters (und nebenbei auch noch durch die LUN (Logical Unit = logische Einheit) der Startplatte sowie des SCSI-Adapters und auch das etwaige Vorhandensein eines weiteren SCSI-Adapters etc.) bestimmt wird. Unabhängig davon, welcher Bustyp zur Ansteuerung der Platten verwendet wird, ist D1 immer die erste Platte im System. An manchen Stellen wird D1 auch als 'erstes Festplattenlaufwerk' bezeichnet, aber das kommt auf dasselbe hinaus.
Nach diesem Schema werde ich auch in diesem Artikel vorgehen: D1 für die erste Platte, D2 für die zweite usw. und nicht etwa Master/Slave. In meinem System befinden sich zwei IDE-Platten am ersten IDE-Controller, ein CDROM am zweiten, ein SCSI-ZIP 100 und ein PCMCIA-Kartenleser. LVM erkennt die beiden IDE-Platten als D1 und D2, wobei D3 entweder das ZIP oder der Kartenleser (mit eingelegter CF-Karte) ist, wobei das jeweils andere Gerät zu D5 wird - es kommt darauf an, in welches Laufwerk der jew. Datenträger zuerst eingelegt wird, und auch darauf, zu welchem Zeitpunkt ich auf Austauschbaren Datenträger aktualisieren klicke. D4 scheint dabei das CDROM zu sein, aber das spielt im Rahmen dieses Artikels keine Rolle.
In der LVM-Welt sollte man weniger in Begriffen wie "Laufwerk C:", "Laufwerk D:" usw. und mehr an die Platten als D1, D2 etc. denken, in welcher Reihenfolge auch immer LVM sie im System identifiziert.
Abb. 1, Ansicht der 10GB-Western Digital-Platte als "D1" in Partition Magic
3.03 vor dem Einsatz von LVM. Der OS/2-Bootmanager befindet sich in der dritten
primären Partition.
Nachforschungen im Internet sowie in einigen Büchern versorgten mich mit einem groben Überblick über die für die Einteilung der neuen Platte notwendigen Vorgehensweise: der Master Partition Boot Record ist in der Lage, die Lage von maximal 4 Partitionen aufzunehmen. Eine davon kann eine erweiterte Partition sein, also eine Einrichtung, die es uns ermöglicht, eine ganze Reihe logischer Partitionen in Form einer verketteten Liste von Partitionstabellen anzulegen (die Maximalzahl logischer Partitionen ist dabei lediglich davon abhängig, wieviele solcher Partitionen vom jeweils eingesetzten Betriebssystem verdaut werden können).In der Praxis bedeutet dies bei der Einrichtung eines Multiboot-Systems, daß uns maximal 3 nutzbare primäre Partitionen zur Verfügung stehen, und die verschiedenen Betriebsysteme haben sehr verschiedenartige Einschränkungen bezüglich der Frage, welcher Teil eines Systems auf welcher Art von Partition abgelegt werden kann. DOS-basierte Betriebssysteme (DOS, Windows) haben hier ihre ganz spezielle Anforderung: Sie bestehen darauf, auf der ersten Partition der ersten Platte installiert zu werden. Linux ist hier etwas weniger zickig: es erwartet lediglich, daß sein /boot-Verzeichnis auf D1 oder D2 liegt (s. auch die Erläuterungen weiter unten), während OS/2 ab Version 2.1x aufwärts auch in vollem Umfang in einer logischen Partition installiert werden kann (die Einschränkungen bezüglich der Lage eines OS/2-Systems haben sich über die Jahre mit jedem Upgrade und FixPack immer weiter verringert - ein modernes OS/2 kann praktisch (mit gewissen Einschränkungen) überall installiert werden). Der Bootmanager muß sich in einer primären Partition auf D1 or D2 befinden. Jedenfalls mußte ich sorgfältig darauf achten, daß alles auf der Partition seiner Wahl zu liegen kommen würde.
Ich beschloß daher, nach folgendem Schema vorzugehen: die erste primäre Partition würde dem Bootmanager gehören, auf die zweite sollte Windows, auf die dritte /boot von Linux (was sich im nachhinein als falsch erwies - ich hatte die Linux-Anforderung "unterhalb der ersten 1024 Zylinder" fälschlicherweise mit "primärer Partition" gleichgesetzt - s. unten unter Windows, DOS, Linux und OS/2), und die vierte sollte die erweiterte Partition als "Container" für alle logischen Partitionen sein, von denen zwei für OS/2 vorgesehen waren, während der Rest eine bunte Mischung aus FAT16, HPFS, JFS und ext3 (die neue Version des Linux-Dateisystems von ext2 mit Dateisystemjournal) werden sollte.
Außerdem fand ich heraus, warum ich die Anordnung der Partitionen meiner 10GB-Platte nicht verändern konnte: unter Einsatz von DFSee und der Mithilfe des ausgezeichneten DFSee-Kundendienstes konnte aufgedeckt werden, daß dieser Zustand auf fehlerhafte Einträge der Partionsgrenzen in der erweiterten Partition zurückzuführen war.
Jan van Wijk erklärt dies folgendermaßen: Partitionen werden auf zwei verschiedene Arten beschrieben, nämlich CHS (cylinder-head-sector = Zylinder-Scheibennummer-Sektor, "fange hier an und höre da auf") und LBA (logical block addressing = lineare logische Blockadressierung, "fange hier an und gehe soundso weit"). Die Partitionstabelle enthält immer beide Varianten, und beide müssen abgeglichen werden. Die meisten modernen Plattenverwaltungsprogramme verwenden lediglich die LBA-Beschreibung und ignorieren die CHS-Werte, aber diejenigen, die sowohl LBA als auch CHS verarbeiten (und zu diesen gehört LVM), werden sich bei Abweichungen zwischen CHS- und LBA-Werten schlicht weigern, mit einer solchen Partition noch irgendetwas anderes anzustellen als sie zu löschen. Konflikte zwischen CHS- und LBA-Informationen können von einer ganzen Reihe von Ereignissen ausgelöst werden. Dazu gehören Dinge wie eine Veränderung der Plattengeometrie im BIOS oder die Verwendung eines anderen Plattentreibers. Mit CHS können Platten, die größer als 8GB sind, nicht definiert werden, weil es am dafür zur Verfügung stehenden Speicherungsort nicht möglich ist, einen Wert größer als 1023 einzutragen.
Über die Jahre hinweg hatte ich die BIOS-Einstellungen für die Platte optimiert, die Hauptplatine ersetzt (eine Aufrüstung von einem Asus P2L97 auf ein Abit KT7E) und einige Rekonfigurationen mit PQMagic vorgenommen. Ungeachtet der eigentlichen Veränderung fand LVM fehlerhafte Werte und war nicht mehr bereit, irgendwelche Veränderungen auf die Platte zurückzuschreiben - nicht einmal mehr mit "LVM /NEWMBR:1", was eigentlich für die Behebung von MBR-Problemen vorgesehen ist.
In genau dieser Lage befand ich mich, als ich mich entschied, eine neue Platte zu erwerben und die existierenden Partitionen darauf zu klonen. An dieser Stelle sollte ich wohl erwähnen, daß 'Klonen' nichts mit DFSee respektive seinem CLONE-Befehl zu tun hat. Wenn ich DFSee verwendet habe, dann zur Neuzuordnung von Laufwerksbuchstaben und zur Fehlerdiagnose, jedoch nicht im Zusammenhang mit der Übertragung der Konfiguration der 10GB-Platte. DFSee besteht aus einer ansehnlichen Ansammlung von Plattenhilfsprogrammen und wäre eine eigene Artikelserie wert. Die Partitionen der neuen Platte sind in exakt der Reihenfolge angeordnet, wie sie auf der alten Platte besteht, mit Ausnahme der allerletzten Partition. Sollte eine Zielpartition einen anderen Laufwerksbuchstaben aufweisen, dann wäre eine Anpassung aller Verweise auf den alten Laufwerksbuchstaben in den verschiedensten INI-Dateien erforderlich - ein sehr zeitraubendes und fehlerträchtiges Unterfangen. Wegen weiterer Informationen bezüglich der Verlegung von OS/2-Anwendungen auf Partitionen mit anderen Laufwerksbuchstaben konsultieren Sie bitte die Ratgeberseite der Southern California OS/2 User Group (SCOUG): http://www.scoug.com/os24u/2003/scoug302.mrkia.html. Ich habe lediglich die C:-Platte, die für Windows98, geklont. Sollten sich beim Klonen eines DOS-basierten Betriebssystems weitere startbare primäre Partitionen auf der neuen Platte befinden, dann müssen diejenigen, auf die nicht geklont werden soll, vorher versteckt werden.
Als meine zukünftige D1 erwarb ich eine 40GB Maxtor IDE-Platte und schloß sie vorübergehend als D2 an meinen Rechner an. Mit LVMGUI (und nicht dem von Maxtor mitgelieferten MAXBLAST) legte ich die folgenden primären Partitionen an (s. auch das Säulendiagramm der D1 in Abb. 2):
Boot manager, 1 Zylinder (als freien Platz angelegt)
C:, 2 GB FAT16, für W98
und die folgenden logischen Partitionen:
?, ext3 78 MB (hellgrau), Linux /boot
2929, ext3 (grau), Linux /root
D: HPFS, OS/2 Betrieb
E: HPFS, OS/2 Wartung
F: FAT16, Datenaustausch zwischen OS/2, W98 und Linux
G: HPFS, OS/2-Programme und Daten
8401 MB, ext3 (grau) Linux
16 MB, (grau) Linux swap
H: HPFS, Daten
M: HPFS, Daten
Abb. 2, Ansicht der 40GB-Maxtor als D1 in LVMGUI nach der Partitionierung
Konfiguration und dem Anschluß als IDE0, der neuen primären Mastereinheit..
Die D2 war schon vorher in Verbindung mit der 10GB-Platte im Einsatz (in Abb.
1 nicht dargestellt) und enthält Datenpartitionen. Der OS/2-Bootmanager
befindet sich nun auf der ersten primären Partition der D1. Die zukünftige
Partition für das Linux- /boot-Verzeichnis ist hervorgehoben.
LVM hüllt sich bezüglich erweiterter Partitionen in Schweigen und zeigt sie nicht an (PMagic zeigt sie an, s. Abb. 1). Die Linux-Partitionen wurden erst nach der Anfertigung der obenstehenden Abbildung formatiert und eingerichtet, deshalb werden sie hier noch als 'unformatiert' (unformatted) angezeigt (hellgrau).
Fast alle PC-Betriebssysteme verwalten Platten nach ein- und demselben Grundschema, indem sie sie in Datenbereiche, Partitionen genannt, aufteilen. LVM.EXE (GUI-Version: LVMGUI.EXE) ist OS/2s neues Schmankerl zur Verwaltung von Plattenpartitionen und ersetzt den langjährigen und ehrwürdigen FDISK.EXE. Ist man FDISK und feste Laufwerksbuchstaben gewöhnt, dann kann LVM auf den ersten Blick ziemlich geheimnisvoll wirken.
Wird OS/2 Version 4.51ff oder eCS verwendet (Nach- oder Neuinstallation), dann wird LVM zwingend dazu eingesezt, um allen am PC angeschlossenen Platten seine speziellen Informationen hinzuzufügen. Man kann dies unter Nutzung von LVM selbst machen, oder automatisch durch VCU.EXE erledigen lassen, was jedoch im Falle veralteter Plattentreiber, die nicht in der Lage sind, die neue, größere Platte korrekt zu erkennen (s. unten), einige Fallstricke mit sich bringt. Man hat keine Wahl - diese neueren Versionen von OS/2 laufen nur noch mit LVM-konvertierten Partitionen. Nicht-LVM-Betriebssysteme (OS/2 v3, OS/2 v4.50, Linux, DOS, Windows, etc.) werden hiervon nicht beeinträchtigt. Sie sind nicht in der Lage, diese LVM-Informationen zu verarbeiten, und machen weiterhin die von ihnen gewohnte Zuordnung von Laufwerksbuchstaben zu Partitionen, genau so, wie sie es immer getan haben. Ausschließlich die LVM-tauglichen OS/2 und eCS sind in der Lage, manuell mit LVM zugeordnete Laufwerksbuchstaben und/oder partitionsübergreifende logische Datenträger zu erkennen. Da LVM den FDISK ersetzt, resultiert jeder [OS/2] FDISK-Aufruf auf einem LVM-System lediglich in der Aufforderung, LVM zu verwenden.
DOS-, vor-LVM-OS2- und Windows-Systeme ordnen jeder Partition automatisch, beginnend bei C:, einen Laufwerksbuchstaben zu. Auf einem LVM-tauglichen OS/2 schreibt LVM spezielle Informationen in ungenutzte Bereiche am Ende der Spur, die den MBR enthält, welche dem System dazu dienen, die Zuordnung von Laufwerksbuchsteben zu erkennen. Ausgenommen bei primären Partitionen bezeichnet ein Laufwerksbuchstabe nicht mehr länger eine spezifische Partition. Hinzu kommt die Möglichkeit, einer Partition einen Laufwerksbuchstaben 'von Hand' zuzuordnen, und zwar unabhängig davon, an welcher Stelle diese Partition in der physikalischen Reihenfolge aller an das PC-System angeschlossenen Platten erscheint (in gewissen Grenzen; CDROM-Laufwerksbuchstaben können mit LVM nicht verändert, wohl aber reserviert werden). Sie können zudem übergreifende logische Datenträger definieren, welche aus mehreren physikalischen Partitionen auch unterschiedlicher Platten bestehen, und dieser Zusammenstellung einen (nur einen) eigenen Laufwerksbuchstaben zuweisen. Anders ausgedrückt: Laufwerksbuchstaben können separate Partitionen repräsentieren, genau so, wie sie es schon immer getan haben (genannt "Kompatibilitätslaufwerk"), oder sie können als Einsprungpunkt zu einem Laufwerk "X:" dienen, welches aus verschiedenen Partitionen einer oder mehrerer Platten besteht (genannt "LVM-Laufwerk"). Ein LVM-taugliches OS/2 kümmert sich nicht mehr darum, was hinter einem Laufwerksbuchstaben steckt (oder wo die Bestandteile liegen), sondern eher, welchen Namen das Ganze trägt.
Desweiteren ist es unumgänglich, darauf zu achten, daß auf allen Systemstartdatenträgern, die man beim Übergang zu einem LVM-System verwendet (oder im Falle von Kloning, auf der Startplatte, von der aus gearbeitet wird) möglichst aktuelle Plattentreiber installiert sind, d.h. Plattentreiber, die in der Lage sind, die Geometrie der neuen Platte korrekt zu erkennen - ansonsten besteht die Gefahr, daß die Partitionstabellen zerstört werden. Jan van Wijk weist darauf hin, daß man sich in einer solchen Katastrophensitutation zwar helfen kann, daß dies aber ein sehr komplexer Vorgang ist. Er rät, das System in einem solchen Fall von Disketten aus zu starten, die die benötigten aktuellen Plattentreiber enthalten, und anschließend LVM aufzurufen, um die benötigten Partitionsinformationen zu generieren (besser, als sich auf den Automatismus eines VCU.EXE zu verlassen) oder die VCU-Implementierung in DFSee zu verwenden, und danach mit der Installation fortzufahren. Ich meinerseits habe die Erfahrung gemacht, daß ich die neue Platte nach dem Hochfahren von OS/2 von der alten D1 aus problemlos einrichten konnte, weil ich dort ohnehin die neuesten Treiber von Daniela Engert im Einsatz hatte.
Nicht verwirren lassen: Der OS/2-LVM hat nichts mit dem gleichnamigen Partitionsverwaltungsprogramm
zu tun, welches bei Linux verwendet wird. Der Linux-LVM ist zwar auch in
der Lage, partitionsübergreifende Datenträger anzulegen, die Resultate
jedoch sind zum OS/2-LVM nicht kompatibel. Zur Einsicht weiterer Details
über LVM empfehle ich die Seiten 13 und 53 der INSTALL.PDF im Verzeichnis
\books\pdf der eCS- und SWC-CDs. Das Dokument USINGLVM.PDF beschreibt die
grafische Oberfläche der LVMGUI. Mit dem Befehl "HELP LVM" läßt
sich zwar ein diesbezüglicher Hilfetext einsehen, aber dieser bedarf
für uns einfache Sterbliche noch einer Übersetzung. Einen guten
Artikel über LVM von Bob Eager finden Sie unter http://www.tavi.co.uk/os2pages/lvm.html.
Alex Taylor beschäftigt sich mit der Programmierung einer verbesserten
grafischen Oberfläche:
Wurden Ihre Platten einmal zu LVM-Datenträgern konvertiert, dann muß vom Einsatz anderer Partitionsverwaltungsprogramme (OS/2s FDISK, DOS/Windows FDISK, Partition Magic, Linux Partitionsverwaltungsprogramme etc.) dringend abgeraten werden, es sei denn, Sie wüßten ganz genau, was Sie tun. Es ist mit ihnen zwar möglich, Partitionen zu manipulieren, aber da sie die von LVM benötigten Spezialinformationen nicht an die etwaigen neuen Gegebenheiten anpassen, wird OS/2 nicht in der Lage sein, die dann geänderte Konfiguration zu erkennen. In einem solchen Fall wäre es nötig, die LVM-Informationen separat zu verändern, was ziemlich kompliziert werden kann (s. Overby, http://www.os2voice.org/VNL/past_issues/VNL1100H/vnewsf5.htm und Eager weiter oben).
Bei der Anpassung der Größe einer Partition auf einem LVM-System werden in Wirklichkeit Plattenpartitionen einem LVM-Laufwerk hinzugefügt oder von ihm entfernt, und nicht etwa physikalische Partitionen in ihrer Ausdehnung verändert. Mit JFS-Partitionen kann man dies sozusagen jederzeit machen. Sie können ein JFS-LVM-Laufwerk jederzeit um eine neue Partition (unformatiert oder JFS-formatiert) erweitern, ohne die darauf befindlichen Daten zu zerstören. Bei Partitionen jedoch, die mit HPFS oder FAT formatiert wurden, muß die Definition einer übergreifenden Partition beim Anlegen und vor dem Formatieren erfolgen, danach läßt sich hier nichts mehr verändern (s. die PDF-Dateien von IBM und den Artikel von Eager für Zusatzinformationen). Daher bedeutet die Größenänderung eines nicht-JFS-Lauferks eine Sicherung aller Daten auf dem betreffenden Laufwerk, das Einbringen der gewünschten Anpassungen mit LVM und ein anschließendes Zurückspielen der vorher gesicherten Daten. Übergreifende Partitionen werden nur von LVM-tauglichen OS/2 und eCS erkannt.
Laufwerk M: (Abb. 2) demonstriert die Möglichkeit, mit LVM Laufwerksbuchstaben frei zu vergeben. Mein System enthielt eine Menge Verweise auf Objekte auf den Laufwerken I: und J:, die auf D2 definiert waren. Durch die Zuordnung des Laufwerksbuchstabens M: zur letzten Partition auf D1 konnten diese Verweise unangetastet bleiben, was mir eine Menge potentiell gefährlicher Rekonfigurationsarbeit ersparte.
Nachdem alle Partitionen angelegt und formatiert worden waren, rief ich SYSINSTX x: für die beiden zukünftigen OS/2-Systempartitionen auf, um die notwendigen Systemdateien zu übertragen, und anschließend XCOPY x:\*.* y:\ /H /O /T /S/E /R /V zur Übertragung aller anderen Dateien und Verzeichnisse, wobei x die zu clonende OS/2-Partition bezeichnet und y: die Partition auf der neuen Platte. Abgesehen von dem dort wegfallenden SYSINSTX-Aufruf ist der Ablauf für alle weiteren Datenpartitionen identlisch.
Da LVM nur eine Bootmanager-Partition auf genau einer am System angeschlossenen
Platte zuläßt, mußte ich die 10GB-Platte abhängen,
die 40GB-Platte als D1 anschließen, von Diskette booten und "
Die Bootmanager-Partition muß nicht unbedingt die erste Partition auf einer Platte sein (s. Abb. 1), vielmehr kann sie sogar auf der zweiten Platte liegen. Sie muß allerdings in jedem Fall als primäre Partition definiert und zudem die einzige startfähige Partition im gesamten System sein.
Abb. 3: Physikalische Sicht von D1 in LVM.EXE (Befehlszeile), entspricht
dem Säulendiagramm aus Abb. 2; aufgezeichnet nach Installation von Linux
und Konvertierung des Laufwerks M: nach JFS. Die Darstellung entstammt einer
Montage zweier mit PMView eingefangener Bildschirme mittels PhotoTiger.
Im Laufe meiner Nachforschungen entstand auch eine Win98-Version des Ablaufs: den virtuellen Speicher abschalten und die Windows-Version von SYSINSTX gefolgt von der Windows-Version von XCOPY auf die neue Partition loslassen. Sie benötigen allerdings ausreichend konventionellen Speicher, um DOS (Win98) ohne Swapdatei betreiben zu können. Zunächst habe ich das Laufwerk unter OS/2 als FAT16 formatiert - Windows98 änderte dies auf VFAT, um die Verwendung langer Dateinamen ermöglichen zu können. Anschließend (wobei x: für die neue Partition steht): Windows vom bestehenden Laufwerk C: starten, SYS x: zur Erstellung der Systemdateien in einem DOS-Fenster aufrufen, in den Systemeinstellungen unter System->Leistungsmerkmale->Virtueller Arbeitsspeicher "Virtuellen Speicher deaktivieren" auswählen. An dieser Stelle wird Windows eine Warnung wegen möglicher Probleme beim Versuch, ohne virtuellen Speicher zu arbeiten, anzeigen, weshalb man genügend konventionellen Speicher benötigt. Anschließend das System durchstarten und mit Start->Ausführen XCOPY c:\*.* x:\ /c /e /f /h /r aufrufen. XCOPY muß mit Start->Ausführen angestoßen werden, denn nur so wird XCOPY32.EXE verwendet, welches mit langen Namen umgehen kann. Schalten Sie anschließend auf jeden Fall die virtuelle Speicherverwaltung wieder ein.
Bevor ich dies herausfand habe ich es mit XCOPY von OS/2 probiert, der auch zu funktionieren schien. Die resultierende W98-Partition bootete zunächast einige Male in den abgesicherten Modus, bevor sie normal hochfuhr. Jedes mal verkündete sie stolz, alle "neuen" Geräte gefunden zu haben, aber es gab keine Verknüpfungen mehr zu den vorher installierten Anwendungen.
Aufgrund der Windows-eigenen Abhängigkeit von der ersten aktiven primären Partition auf der ersten Platte bestand die Notwendigkeit, die 10GB-Platte zunächst als D1 anzuschließen und von dort aus zu booten, und sie dann auf die 40GB-Platte zu klonen, wobei die neue Win-Partition ihren Laufwerksbuchstaben automatisch zugeordnet bekam. Anschließend mußte die 10GB-Platte abgehängt, die 40GB-Platte als D1 angeschlossen und OS/2 gestartet werden, um sie per LVM in das BootManager-Menü aufzunehmen.
Die DOS 6.22-Partition auf der 10GB-Platte wurde nicht geklont, weil ich beabsichtigte, mit Linux (Red Hat 8.0) herumzuexperimentieren. Unter Linux existieren keine Laufwerksbuchstaben. Jede IDE-Partition wird mittels der Terminologie "/dev/hdln" identifiziert, wobei das I für die jeweilige Platte steht (D1 ist hda, D2 ist hdb usw. ) und n für die Nummer der Partition auf der Platte I. /dev/sdyn bezeichnet SCSI-Platten, wobei y die SCSI-Plattennummer und n die Nummer der Partition auf Platte y darstellt. In gewisser Hinsicht stellt der LVM von OS/2 damit den goldenen Mittelweg zwischen FDISK und der Linux-Welt ohne Laufwerksbuchstaben dar. LVM verwaltet die Partitionen ohne Laufwerksbuchstaben, stellt sie aber zur Verfügung, weil OS/2 sie benötigt, damit es laufen kann.
Die meisten oder gar alle verfügbaren Linux-Distributionen verlangen, daß ihr /boot-Verzeichnis unterhalb der 1024-Zylindergrenze der ersten oder zweiten Platte liegt, es sei denn, das BIOS Ihrer Hauptplatine verfügt über die sog. LBA32-Erweiterung (die meisten BIOSse, die nach 1994 auf den Markt kamen, verfügen über diese Einrichtung; sollten Sie sich jedoch nicht sicher sein, dann können Sie es mit einem kleinen, von Bob Eager geschriebenen, Programm herausfinden, welches hier http://www.tavi.co.uk/os2pages/extdisk.html zu finden ist.) Diese Einschränkung hat dazu geführt, daß ich DOS 6.22 von der 40GB-Platte verbannen mußte (dachte ich jedenfalls, weil ich im Zusammenhang mit Linux mit den Anforderungen "unterhalb der 1024-Zylinder-Barierre" und "Primäre Partition" durcheinander kam). Wenn Sie einer Multisystemumgebung, die ein LVM-taugliches OS/2 beinhaltet, ein Linux hinzufügen, dann achten Sie darauf, daß die Partitionsverwaltungsprogramme von Linux keine Veränderungen am MBR vornehmen (oder anders ausgedrückt: verwenden Sie sie nicht), und legen sie das Systemstartprogramm (GRUB, LILO usw.) in das Linux-/root-Verzeichnis. Anderenfalls könnte der MBR bis zu einem Punkt zerstört werden, an dem LVM und der BootManager nicht mehr damit klarkommen, was ernste Probleme für OS/2 zur Folge hätte. Nach dem Hinzufügen zum BootManager-Menue erscheint bei RH 8.0 kein Laufwerksbuchstabe, weil dort keiner verwendet wird.
Der LVM-taugliche BootManager versteckt primäre startbare Partitionen ein wenig anders als seine Vorgänger. Beim alten BootManager mußte man lediglich eines der vorhandenen, auf einer primären Partition befindlichen Systeme zum Starten auswählen, und alle übrigen primären Partitionen wurden automatisch versteckt. Beim neuen BootManager ist das nicht der Fall, deshalb muß man bei Systemen, die die vom LVM verteilten Laufwerksbuchstaben nicht erkennen, mit einem Programm wie DFSee oder AirBoot zur Bearbeitung von Partitionstabellen dafür sorgen, daß die jeweils zu startende C:-Partition aktiv ist und die unbenutzten anders eingerichtet sind. Für OS/2 darf es nur eine Partition pro Laufwerksbuchstabe geben, und nicht etwa ein aktives Laufwerk C: und daneben ein verstecktes. Um eine spezielle Partition als C: anzusprechen muß man folgerichtig die Zuordnung der Laufwerksbuchstaben anpassen (also C: von einer Partition entfernen und einer anderen zuordnen).
Als ich Warp 4.52 installierte, war die DOS 6.22-Partition zufällig gerade aktiv, was dazu führte, daß OS/2 die erste Win98-Partition niemals finden konnte (selbst wenn ich Windows98 startete, wieder herunterfuhr und anschließend sofort OS/2 startete). Um dem abzuhelfen mußte ich die Zuordnung des Buchstabens C: zur DOS-Partition auflösen und der ersten Windows-Partition geben. LVM weigerte sich, das zu erledigen (erneut diese Fehler bei den Partitionsgrenzen), deshalb mußte DFSee im fdisk-Modus mit folgenden Befehlen eingesetzt werden:
-w+ -Q lvmset -B 1 -l- #lvmset -B 2 -l:C
was im Kern bedeutet "schalte den Fenstermodus ein, beende dich selbst nach erfolgreicher Ausführung des allerletzten Befehls, lösche den Laufwerksbuchstaben der ersten Partition auf Platte 1, und der nächste Befehl lautet: Setze den Laufwerksbuchstaben C: für Partition 2 auf Platte 1". Danach konnte OS/2 die Windows-Partition erkennen, die von DOS jedoch nicht mehr. Um die DOS-Partition wieder sichtbar zu machen müßte die obige Befehlssequenz erneut ausgeführt werden, allerdings so verändert, daß das C: von der zweiten Partition entfernt und der ersten zugeordnet wird.
Etwas mühsam, wenn man die alte Vorgehensweise gewöhnt ist, aber wegen der neuen Methoden zum Verstecken und Anzeigen von Partitionen bzw. der manuellen Vergabe von Laufwerksbuchstaben absolut unvermeidlich.
Ich kann DFSee an dieser Stelle nur empfehlen. Schließlich habe ich es, nachdem ich es mir die Jahre über immer wieder angesehen und von seiner Komplexität einigermaßen verwirrt wurde, doch lizensiert. Das Produkt beinhaltet eine erstklassige technische Unterstützung. Seien Sie allerdings sehr vorsichtig bei seiner Anwendung; obwohl es einem in kniffligen Situationen den Tag retten kann, lassen sich damit auch versehentlich Änderungen durchführen, die unweigerlich zur Katastrophe führen.
Alle Systemstartpartitionen funktionieren nun genauso wie vorher auf der 10GB-Platte - Hintergrundbilder, Anwendungen, Referenzen (und Verknüpfungen) und auch alles andere. Die 10-GB-Platte ist nun die IDE0 in einer weiteren Maschine, die ich mir für Hardware- und Konfigurationstests aufgebaut habe.
Nachdem alles wieder funktionierte, habe ich Laufwerk M: sowie alle Partitionen auf D2 nach JFS konvertiert und erweiterte Plattenlaufwerke über jeweils zwei Partitionen definiert, um die Anzahl von Laufwerksbuchstaben meines Systems im Vorgriff auf die Installation eines häuslichen Netzwerks zu reduzieren. Abb. 4 zeigt die LVMGUI-Sicht nach dieser erneuten Rekonfiguration, und in Abb. 5 sehen Sie die Logische Sicht des LVM.
Abb. 4. Ansicht in LVMGUI nach erneuter Rekonfiguration
mit erweiterten LVM-Plattenlaufwerken I: und J:, wobei I: die ersten beiden
Partitionen von D2 umfaßt und J: die letzte Partition auf D1 sowie
die letzten beiden Partitionen auf D2. Die Detailanzeige am unteren Ende des
Fensters richtet sich danach, welche Partition gerade ausgewählt ist
(im Beispiel die letzte Partition auf D1). D4 ist mein SCSI-ZIP 100.
Abb. 5, äquivalente Darstellung aus der logischen Ansicht
im LVM.EXE, wobei gerade D1 mit Laufwerk J: selektiert ist. Der obere Kasten
enstpricht dem Säulendiagramm aus Abb. 4, und der untere Kasten der
Detailanzeige aus LVMGUI.
Die einzige mir bekannte LVM-taugliche Alternative zum BootManager ist AirBoot, ein Netlabs-Projekt: http://air-boot.netlabs.org/ Daneben habe ich manche Internetseiten über BootManager gefunden, wo behauptet wird, sie könnten jedes beliebige System von jeder beliebigen Partition aus starten. Ein Produkt dieser Gattung, V-Coms System Commander, habe ich vor einigen Jahren einmal ausprobiert und als recht umständlich empfunden. Bei der Mehrheit dieser Programme wird OS/2 jedoch nicht erwähnt, und falls doch, kein Wort über ein LVM-taugliches OS/2. Da der OS/2-Bootmanager meine Bedürfnisse deckt, habe ich (noch) keine anderen getestet.
Nachdem ich mich durch die ganze Sache gewühlt hatte, und dabei die 10GB- und die 40GB-Platte mehrmals als D1 und D2 und umgekehrt anschließen mußte, bevor ich ein recht gutes Verständnis für die Nutzung von LVM sowie die korrekte Reihenfolge aller Schritte entwickeln konnte, möchte ich Ihnen die folgenden Ratschläge ans Herz legen (achten Sie dabei auf jeden Fall darauf, daß Sie Ihren Rechner ausgeschaltet und vom Strom getrennt haben, bevor Sie Ihre Platten abziehen oder anschließen):
Nun sollte alles betriebsbereit sein.
Alle Bildschirmanzeigen wurden mit PMView eingefangen und mit PhotoTiger aufbereitet.
Boot-Manager-Hinweis - Vor v4.50 mußte die primäre Partition des Boot-Managers auf D1 liegen.
LBA32-Erweiterung - Ein weiterer Name für die Interrupt-13-Erweiterung des BIOS, die oft auch als int13x geschrieben und mit I13x abgekürzt wird.
Daten und Quellen:
|
[Artikelverzeichnis]
editor@os2voice.org
[Vorherige Seite] [Inhaltsverzeichnis] [Nächste Seite]
VOICE Homepage: http://de.os2voice.org