Bis hierher wurde innerhalb des grlm Rescue-Systems eine "VM", also eine virtuelle Maschine, bei debian auch "KVM" genannt, im RAM erzeugt und betriebsfertig für den Zugriff mit dem VNC Client vorbereitet. (Achtung: die Instanz des VNC ist jetzt ":0"). Das alles wurde auf der vorherigen Seite beschrieben. Jetzt gehts hier weiter.
.

In "virtuellen maschinen" wird die Netzwerkverbindung natürlich nicht auf den physikalischen Realtek Netzwerk-Chip geleitet, sondern auf die Virtualisierungs-Ebene mit einem virtuellen Intel Alibi-Chip. Startet man später solch eine (VM-) Installation direkt von der Platte, kommt man nie wieder von draußen dauf. Und an die Konsole kann man nur seltenst dran. Das opensuse System läuft vermutlich hoch, hat aber keine Netzwerkverbindung und ist damit tot.

Ich benutze diese autoyast Installtion nur, um die beiden Platten sauber als RAID1 nach meiner Vorlage zu konfigurieren.
.
Später muß ich das auf meinem Musterserver vorbereitete Partitions-Image auf /boot und auf root (/) übertragen.
.

(7) Die neue "KVM" ist nun gestartet, und damit Sie die Installation des gewünschten Betriebssystems vornehmen können, verbinden Sie sich nun via VNC zu Ihrem Server. - Sie sollten nun in der Lage sein, die opensuse Installation via VNC auf grafischer Basis durchzuführen.

(8) Es funktioniert - die opensuse 13.2 Konfiguration (samt Konfiguration der RAID1 Platten) verläuft im Fenster des VNC Clients genau wie an der physikalischen Konsole des lokalen Servers und wird (hier - kommt noch) gesondert beschrieben.

Die gesamte opensuse 13.2 Installation erfolgt über eine temporäre DHCP Netzwerk-Adress-Konfiguration. Das kann so aber nicht bleiben.

(9) Um im Anschluss die Netzwerk Konfiguration aufzusetzen, fahren Sie den neu installierten Server per KVM - also den soeben benutzten virtuellen Server innerhalb der VNC-Verbindung (also nicht den eigentlichen debian rescue Host-Server an sich) herunter.

(10) Wie Sie die lokalen RAID1 Partitionen mounten, (steht bald hier).

(11) an (mindestens) 4 Konfigurations-Dateien müssen sie die Einträge kontrollieren bzw. ergänzen: (aus DHCP mache static IP)

(a) /etc/sysconfig/network/ifcfg-br0
(b) /etc/sysconfig/network/ifcfg-enp63s0 (dieser Name ist nicht überall gleich)
(c) /etc/hosts
(d) /etc/resolv.conf
(e) die Firewall-Konfig Kontrolle in /etc/sysconfig/ hatte ich vergessen

(und darum : Muster Beispiele kommen noch)

SORRY, das hat so nicht funktioniert, die Platten müssenohen UUID erkant werden. Da stimmt etwas beim Bootloader nicht.


(12) Anschließend sollte es möglich sein, den Server mit dem installierten opensuse System von der Festplatte "normal" zu booten. Deaktivieren Sie dazu den Rescue Modus - warten Sie einige Minuten und lösen Sie dann einen Neustart aus.

Bitte beachten Sie, dass diese Vorgehensweise nicht für alle Betriebssysteme in Frage kommt, besonders bei Virtualisierungs-Systemen wie VMware wird es wahrscheinlich nicht funktionieren.

Wichtig :
Da der opensuse Server (auf der Festplatte) innerhalb einer virtuellen Maschine installiert wurde, können Sie mit dieser laufenden Version keine weiteren virtuellen Gäste installieren. Diese VM (oder KVM) muss beendet werden und der Rescue Modus muss ebenfalls beendet werden und der physikalische Server muss von Grund auf von der Platte neu gebootet werden.

Haben Sie sich mit der korrigierten Netzwerk-Config vertan, gibts nur den Weg zurück über den Rescue-Modus und Nachbessern ist dann angesagt.
.

Es hatte jetzt 2 mal geklappt, ein opensuse 13.2 -NET Image zu installieren. Jetzt muss es nur noch problemlos von der Platte booten.

Wichtig : Nach dem Verlassen der virtuellen KVM Maschine, in der die Installation des Images erfolgte, soll oder muß ein "reboot" erfolgen, wegen der neu zugeordneten bzw. geänderten Partitionen auf der Festplatte. - Dann die Netzwerk-Konfig von der geretteten Version benutzen - so die Theorie.
.

Nach vielen Versuchen, eine eigene opensuse 13.2 Varaiante vorzubereiten und dann die neue direkte Boot-Version auf der Platte (also ohne Debian als KVM-Basis) zu korrigieren, ist mangels Wissen gescheitert.

Denn ich hatte die UUIDs der unterschiedlichen logischen RAID 1 Partitionen nicht bedacht. So findet der Boot-Loader, sofern er überhauppt gestartet wird, die eigentliche Linux Platte nicht. Mangels Konsole bzw. Fernkonsole sieht man das aber nicht, erst später im Rescue-Modus und mounten der Linux-Partition in den Log-Dateien ist das ersichtlich.

Wie es alternativ dennoch bzw. besser geht , kommt auf einer anderen Seite.
.