Sie sind hier: Zentrale | Server-Einrichtung | Suse-Linux für Heimserver - zweiter Versuch  Harry Boeck - Heimserver

Suse-Linux für Heimserver - zweiter Versuch

Hardware: VirtualBox auf meinem aktuellen Arbeitsplatzrechner von 2000, der immer noch gleichzeitig mein Heimserver ist.

Ziel der Eirichtung: Ein Serversystem mit minimalistischem GUI, aber angenehm leichter Wartung / Überwachung über's GUI (so, wie ich das von meinem bisherigen Server unter Windows 98 und Windows XP gewohnt war bzw. bin).

Warum in einer Virtualisierten Umgebung?

Ich habe zwar einen leistungsfähigen Zweitrechner neben dem nun schon als alt zu bezeichnenden Arbeitsplatzrechner zu stehen. Der ist aber eben weil er moderner und leistungsfähiger ist - und das übrigens NUR, weil sich eine gewisse Software (Elder Scrolls 4 - Oblivion) auf dem älteren nicht ausführen ließ - sehr viel leistungshungriger. Dessen Grafikkarte verbrät unter Last allein soviel wie Motherboard, CPU und Grafikkarte des älteren zusammen. Deshalb ist der bisher nur genau für dieses Spiel bzw. als Ausweichrechner bei Anwesenheit von Besuchern in Betrieb. Ansonsten steht er einsam und verlassen in der Ecke.

Da ich außerdem jede Menge negative Erfahrungen mit Linux-Installationen in den letzten reichlich 10 Jahren gesammelt hatte (immer war die Hardware entweder zu neu oder zu alt oder irgendwas wichtiges wie ein Modem fürs Internet ließ sich absolut nicht zur Funktion bringen - und ohne funktionierendes Internet ist sowas bei Linux echt eklig!...), besonders negative Erfahrung zudem mit dem letzten Versuch mit Suse Linux 10.1, andererseits aber schon gute Erfahrungen mit dem Einrichten von speziellen Linux-Systemen auf virtuellen Systemen (sowohl mit VMWare als auch mit VirtualBox), liegt es nahe, das Ganze mal richtig nahtlos mit ner virtuellen Umgebung innerhalb eines sicher funktionierenden Gastsystems zu probieren...

Festlegen der VirtualBox

Suse soll sich genau wie mein Windows mit seinem Systemkern auf einem relativ kleinen System-Datenträger einrichten und alle sonstigen Anwendungen auf einem Anwendungs-Datenträger ablegen. Ziel ist, das System genau wie beim Windows schnell mal sichern/restaurieren oder ganz gegen ein neues austauschen zu können, während die Anwendungen nach Möglichkeit vom Wechsel des Kerns nichts mitbekommen sollen und aus dem Stand sofort wieder lauffähig sein sollen. So daß ich eventuell auch mal Tests mit verschiedenen Linux-Distributionen bei nahezu gleicher Anwendungs-Umgebung machen kann...

Das Suse-Linux bekommt also einen "kleinen" System-Datenträger von 4 GB Größe. Das ist das doppelte dessen, was ich Windows XP zubillige, ist aber meinen früheren negativen Erfahrungen geschuldet, daß Desktop-Umgebungen unter Linux offenbar extreme Platzverschwender sind. Das letzte mal unter Suse Linux 10.1 hatte das System etwas von über 2 GB benötigtem Platz gemeckert, wenn ich Gnome und KDE mit zur Auswahl haben wollte.
Na ja: Daran soll'S jetzt nicht scheitern. Ist ja eh erstmal nur zum Spielen und Kennenlernen...

Dazu kommt Zugriff auf das DVD-ROM-Laufwerk, das Netzwerk und das Windows-Sound-System. Außerdem 256 MByte RAM (im Wirtssystem sind 512, und ich möchte, daß dieses auch noch benutzbar bleibt; ich gehe eh davon aus, daß ich das Wirtssystem wochenlang zur Problemklärung benutzen muß, ehe das Linux halbwegs ansprechend läuft...).

Ach ja: Die VirtualBox läuft natürlich unter eingeschränkten Rechten. Erstmal unter meinem eigenen Konto. Wenn das System mir irgendwann gefällt, regelmäßig über ein extra Konto, wo die VM nur noch auf ihre eigenen Daten zugreifen darf...

Grundinstallation

Die Grundinstallation beginnt mit einem Hänger: Nach Aufbau des grünen Startbildes mit dem sinnlos langsamen Einblenden des Willkommensgrußes hängt das Suse in der VirtualBox. Die VirtualBox zeigt 100% CPU-Auslastung. Nach 3 Minuten Anstands-Wartezeit starte ich die Box neu.

Danach meckert sie erstmal, daß sie nicht mehr auf die DVD-ROM zugreifen könne und sonst kein Bootmedium hätte.
Ein Blick rüber in den Dateimanager des Wirtssystems zeigt, daß die DVD-ROM sehr wohl noch da ist und navigiert werden kann.

Hmmm... - Da muß sich wohl irgendwo was verhakt haben...

Ich mache die VirtualBox komplett aus und neu an.
-> Siehe da: Es geht wieder!

Anschließend beschließe ich erstmal, diesen Bericht zu schreiben, denn so, wie es beim bloßen Booten von CD losgeht, wird es bestimmt wieder lustig...

Sprachauswahl: englich-us
Lizenz akzeptieren: natürlich.
Installationsart: Neuinstallation, OHNE "online-repositories" anzukreuzen!
Timezone: europa/germany
Desktop: KDE
Partitionierung:

swap-Partition: Nein, Danke: Ich habe ein virtuelles System. Bei dem wird der RAM bereits vom Wirtssystem verwaltet, ich benötige keine Swap-Partition, die ihrerseits nochmal über eine Swap-Partition des Wirtssystems geleitet wird. WENN ich dem Gastsystem mehr RAM zur Verfügung stellen möchte, baue ich RAM in der Virtuellen Maschine ein, keine doppelt-virtuelle Swap-Partition!
Wobei natürlich die momentan für mich nicht zu beantwortende Frage auftaucht, ob Linux überhaupt in der bloßen Lage ist, ohne Swapfile zu funktionieren.
Kurzer Abstecher zu Google (im Wirtssystem - wo sonst) zeigt: Ja, swapfreier Betrieb SOLL regelmäßig möglich sein, KANN aber auch zu Problemen führen. Das sei vom Kernel abhängig.
OK: Ich lasse mich überraschen...

Ein Abstecher aus reiner Neugier nach Novell zu den Systemanforderungen für Hardware bringt mich auf einen gewissen Boden von Tatsachen zurück:
Nach deren Darstellung ist Linux dermaßen wahnsinnig ressourcen-gefräßig, daß ich mit meiner virtuellen Maschine EIGENTLICH keine Chance haben dürfte, das Zeug überhaupt auszuführen.
Dabei frage ich mich immer wieder, wie die fertig konfigurierten Linuxe von den Live-CDs es mitsamt grafischer Oberfläche schaffen, selbst auf dermaßen alten Krücken wie meinem 1997er Rechner zu starten! Außerdem frage ich mich, wie es eine BOSS-CD schaffen kann, in eben genau einer solchen Virtuellen Maschine auf eben DIESEM PC flüssig zu laufen. In einer VM übrigens, die gegenüber der jetzt eingerichteten nochmals halbierte Datenträger-Ressourcen hat...

Irgendwas muß hier doch faul sein: Ist es die spezielle Suse-Compilation, die das Linux dermaßen jeden Rahmen sprengen und gegenüber Windows so absolut montrös aussehen läßt? Oder ist es einfach nur Größenwahn der Leute bei Novell, die jene Online-Dokumentation verfaßt haben?

Ich weigere mich einfach mal, diese Darstellung bei Novell zu glauben!
Live-CDs sind einfach ein zu starkes Argument gegen diese Übertreibung!

Daß dieser Punkt nicht ganz glaubwürdig ist, muß ja nicht heißen, daß der Rest der Online-Dokumentation nutzlos ist. Die c't, die ich neben mir zu liegen habe, enthält bezüglich der Installationsbeschreibung auch nichts weiter als genau so einen Bericht, wie ich ihn hier gerade verfasse: Nur die reine Erwähnung der tatsächlich beim Autor vorhanden gewesenen Bedingungen. Keinerlei allgemein Analyse oder gar Hilfestellung für Entscheidungen. DAS aber finde ich offenbar in der Online-Hilfe von Novell.

Ja, also: Eine "Logische Datenträgerverwaltung" möchte ich nicht dazwischengeschaltet haben. DAS macht ebenso wie die RAM-Verwaltung das Wirtssystem bzw. die VM-Verwaltung.

Das Suse-Linux schlägt vor, den von mir als Systemdatenträger vorgesehenen 4GB großen solchen mit nur einer 512 MB Swap-Partition zu belegen und die 16 GB des Anwendungs-Datenträgers auf eine System- und Home-Partition aufzuteilen.
Hmmm...: NEIN!
-> Ich wähle eine benutzerdefinierte Partitionierung...
Im nächsten Bildschirm muß ich nochmals dasselbe verlangen...

Dann kommt erstmal eine "Fehlermeldung", daß die Wurzel des Dateisystems noch nicht definiert sei...
Na ja: Das ist ja wohl weniger ein Fehler als ein erwünschter und explizit angeforderter Zustand, oder?

Gut: Ich könnte unten auf vier verschiedene Buttons klicken, aber ich gehe eine Wette ein, daß der oben zum Erzeugen der einzige ist, der mich momentan zum Ziel führt...
Es stehen effektiv 5 Dateisystem-Formate zur Auswahl (Swap und Fat fallen weg)...
-> Es ist wieder ein Ausflug über Google in das Weite Wilde Web notwendig... Was ist heutzutage angesagt? Was SOLLTE man wählen, wenn man ein auf Sicherheit ausgelegtes System aufbauen möchte (IRGENDWANN will ich ja durchaus Linux die Aufgabe des Servers übertragen)?

OK: Unter verschiedenen Google-Abfragen liegen immer wieder Diskussionen auf www.linux.com oben und hören sich relativ aktuell und interessant an. Unter anderem:
How to hide an entire filesystem
Filesystems-HOWTO
Das zu studieren kostet allerdings extra Stunden...
Zunächst schrumpft die Auswahl weiter um ext2 (zu alt, zu FAT-mäßig).
Die Lösung - eine Übersicht in kompakter Form für die zur Auswahl stehenden Optionen - bringt allerdings der Artikel "25.2 Major File Systems in Linux" in Novells Online-Dokumentation zum Suse Linux.

Damit reduziert sich die Entscheidung auf: Raiser oder XFS?
Hauptkriterien hier sind:
  • Binary Trees für "richtige" Verwaltung sortierter Listen
  • Journale für die Verbesserung der Sicherheit bei Stromausfällen
Deutlich weitergehende Infos sind allerdings bei Novell nicht zu finden. Aber mit der so reduzierten Auswahl kann ich ja nochmals Googeln...
www.namesys.com versus oss.sgi.com/projects/xfs...
Das Raiser-Filesystem macht auf mich den besseren Eindruck. Vor allem hinsichtlich der Behandlung vieler kleiner Dateien. Wobei ich mir bewußt bin, daß die Systeme in ständiger Weiterentwicklung befindlich sind und letztlich beide in ähnliche Richtungen entwickelt werden. Und daß ich noch keinen Einblick in den Programmcode genommen habe (was meine Sympathie nochmal komplett umkrempeln könnte...).

Ich wähle also Raiser!

Dann sehe ich allerdings gleich im anschließenden Dialog, daß das aktuelle Raiser 4 gar nicht zur Auswahl steht, sondern nur zwei 3er Versionen...
OK, dann muß ich wohl erstmal damit leben und später eventuell mal den Datenträger wechseln.
Für den Systemdatenträger wird "ordered writes" eingestellt, für den Bereich der Anwendungsdaten "writeback".
Tja, und bei der abschließenden Kontrolle fällt auf: Das "writeback" ist nicht angenomen worden. Erst nach nachträglichem Editieren wird es dauerhaft in den Einstellungen verewigt.
Außerdem stelle ich "mount by Label" ein. Damit ist das Gefühl näher am Gewohnten dran...

So, endlich (2 Stunden später - aber doch mit recht interessantem Inhalt) geht es weiter...

Als Keyboard Layout und Sprache ist noch Englisch-US eingestellt. Während ich gern englischen Original-Text präsentiert bekomme, lege ich doch Wert auf deutsche Tastatur...
In den Sprachen-Details stelle ich ein, daß der Administrator gleiche Sprach-Einstellungen wie ein normaler Nutzer haben soll (FALLS ich die noch irgendwo auf deutsch ändere).
Hmmmm... Daß das Tastaturlayout nicht unabhängig von der Sprache im GUI einstellbar sein soll, glaube ich jetzt erstmal nicht. Aber das ist, was mir im Installationsbildschirm angeboten wird. Und was ich ERSTMAL nicht weiter ändern kann...

So: Zur Software-Auswahl...

Ein Blick in die Details läßt mich schon wieder ahnen, daß ich das meiste davon nie anfassen werde und EIGENTLICH nicht auf dem System haben will... Es werden hauptsächlich Platzverbrater sein.
Ich lasse aber erstmal die Grundauswahl so, wie sie vorgegeben wurde - in der Hoffnung, so am ehesten zu einem funktionsfähigen System zu kommen...

Abschalten tue ich:
  • Multimedia
  • Büroprogramme
  • grafische Desktop-Effekte (die verabscheue ich)
  • Grafik
  • Spiele
  • RealPlayer, Flashplayer und ähnliches Multimedia-Zeug, was nicht dort eingeordnet ist
  • Datei- und Druckserver
Reinnehmen tue ich:
  • Netzwerkverwaltung
  • Acroread
  • Antivir
  • Apache
  • PHP
  • MySQL

...Tja, und beim Durcharbeiten der Software-Optionen passiert dann mal wieder der Schrecklichste vorstellbare Fall: Während ich beim Druckserver rechtsklicke und anweisen will, daß alle Einträge DIESER Liste (die im rechten Bildschirm Untereinträge hat) nicht installiert werden sollen (ohne den Punkt direkt zu verbieten), hat das TATSÄCHLICH eine ganz andere Bedeutung: Nämlich die Liste ganz links wird vollständig gelöscht!
Na toll! Damit stehe ich wieder am Anfang!
-> Also: Verlassen und Änderungen verwerfen!
-> Nochmal rein und alles durchhecheln...

Schließlich alles akzeptieren und weiter zur Installation...
Es kommt eine Meldung, daß die Festplatte hda1 nicht beschrieben werden könne.
Eine Möglichkeit zur Wiederholung (und damit zum Test, ob es vielleicht mit irgendwelchen mangelnden Zugriffsrechten zu tun haben könnte) ist im Suse-Installationsmanager nicht vorgesehen.

OK: Damit ist dieser erneute Versuch, Linux zu installieren erstmal wieder vollkommen ins Wasser gefallen...



Bis ich das nächste mal LUST kriege, dieses Martyrium zu wiederholen, wird wohl wieder etwas Zeit vergehen...

...Oder auch nicht (ein Tag später): Immerhin läuft das Zeug in einer VM. Ich werde also jetzt am laufenden Band Backup-Punkte der VM setzen! Gerade hier kommt der Sinn einer VM mal so richtig zum Tragen...
Ein Qualitätsmerkmal ist das allerdings fürs Suse Linux nicht! Etwas mehr Fehlertoleranz wäre dringend geboten. Ich versuche mich an Linux-Installationen jetzt seit reichlich 10 Jahren - etwa jedes Jahr ein Versuch. Und IMMER NOCH schafft es bisher JEDES Linux, irgendwo in der Installation zu versagen! SOGAR auf einer TOTAL standardisierten VM! Ich KANN mir nicht vorstellen, daß die paar Handgriffe, die ich hier zur Einrichtung gemacht habe, dermaßen einzigartig auf dieser Welt sind, daß NUR ICH immer wieder solche Hürden zu überwinden habe!

Gut, dann mal los...
10:25 Start.
10:29 Sprachauswahl.
10:30 Auswahl der Installationsart: Neuinstallation, diesmal aber MIT online-repositories, weil ich jetzt vorgewarnt bin von wegen nicht aktuellem Raiser...

Ich probiere es mit folgender Konfiguration (aufgrund der Beschreibung der VirtualBox):



...Tja, das produziert:



Was soll mir "no such process" zu "/sbin/ip" an dieser Stelle sagen?
Daß das Zeug noch nicht installiert ist?
Intelligenzbolzen, wer sich diese Installationsprozedur ausgedacht hat!
Jedenfalls liegt es NICHT an mangelnden Zugriffsrechten der VM: Procmon bestätigt, daß DIE alles machen kann, was sie will.

Ich habe jetzt keine Lust, stundenlang irgendwelche Foren abzugrasen, NUR um zu klären, wie ich eventuell während der Installation die Netzwerkfunktionalität erhalten könnte, was wiederum ja NUR dazu dienen soll, EVENTUELL die Raiser 4 - Treiber in das System einbinden zu können (wobei ich ernsthaft bezweifle, daß das überhaupt funktionieren kann - so, wie sich das jetzt schon wieder mit technischen Schwierigkeiten für Banalitäten wie das Netzwerk fortsetzt...).
Ich lasse den Punkt also gezwungenermaßen erstmal weg!

Sehr interessant übrigens nochmal ein Google mit 'linux distribution +"reiser4"':
Es GIBT Raiser 4 sehr wohl als Root-Filesystem! Sogar für die "stabilen" Kernels...
Andererseits sollte es auch später immer noch möglich sein, das Zeug nachzuinstallieren...

11:30 Dateisystem-Optionen (Partitionierung):
Die alten Einstellungen sind fast komplett verloren. Immerhin aber hatte die letzte Installationsprozedur schon mal beide Datenträger vom Prinzip her eingerichtet (womit AUCH feststeht, daß es KEINE Zugriffsprobleme auf Ebene des Wirtssystems oder der VM gab), so daß jetzt bei erstmal gelöscht werden sollen. Na gut.

Ich setze wieder Raiser an, mit "ordered writes" für System und "writeback" für Anwendungsdaten...

11:35 Auswahl der Software:
Wie letztes mal... Die Aktualisierung der Liste benötigt FÜR JEDEN KLICK etwa 2 Minuten! Zwischendurch wird's sogar ab und zu mal etwas schneller (bis runter auf 20 Sekunden pro Klick). Aber da ich jetzt schon weiß, was ich will, dürfte ich innerhalb einer Viertel- bis halben Stunde mit diesem Punkt durch sein...

Na ja... Da kommen wieder diese elendigen Abhängigkeitsbemeckerungen, von wegen daß alle möglichen Programme "sendmail" und solche Scherze benötigen würden, was wiederum elendige Schwänze von weiteren Abhängigkeiten nach sich zieht, die ich jetzt alle wieder einzeln zulassen muß! Wer in der Welt denkt sich SOLCHEN Schwachsinn aus?
-> Gezwungenermaßen lasse ich mal alle möglichen Module installieren, die auf diesem System MIT SICHERHEIT NIE zur Anwendung kommen werden, nur damit dieser Installer endlich weitergeht...

12:05 fertig mit der Software-Auswahl.

12:05 JETZT ist ein Backup-Punkt für die VM dran...
...was keine Minute dauert...

Dann: Installation!

Nicht rechtzeitig habe ich Procmon wieder aktiviert. Aber DIESMAL läuft die Formatierung von hda1 ohne Fehlermeldung durch... Oder?
Die einzigen verbotenen Zugriffe im Wirtssystem in diesen Minuten sind zwei Versuche MEINER FIREWALL-INSTANZ, AUF DEN APACHE-SERVER SCHREIBENDERWEISE ZUZUGREIFEN! NA HIER WIRD'S LUSTIG! SEIT WANN DENN SOWAS!?!
Das schaue ich mir noch genauer an...
Das hat allerdings erstmal nichts mit der Linux-Installation zu tun...

Der Fortschrittsbalken in der "Paketinstallation" erzählt mir etwas von 1,5 Stunden Wartezeit... OK: Das Zeug kann im Hintergrund vor sich hin dödeln...
Damit das System benutzbar bleibt, muß ich allerdings die Prozeßpriorität der VM auf "idle" runtersetzen.

Was macht in so einem Fall eigentlich ein durchschnittlicher Anwender?
Kaffe trinken und Zigaretten rauchen? Oder Spazierengehen? Einen Waldlauf machen? Haushalt in Ordnung bringen? Ein Buch lesen?
OK, nehme ich jetzt alles mal stückweise in Angriff...

Zwischendurch - 12:47



Na? Ist DAS nicht LUSTIG?!

Ich probiere mal spaßenshalber die Systeminformationen durch: Sieht alles OK aus.
Ich probiere spaßenshalber mal einen Start des installierten Systems: Das bewirkt offenbar ein Booten von CD.
Ich probiere im folgenden Installationsbildschirm eine Reparatur des installierten Systems: Das bewirkt schon wieder ein Booten von CD, diesmal beginnend mit dem grünen Begrüßungsbildschirm!
Anschließend ein Hänger mit "Booting from local disk..."

Ja, hmmm: Was soll mir DAS sagen?

-> Ich erstelle einfach mal noch einen Backup-Punkt für den außerordentlich unerwarteten Fall, daß mir doch noch ein Linuxer über den Weg läuft, der SOWAS kennt...
-> Dann wird der Punkt von unmittelbar nach Definition der Softwareausstattung wieder restauriert und fortgesetzt...
Hmmm... Die Restaurierung von vorher gesetzten Backup-Punkten kann unter der VirtualBox NICHT ohne Zerstörung aller folgenden Backup-Punkte ausgeführt werden?
Was soll DER QUATSCH denn jetzt?
-> Ich lege ein Backup vom Backup an, so daß ich jetzt eine weitere Suse-VM als Archiv zu liegen habe...
-> Dauert nochmal eine knappe Viertelstunde...

Zwischendurch stolpere ich in der Hilfe für die VirtualBox über einen kleinen Eintrag, der speziell auf ein Problem von Linux als Gastsystem von virtuellen Systemen eingeht (und das ist offenbar nicht auf VirtualBox beschränkt):
Wenn Linux versucht, eine Schreiboperation auf Datenträger auszuführen, die vom Wirtssystem nicht innerhalb eines relativ knappen (EIGENTLICH riesigen) Zeitraumes ausgeführt wird, reagiert es nicht mit einer eventuellen Fehlermeldung und optionalen Wiederholung des Versuchs, sondern schlicht mit einem Hänger (was nach meiner nahezu vollkommenen Unkenntnis dessen, was darunter nun wieder alles verstanden werden könnte, durchaus auf die beiden hier vorliegenden Fälle zutreffen könnte: Immerhin war das System in beiden Fällen mit umfangreichen (Gigabyteweisen) Schreiboperationen beschäftigt, wobei Windows durchaus extrem träge reagiert, wenn ich nicht gerade die Priorität der VM auf "idle" herabsetze. Was wiederum die Schlußfolgerung aufzwingt, daß es DANN dem Gastsystem genauso ergeht wie vorher meinem Wirts-Desktop: Nämlich extrem träge Reaktionen!

Leider war ich beim zweiten Absturz gerade mit Haushaltarbeit beschäftigt und hatte deshalb keinen Blick auf die wahrscheinlich zwischendurch aufgetaucht gewesene ursächliche Fehlermeldung werfen können. Ich nehme aber mal einfach an, daß sie ähnlich wie die vom ersten Fall gelagert gewesen sein dürfte... ("Meldung, daß die Festplatte hda1 nicht beschrieben werden könne")

Die VirtualBox-Hilfe meint, man solle ein Kommando VBoxManage setextradata "VBoxInternal/Devices/piix3ide/0/LUN#[x]/Config/FlushInterval" [b] absetzen...
-> Ich nehme mal an, daß es irgendwo im VirtualBox-Programm-Verzeichnis sowas gibt...? Ja!
Und für [x] und [b] sollen eingesetzt werden?
Aha: Nun: Der Cache des Windows ist momentan recht groß. Er umfaßt momentan rund 350 MB (bei 512 MB RAM). DAS könnte auch ein Grund sein, warum das ganze System so sehr träge wird, wenn die VM massenhaft Datenträgeroperationen ausführt: Da fühlt sich Windows eventuell veranlaßt, den RAM der VM zugunsten temporärer Zwischenspeicherung von Datenträger-Daten auszulagern?
Leider ist im Nachhinein im Procexp nicht mehr viel davon zu sehen, weil die VM ja dummerweise schon ausgeschaltet ist (damit ich ein konsistentes Backup vom Backup bekomme).

Ich nehme also mal einfach die Empfehlung aus der VM-Hilfe an, daß der Schreibcache auf 10 MB begrenzt wird. Außerdem nehme ich noch den Folgetip mit, daß "Responding to guest IDE flush requests" eingeschaltet wird...

VBoxManage.exe setextradata OpenSuse-10-3 "VBoxInternal/Devices/piix3ide/0/LUN#0/Config/FlushInterval" 10000000 VBoxManage.exe setextradata OpenSuse-10-3 "VBoxInternal/Devices/piix3ide/0/LUN#1/Config/FlushInterval" 10000000 VBoxManage.exe setextradata OpenSuse-10-3 "VBoxInternal/Devices/piix3ide/0/LUN#2/Config/FlushInterval" 10000000 VBoxManage.exe setextradata OpenSuse-10-3 "VBoxInternal/Devices/piix3ide/0/LUN#3/Config/FlushInterval" 10000000 VBoxManage.exe setextradata OpenSuse-10-3 "VBoxInternal/Devices/piix3ide/0/LUN#0/Config/IgnoreFlush" 0 VBoxManage.exe setextradata OpenSuse-10-3 "VBoxInternal/Devices/piix3ide/0/LUN#1/Config/IgnoreFlush" 0 VBoxManage.exe setextradata OpenSuse-10-3 "VBoxInternal/Devices/piix3ide/0/LUN#2/Config/IgnoreFlush" 0 VBoxManage.exe setextradata OpenSuse-10-3 "VBoxInternal/Devices/piix3ide/0/LUN#3/Config/IgnoreFlush" 0

Dann (???) eine Restauration des ersten Backup-Punktes... (oder muß ich etwa die Kommandos in Bezug auf den jeweiligen Snapshot ausühren??)
Das Restaurieren dauert allerdings länger: Das Kopieren läuft mit nur etwa 10 MB/s, wobei immerhin rund 6 GB zu restaurieren sind (sollte also 10 Minuten dauern...).

Dann anwerfen dieses Zustands...
Jetzt wird's NOCH lustiger:



Reproduzierbar...

Hängt das nun mit den oben abgegebenen Kommandos zusammen?
Oder wäre das sowieso zu erwarten gewesen?
Oder reichen hier irgendwelche Zugriffsrechte nicht aus?
Vor allem: Wird es nicht vielleicht schneller gehen, wenn ich nochmal die Stunde Installations-Definition über mich ergehen lasse?

Das Verwerfen des Sicherungspunktes und der Versuch, die VM ganz neu zu starten, schlägt ebenfalls fehl. Offenbar hängt das NICHT mit dem Sicherungspunkt zusammen.

Ich restauriere mal spaßenshalber das Backup vom Backup...
Und beseitige vorher die fehlerhafte VM...
So. Durch das Restaurieren ist aber die VM nicht wieder aufgetaucht.
Offenbar notiert sich die VirtualBox ihre VMs noch ganz woanders.
In der Registry? Habe ich wirklich Lust darauf, auch DIESEM Scheiß noch hinterherzulaufen?
-> Umbenennen. Schnell ne neue VM einführen...
-> Das Backup wieder zurück umbenennen...
-> Geht nicht: Zugriff verweigert!
-> Prüfung: Nein! Ich DARF! -> Irgendein Aas hat da noch die Finger dran!
-> Die VBoxSvc.exe läuft noch im Hintergrund!
Außerdem werden 20% der CPU durch andauernde Interrupts verbraten!
Außerdem reagiert das ganze System auf einmal stockend!
-> Ich schmeiße mal eben den Dienst raus!
-> Ändert nichts an der Situation.
-> Ich beende schrittweise alle anderen Prozesse...
-> Hilft alles nichts: Ich starte den Rechner neu...

So, jetzt geht's erstmal wieder...

Dafür empfängt mich die nächste Liebesbotschaft:

Machine UUID {97df4d47-8df3-4576-86b3-95f1b8c68389} in 'D:\Medien\vbox\OpenSuse-10-3\OpenSuse-10-3.xml' doesn't match its UUID {07058282-ca19-40ce-8b1d-87f573c3e066} in the registry file 'C:\Dokumente und Einstellungen\Harry\.VirtualBox\VirtualBox.xml'. Fehlercode: E_FAIL (0x80004005) Komponente: Machine Interface: IMachine {31f7169f-14da-4c55-8cb6-a3665186e35e}

Na toll! Die notieren sich also irgendwelche UUIDs, ja?
Wozu zum Teufel tun die das?!

Aber jetzt weiß ich wenigstens endlich, WO die diesen Scheiß notieren!
-> {97df4d47-8df3-4576-86b3-95f1b8c68389} in die 'C:\Dokumente und Einstellungen\Harry\.VirtualBox\VirtualBox.xml' übertragen...
-> OK, die Typen wehren sich mit Händen und Füßen...

Hard disk 'D:\Medien\vbox\Open-Suse-System.vdi' with UUID {c3a6ba19-7e48-4039-9dd2-35e5bdd0b8ad} is already attached to a machine with UUID {97df4d47-8df3-4576-86b3-95f1b8c68389} (see 'D:\Medien\vbox\OpenSuse-10-3\OpenSuse-10-3.xml'). Fehlercode: E_FAIL (0x80004005) Komponente: Machine Interface: IMachine {31f7169f-14da-4c55-8cb6-a3665186e35e}

OK, ich gebe auf: Das letzte Wort ist DAS allerdings nicht!

JETZT lege ich erstmal ein DRITTES Mal eine neue VM für das Suse Linux an.
Wenn DIESER Versuch auch scheitern sollte, ist Linux erstmal wieder abgeschrieben...
Sicherheitshalber statte ich sie mit etwas mehr RAM (1 GB) aus...

-> Neue VM gestartet...
-> JETZT sind erstmal wieder keine CDROM-Laufwerke mehr im Wirtssystem!!
Was soll DIESES Chaos schon wieder?! Ich WERDE WAHNSINNIG! Ich schmeiße gleich mit Bomben um mich!
-> Gerätemanager! Hardware! CDROMs! Neue Hardware suchen!
-> Das CDROM-Laufwerk muß erst noch mal kurz vom Strom getrennt werden, ehe es endlich wieder gefunden wird!
Man! Was kann sich da NOCH alles verhaken?!
Ist Linux wirklich DERMAßEN Hardware-feindlich?!

JETZT startet endlich wieder die VM...
...Nur, um gleich darauf wieder hängenzubleiben!
-> Das DVD-Laufwerk war in der Konfiguration schon wieder ausgenommen worden!
-> Wieder reingesetzt!
-> Neustart!
-> SCHEINT erstmal anzulaufen...

Nachdem das System schon wieder so unsagbar träge wird, fallen mir zwei Sachen ein:
  1. Die Kommandos von oben zur Konfiguration des IDE-Zugriffs müssen noch abgesetzt werden!
  2. Die Priorität der VM muß wieder runter!
Gut, dann nutze ich die Gelegenheit außerdem noch, um nochmal einen Test der Snapshot-Funktion zu machen und ein Backup anzulegen...

-> Snapshot anlegen, VM ausschalten, Snapshot wieder anschmeißen...
-> Das Restaurieren des Snapshots klappt IM MOMENT sehr wohl.
Allerdings kann man keinerlei Änderungen an den Hardwareeinstellungen vornehmen. Eventuell war das vorhin ja einer der Gründe, warum die Snapshots zum Absturz führten (die VBoxManage-Befehle hatte ich zwischendurch angesetzt)...

Ich beende die VM also nochmal (wobei ich den Snapshot verwerfe) und setze erstmal die Befehle zur IDE-Konfiguration ab...
@echo off pushd D:\Werkzeug\runtimes\vbox VBoxManage.exe setextradata OpenSuse-10-3 "VBoxInternal/Devices/piix3ide/0/LUN#0/Config/FlushInterval" 10000000 VBoxManage.exe setextradata OpenSuse-10-3 "VBoxInternal/Devices/piix3ide/0/LUN#1/Config/FlushInterval" 10000000 VBoxManage.exe setextradata OpenSuse-10-3 "VBoxInternal/Devices/piix3ide/0/LUN#0/Config/IgnoreFlush" 0 VBoxManage.exe setextradata OpenSuse-10-3 "VBoxInternal/Devices/piix3ide/0/LUN#1/Config/IgnoreFlush" 0 popd

...Aha, das ginge auch noch viel einfacher: Es kommen bloß die Zeilen...

<ExtraDataItem name="VBoxInternal/Devices/piix3ide/0/LUN#0/Config/FlushInterval" value="10000000"/> <ExtraDataItem name="VBoxInternal/Devices/piix3ide/0/LUN#1/Config/FlushInterval" value="10000000"/> <ExtraDataItem name="VBoxInternal/Devices/piix3ide/0/LUN#0/Config/IgnoreFlush" value="0"/> <ExtraDataItem name="VBoxInternal/Devices/piix3ide/0/LUN#1/Config/IgnoreFlush" value="0"/>

...in der "OpenSuse-10-3.xml" hinzu...
Na ja...

OK, zwischendurch beim Konfigurieren der neuen VM eine neue Erkenntnis:
Der RAM wird von der VM NICHT geswapped!
Man KANN zwar einer VM mehr RAM als physisch existent zuweisen. Der wird aber nicht auf den virtuellen RAM des Wirtssystems abgebildet, sondern "gelocked" im physischen Speicher vorrätig gehalten.
Warum machen diese Typen das? (Das Festnageln im physischen RAM)
Das ist doch SINNLOS!

Damit ist die Vorstellung von weiter oben, daß ich das Wirtssystem das Swapping erledigen lassen wollte, wohl für den Arsch!
Oder gibt es ähnlich wie für die Beeinflussung der Festplatten-Operationen noch irgendeine Möglichkeit, der VM diesen Schwachsinn abzugewöhnen?
-> Nein: Ich bin nicht der einzige, der diesen Standpunkt vertritt. Aber die Antworten von Seiten der Entwickler lauten auf "nicht so"...

-> Das ganze NOCHMAL. Zum VIERTEN!
-> Diesmal MIT einer Linux Swap-Partition...

Allgemein probiere ich jetzt (immerhin mache ich's nun schon zum x-ten mal hintereinander weg) auch mal die extra optionen auf den Installationsseiten durch. Und siehe da: Bei der Softwareauswahl ganz unten fällt mir ein kleines Kreuzchen ins Auge, das mich von der elendigen stundenlangen Warterei auf die Abhängigkeitsprüfungen befreit:
Einfach den Automatismus abschalten! Schon kann man dieses Konfigurationswerkzeug tatsächlich zur Konfiguration benutzen!

P.S.: Das nehme ich allerdings eventuell gleich wieder zurück: Durch das Entfernen jenen Häckchens sind auch Häckchen bei fast allen gewünschten Modulen verschwunden. Wenn das jetzt heißt, daß ich mich durch den gesamten Wald per Hand durcharbeiten müßte, fällt meine Entgeisterung gleich wieder auf das alte Niveau zurück...
Nein: Es funktioniert nach abschließendem Klick auf den "Prüfen"-Schalter...

Tja, und dann die Installation: Schon wieder hängt das System...
Der Mauszeiger klebt am Fensterrand fest, was an sich schon wieder genug aussagt.



-> Nach 5 Minuten: Abbruch. Das war der vierte Fehlschlag in Folge...

So, jetzt haben wir zwei neue Optionen: Beides werde ich jetzt berücksichtigen...

Download + Installation der Version 1.5.2 von VirtualBox...

Die neue Version verlangt beim ersten Start eine Online-Registrierung.
DIE aber stürzt auf meinem System - was immer ich auch probiere (egal, unter welchem Konto ich das Ding aufmache und was ich eintrage) - ab.



Fein! DAS ist Innovation!

Wenn ich den Registrierbildschirm wegklicke, kann ich das Ding dennoch benutzen. Allerdings kommt der Registrierbildschirm bei jedem Neustart der VM-Umgebung.

Ich beschließe zwischendurch, das Verhalten als Bug zu melden...
Das Bugreporting-Formular hat aber selbst auch nochmal einen Bug: Wenn man dort "Enter" drückt, um das Firmular abzuschicken, geht es einfach aus und man fällt auf die vorhergehende Seite zurück!

Gott, ist das innovativ!

So, jetzt reichts: Ich notiere jetzt den Bugreport erstmal hier, damit ich ihn per copy & paste in das Formular auf deren Webseite übernehmen kann...

registration dialog crashes
registration dialog crashes after submit. reproduceable system & environment: windows XP SP2 internet connection via modem/router firewall installed: comodo under user as well as admin account details: After pressing submit (whatever in the english version) on the registration dialog, independently from the settings of the firewall to let the vbox go through, independently from the start of the confirmation dialog (if automatically started on start of the vbox or via the help menu), the vbox starter application crashes. If the firewall is set to confirm the access of vbox, the crash occures only after the confirmation was given - independently from its decision to block or to let pass. After that, a message comes up from the confirmation dialog stating that no access was given or the connection refused - dependend from the decision on the side of the firewall. At the same time, on top of that message, the system dialog stating a crash of the vbox application occures while the application messagebox behind it is still responsive. After confirming the application crash dialog, the application shuts down.

-> JETZT funktioniert das Bugreport-Formular auf einmal...

Nach einer gewissen Anzahl von Registrierungsdialog-Einblendungen wird der Registrierungsdialog nicht mehr automatisch eingeblendet, ist aber noch im Hilfemenü greifbar. Nach einer weiteren gewissen Anzahl von Aufrufen über das Hilfe-Menü ist er auch dort disabled.
Ich gehe mal davon aus, daß er durch irgendein kleines Progrämmchen im Programmverzeichnis der VBox dargestellt wird...
Jetzt allerdings stört er mich erstmal nicht mehr und kann mir den Buckel runterrutschen!

Download von Ubuntu...

Das ist ein recht kompaktes Paket, das auf eine normale CD paßt...
Allerdings braucht das Ding immer noch eine halbe Ewigkeit zum Download. Dabei hat die Berliner Uni, von der ich es hole, einen echt starken Zugang. Mein DSL arbeitet erstmals in der Gegend seines Leistungssolls (rund 550 KByte/s alias rund 4.5 MBit/s - also auf 75% der Brutto-Rate).

Während dessen tritt der Browser in einen Download-Streik.
Ich muß nun leider erst den Abschluß des Downloads abwarten, bevor ich irgendwas neues mit dem Ding beginnen kann...
In der Zeit kann ich ja nochmal eine Suse-Installation mit der neuen VM-Umgebung im Hintergrund probieren...

Installationsversuch für OpenSuse 10.3 - zum Fünften

VirtualBox meckert beim Start unter meinem Benutzerkonto über seine eigene Unfähigkeit, ein Lock auf eine seiner Konfigurationsdateien setzen zu können...



Dabei stellt sich heraus, daß eine Serverinstanz noch im Hintergrund läuft, die sich festgefressen hat und nicht beendet werden kann...
-> Offenbar muß das System mal wieder zwingend neu gestartet werden.
-> DAS allerdings ist nicht möglich, solange das Ubuntu nicht runtergeladen ist, es sei denn, ich will das AUCH fehlschlagen lassen (weil der Browser kein richtiges Unterbrechen von Downloads gestattet...)!

Nach Neustart des Systems geht es erstmal wieder...
Übrigens ist der VBox-Service möglicherweise durchaus noch abschießbar, wenn er sofort nach einem Crash bzw. einem normalen Beenden der Verwaltungsoberfläche abgeschossen wird, nicht mehr jedoch, wenn nach einem solchen Crash eine weitere Instanz der Oberfläche bereits gestartet wurde. Ich vermute mal einen Fehler in einem Referenzzähler...

Ich versuche mal, ein Netzwerkadapter im Bridgemodus aufzusetzen:
  • Es wird ein Hilfprogramm gestartet, welches allerdings nur mit Administratorrechten funktionieren kann:
    D:\Werkzeug\runtimes\vbox\VBoxSVC.exe /Helper VirtualBox\SVCHelper\{7bb3ee5e-0eb9-441e-8804-be95804e72fa}
  • Anschließend habe ich einen neuen Netzwerkadapter im Hostsystem, den ich ganz wie üblich konfigurieren kann.
    Leider verlangt das Windows jetzt nach einem Neustart. Es ist nicht bereit, den Netzwerkadapter so ohne weiteres als konfiguriert anzusehen...
    ...
    Hmmm... Nach einem Systemneustart ist der Netzwerkadapter aber immer noch nicht funktionsfähig...

    ...Das ist OK so und offenbar so gedacht: Er gehört zum Gastsystem und wird aktiv, sobald der Gast eingeschaltet wird.

    Das ist zwar ein bißchen gewöhnungsbedürftig, alldieweil ja sonst NIE irgendein Gerät eines ANDEREN Rechners mitten unter den Geräten des EIGENEN Systems angezeigt wird, da aber das Gastsystem ein Kind des Wirts ist, erscheint das noch nicht mal philosophisch daneben, sondern ganz passend. Und irgendwie glaube ich mich zu erinnern, daß das bei VMWare auch nicht viel anders war...

    Eventuell könnte die Darstellung dieses Zusammenhangs einen kleinen Platz in der Online- wie der mitgelieferten Hilfe finden. Ansonsten ist das vollkommen OK.

    P.S.: Daß der Adapter abhängig vom Client als "verkabelt" dargestellt wird, ist konfigurierbar: In den Hardware-Einstellungen unter "Erweitert/Media Status".

Software-Auswahl wie schon tausendmal geschehen...
Snapshot genommen - wie schon mal geschehen...
Installation gestartet - wie schon mal geschehen...
Einrichtung der Datenträger: läuft durch - wie schon mal geschehen...
Installation der Software: mal sehn, wann sie diesmal hängen bleibt...
Ich nehme jetzt zwischendurch einfach immer wieder mal einen Snapshot...
Nächster Snapshot bei 50% Abarbeitung...

-> Das System ist hart ausgelastet: Der Nachtrag einer Zeile im Editor wird von etlichen Sekunden Swapping begleitet...

Nächster Snapshot bei 90% Abarbeitung...

Was mir so nebenbei aufällt: Im Prozeßmonitor haben die VM-Module eine nur lapidare Größe an RAM gemeldet. (Nicht mal die "virtual size" liegt signifikant über der anderer Module.) In der System-Gesamtübersicht steht aber etwas von knap 700 MB vergebenem Speicher, während der Cache außergewöhnlich klein geworden ist (knapp über 100 MB). Das ist doch irgendwo nicht so ganz konsistent, oder?

...Inzwischen startet das Linux selbständig neu...

ICH BIN DRIN! (im Konfigurationsabschnitt... - um die Freude etwas zu dämpfen...)

Es ist 23:20 - Es sind seit Freitag abend (gegen 20 Uhr hatte ich angefangen, wenn ich mich recht entsinne) rund 27,4 Stunden vergangen, bevor das Linux zum ersten Login-Bildschirm kam!
Gut - abzüglich einer Schlafphase zwischendurch.

JETZT beginnt erst die eigentliche Inbetriebnahme. BISHER ging es ja NUR um das Aufspielen von Dateien. Und ein bißchen Grundkonfiguration von Hardware.

Was meinen Sympathie-Level gleich wieder ein wenig anhebt, ist das Angebot von Blowfish-Verschlüsselung statt einfacher Hashes für Passwörter. Sinnvoll.

Netzwerkkonfiguration:

Das Suse Linux verhält sich hier ähnlich einem Windows: Ungefragt wird ein DHCP-System vorausgesetzt - und im selben Atemzug ungefragt ein eigener DHCP-Server aufgesetzt.

Ich kann mich GANZ KLAR erinnern, WEDER DHCP NOCH DNS NOCH irgendeinen anderen ungebetenen Netzwerkdienst in der Software-Auswahl zugelassen zu haben.
Dennoch werden alle diese Dinge vollkommen frech und frei eingesetzt! Daß sowas eventuell ein existierendes System BEEINTRÄCHTIGEN könnte, darauf kommt wohl keiner bei Suse?
BEI MIR hat das dazu geführt, daß der Netzwerkadapter, der in der ERSTEN Phase der Installation noch korrekt funktionierte, JETZT schon wieder als "nicht mehr verbunden" angezeigt wird.


Eine lustige Einlage: Konfiguration der Firewall....

Erlaubte Dienste:

"Firewall vor interner Zone schützen"...

Eine Firewall schützen? Sollte das nicht ANDERSRUM funktionieren?
WER soll hier WAS vor WEM schützen?

Ausführliches Googeln und Studieren mehrerer Foren bringt nach einer Ewigkeit von Zeitinvestition ans Licht: Das ist nur ein schlechter Scherz von einem Eindeutscher gewesen, der wahrscheinlich gar kein Deutscher war und diesen Term schon vor Jahren mal irgendwann geprägt hatte, der dann nie wieder geändert wurde...

TATSÄCHLICH geht es hier darum, die Firewall für das LAN einzuschalten oder eben nicht (Häckchen heißt: eingeschaltet, also Portfilterung aktiv, für Bereiche wie 192.168.x.x)...

Eine Stunde für eine absolut lächerliche Nebensächlichkeit!
Nur um rauszukriegen, daß da mal jemand Schwachsinn kreiert hatte...

Gut: Die Dienste HTTP(S) und SSH sind zuzulassen!

Toll ist diese Firewall aber nicht: Keine Verknüpfung mit Programmen: Welches Programm auch immer beschließt, die betreffenden Ports zu belegen, wird hier durchgelassen. In den hier genannten Fällen ist das erstmal nicht weiter wild, weil die drei Ports von genau zwei Programmen beim Systemstart eh fest belegt werden. Aber im allgemeinen für eine ganze Reihe von Schnittstellen, die abwechselnd von verschiedenen Programmen benutzt werden dürfen sollen, von anderen aber eben nicht benutzt werden dürfen sollen, geht hier nichts zu konfigurieren.

Für State-of-the-Art halte ich hier immer noch die Kerio Personal Firewall, die es aber wohl für Linux nicht geben wird, oder?

Masquerading

benötige ich erstmal nicht.

Broadcast

Nach einer weiteren Stunde Googeln und Studium einer riesigen Dokumentation im PDF-Format, die sich laut Auskunft EIGENTLICH mit der Installation von Suse Linux beschäftigen soll und daher die Erläuterung der Bedeutung der Terme in den Konfigurationsdialogen von Suse Linux enthalten müßte, tatsächlich aber nur Schnulli wie allgemeine Betrachtungen zu den Vorteilen von IPV6 gegenüber IPV4 enthält, stelle ich abschließend fest, daß ich ABSOLUT NULL, NICHTS, NIENTE, ZERO Dokumentation dazu finde, WAS in diesen drei Boxen der Firewall-Konfiguration eingetragen werden sollen könnte.

IPSec-Unterstützung

Noch so ein Witz: Die FIREWALL wird wohl die letzte Instanz sein, die eine IPSec-Unterstützung für das System bereitstellt!
WAS HIER TATSÄCHLICH gemeint sein könnte - ob etwa mit der "Aktivierung" EEEEEine Unterdrückung und ohne KKKKKKeine solche oder mit "Aktivierung" ein Durchlassen von IPSec-Paketen und ohne KKKKKKein solches oder weiß Gott was gemeint sein KKKKKÖNNNNNTE, steht irgendwo, aber nicht in den Sternen dieser Nacht...

GOTT! Laß Hirn regnen auf diese Linux-GUI-Entwickler!

...Den Rest erspare ich mir...

Der Netzwerktest fällt dennoch negativ aus.
Es kommen keine Daten im Wirtssystem an.
Ein Ping vom Wirtssystem auf den dort zu sehenden Adapter ist positiv. Andersrum kann ich es noch nicht durchführen. (Ich wüßte noch nicht, wie...)

Hardwarekonfiguration:

Hier habe ich noch den Bildschirm eingestellt, falls ich demnächst auf die Idee kommen sollte, das Linux im Vollbildmodus zu benutzen. Und jenes dann eventuell auf die Idee kommen sollte, hier selbst die Bildwiederholrate bestimmen zu wollen.
An der Grafikkarte kann man ja offenbar nichts einstellen.
Die Farbtiefe habe ich auf 24 bit erhöht. Das SOLLTE eigentlich auch in Ordnung sein.

Als es schließlich an den Reboot des fertigen Systems geht, empfängt mich ein schon seit Jahren vertrauter Bildschirm (den kenne ich von meinem 1997er Rechner):



Jede weitere Eingabe (z.B. ein Tip auf "Y" (von der Schaltfläche "Yes", auf der der Cursor zunächst zu stehen scheint)) führt dazu, daß eine "login"-Kommandozeile erscheint und meckert.
Dort KANN ich mich zwar einloggen, lande aber auf der Konsole, die mir nun ungefähr genauso viel nützlich ist wie eine DOS Box aus dem Jahre 1990.

Möglicherweise gibt's irgendwo Leute, die schon mal ähnlches erlebt haben... (Ich KANN einfach nicht glauben, daß ich der EINZIGE Mensch auf dieser Welt sein soll, dem SOWAS aber mit 100 prozentiger Wahrscheinlichkeit IMMER passiert!)

JETZT ist aber erstmal Schluß!
Bis ich das nächste Mal Lust habe...


...Was eventuell soeben der Fall ist (ein Tag später...)

Zum Katastrophen-Bild zum Schluß:

Es sind 4-Pixel-Farbstreifen zu sehen.
-> Könnte es sein, daß das, was auch immer als Grafiktreiber von Linux verwendet wird, einfach einen Programmierfehler hat und seine Sache nicht vollständig zu Ende gebracht hat, sondern einen halbfertigen Zustand hinterließ?

Irgendwann ganz zu Anfang kurz nach dem grünen Begrüßungsbildschirm der Startprozedur der Installations-CD kommt eine Warnung, die dringend emnpfielt, die Farbauflösung heraufzusetzen, weil die vorgefundene Grafikkarte mit einer 32-Bit-Auflösung arbeite, der momentan verwendete Treiber aber nur eine 16-Bit-Auflösung verwende.
Später bei der abschließenden Hardwarekonfiguration der Installationsprozedur hatte ich aber keinen 32-Bit-Modus auswählen können, sondern nur 8, 16 oder 24 Bit. Davon hatte ich die höchstmögliche genommen.
So wie jetzt die Farbstreifen aussehen, könnten sie ohne weiteres darauf hindeuten, daß hier jemand auf der einen Seite 32 bit, auf der anderen 24 bit benutzt...

Schauen wir uns doch mal die Farbwerte an (in Gimp oder Paintshop im laufenden Windows des Wirtes)...
Eine Periode besteht aus: "00aa00000000aa00aaaa0000".
Das sind 12 Byte. Die teilen sich auf auf 4 Pixel des Bildes: "00aa00 000000 aa00aa aa0000".
Sie sind aber möglicherweise für 3 Pixel gemeint gewesen?: "00aa0000 0000aa00 aaaa0000".
Nein, sieht erstmal auch nur nach Farbstreifen aus.

Dennoch liegt die Vermutung nahe, daß genau hier was schiefgelaufen ist.

Ich versuche mal, einen Weg zu finden, diese Farbeinstellung nochmal zu ändern. Irgendwann war mir doch schon mal ein Angebot zur Reparatur oder gar zur Änderung der Installation über den Weg gelaufen...

-> Erstmal die Option "Repair installed System" im grünen Begrüßungsbildschirm...
-> Lustig ist das Leben...



(Ich war zwischendurch wieder mal mit anderen Sachen beschäftigt, um nicht meinen letzten freien Tag an diesem Wochenende mit Däumchendrehen vor einem wirklich eklig langweiligen Linux-Installations-Bildschirm vergeuden zu müssen, kann also zum genauen Umstand der Erzeugung dieses tollen Ergusses nichts sagen...)

Gut, SO also offenbar nicht...

Ich versuche eine "Installation" im grünen Begrüßungsbildschirm...
...Nein: Da geht eine komplette Neuinstallation ab, oder?...
Ja, leider nur diese Option oder irgendwelcher Schnulli von wegen "Aktualisieren"...

Gut: Ich stelle also den letzten Sicherungspunkt der VM wieder her...
Ahhhh ja: Das funktioniert spaßenshalber jetzt mal...
Wir sind bei etwa 90% der Software-Installation angelangt gewesen...
Mein Sympathie-Level für die VM klettert gleich wieder ein ganzes Stück in die Höhe...

Der nächste Snapshot kommt unmittelbar nach Abschluß der Softwareinstallation...
Dann einer unmittelbar zu Beginn der Konfiguration...
Schade, daß man nicht mehr benötigte Backup-Punkte nicht einfach so wegwerfen kann...

Netzwerkeinstellung genau wie oben...
(außer, daß ich mir diesmal stundenlanges Suchen im Netz nach Erklärungen, was was zu bedeuten haben könnte, ersparen kann... - DAS sollte in einem GUTEN System der Standardfall sein! Linux ist noch weit davon entfernt!)

Aus irgendeinem Grunde klappt momentan die Netzwerkverbindung immer noch nicht...
Es kommen Pakete (sehr wenige, exakt insgesamt drei) aus der VM auf dem Netzwerkadapter des Wirts an, aber es gehen keine zurück.
Die Firewall des Wirts berichtet von keinen Blockungen...
Die drei Pakete sind auch viel zu wenige; sie gehören nicht zum Test im Linux: Dort wurden 18 Pakete abgeschickt.
Möglicherweise ist die Netzwerk-Konfiguration noch irgendwie anders gemeint?
Schön wäre es, wenn die Meinung der VBox-Erzeuger irgendwo anständig erklärt wäre. Allerdings habe ich bislang außer Diskussionen in Foren noch nichts dazu gefunden...
Ich versuche es noch einmal mit einer Suche in der Hilfe wie im Internet...

In der Hilfe der VBox im Abschnitt "Host Interface Networking and bridging on Windows" steht in einem Absatz weiter unten:
If your host is running Windows XP or newer, you can also use the built-in bridging feature
DAS ist möglicherweise falsch: Es muß vielleicht richtig heißen, "must"...
Also: Ich probiere die Anweisung einfach mal aus...
Tja, Hmmm....: Nichts geht mehr...
Aus dem Kontextmenü der Einträge geht hervor, daß diese jetzt irgendwie im "Bridge-Modus" sind. Eine Bridge als solche mag auch möglicherweise irgendwo in den internen Funktionalitäten der Netzwerktreiber aktiviert worden sein, aber "anfassen", einstellen, benutzen kann ich sie offenbar nicht.
Und auf der Kommandozeile sagt mir ipconfig, daß es keinen der beiden Adapter mehr kenne und nur noch einen mit Nullen konfigurierten "MAC-Brückenminiport" zu sitzen habe...

Na fein!

Ahhh ja: Ansichten aktualisieren bringt manchmal was...

-> JETZT existiert eine "Netzwerkbrücke" in den Netzwerkeinstellungen...

DIE stelle ich schnell mal auf die korrekten Adressen ein...
So, und jetzt müßte ich doch sicherlich auch noch den beiden Adaptern irgendwas mitteilen, oder?
Nein: Die werden jetzt über Kontextmenü/Eigenschaften nur noch wie Netzwerkadapter behandelt, nicht mehr wie darauf aufsetzende logische Elemente... -> Es gibt dort jetzt keinen Dialog für Protokolle und dergleichen mehr...
Klick auf "Status" im Kontextmenü geht allerdings auch ins Nirwana...

Außerdem hatte Windows vorhin was gemeckert von wegen, daß es neu starten möchte. Da ich dies als übertriebene Forderung kenne, habe ich es erstmal ignoriert. Aber möglicherweise muß hier jetzt wirklich ein Neustart ran...

-> OK: Im Suse-Installations-Prozeß erstelle ich einen neuen Sicherungspunkt und beende die VM...
Dann wird Windows neu gestartet...

Bei der Gelegenheit schaue ich mir auch mal die Speicherbelegung der VM an... Beim Start der VM schnellt der belegte Speicher von 143 MB...
  • auf 164 MB (Start des VBox-Managers)
  • auf 223 MB (unmittelbar nach Start der VM)
  • auf 525 MB (nachdem das Linux wieder da ist)
Vom letzteren Schritt ist im Procexp nichts zu sehen außer der Summe des belegten Speichers...
Offenbar belegt die VBox den Speicher an der Verwaltung von Windows vorbei...
Oder der ProcExp oder auch Windows ordnet bestimmte Typen von Speicherbelegungen einfach keinem Prozeß zu...

...Auf einmal herrscht mächtig reger Verkahr an der Netzwerkbrücke...
Vom Linux aus wurden bei Start der VM 333 Pakete ins Netz geschickt.
...Und es werden fortlaufend mehr - OHNE daß ich irgendwas tue...
-> Offenbar braucht Linux auch gewisse Handschellen angelegt, was seine Netzwerkaktivitäten betrifft...

Wie ich gerade feststelle, habe ich Wireshark gar nicht im System...???
Häää?!
Das Ding ist doch IMMER SCHON installiert gewesen?!
Ich glaub's nicht! Ich hab das Zeug auf JEDEM Rechner sonst (privat und auf Arbeit) installiert, und ausgerechnet auf meinem eigenen Heimserver sollte ich es die ganzen Monate seit März nicht benutzt haben?!
Drüben im alten Win98 liegt es noch ganz friedlich...
Hmmm, 'ne Version 0.99.4... -> Das prüfe ich mal auf Updates...

...Zwischendurch weitermachen mit Linux: Der Test des Netzwerkes bringt etwas mehr Leben in die Bude: Jetzt werden schon sehr viel mehr Bytes gesendet und auch einige wenige empfangen. Aber die Verbindung ins Internet klappt offensichtlich immer noch nicht...
Vom Wirtssystem aus klappt alles wie schon immer...

Wireshark könnte dabei sehr behilflich sein...

In den Eigenschaften der Netzwerkverbindung des Wirtes ist jetzt alles leer. Genauso in denen des Gastsystems (die im Wirt anfaßbar ist)...
Offenbar sind die Dialogboxen von Windows tiefer und dabei falsch bzw. unvollständig ins System integriert: Sie zeigen in dieser möglicherweise zum Designzeitpunkt der Netzwerkdialoge noch nicht berücksichtigten Betriebsart gar nichts an...

Zurück zu Wireshark: Aktuell ist die Version "0.99.6"...
Bei der Installation wird Winpcap ohne Erlaubnis in einen Standardordner installiert. DAS geht so nicht! -> Rückgängig...
Bevor ich jetzt groß im Netz nach Installationspaketen suche, die das besser machen, ändere ich einfach die Registry... (es geht ja nur um ein einziges kleines Progrämmchen...)
Ähmmm... Im Service steht aber auch etwas davon, daß es da eine "rpcapd.ini" geben soll... Davon habe ich allerdings nichts gesehen!
Na ja, abwarten: Die wird sicherlich beim ersten Start erzeugt werden...

Jetzt sehe ich endlich, was da auf der Linux-Bridge übertragen wird:
Bridge Protocol Data Units
Das ist also OK. -> ausgeblendet!
Dann bleibt erstmal nichts mehr übrig...

JETZT nochmal zu einem Netzwerktest im Linux...
Hmmmm: Beim Wireshark kommt nichts an...
Irgendwas stimmt noch nicht von Seiten des Linux oder vom Vermittler namens VBox her...
Die Brücke im Wirtssystem selbst funktioniert.
In der Hilfe der VBox steht aber nichts weiter.
Und im Linux muß ich erstmal über die Installationsprozedur hinweg.
Ich ignoriere das Zeug also erstmal...

Benutzer anlegen...
Snapshot vor der Hardware-Konfiguration!...

Hardware-Konfiguration: Ich lasse diesmal alles so, wie es ist...

So, dann mal los...
Ja: Sieht besser aus: eine grafische Oberfläche mit Login...

Grund-Einrichtung

Ahhh ja: Eine Website mit Infos zum OS kommt hoch...
Links zum OpenSuse-Wiki stehen drauf...
Beim Klick auf jenen Link werden Aktivitäten am Wireshark im Wirt gelogged:
  • jede Menge DNS-UDP-Anfragen an eine ominöse (von mir nie gesehene, geschweige denn eingestellte) Adresse 224.0.0.251...
    -> SOWAS habe ich natürlich nicht...!
    Mein privates Subnetz liegt auf der 192.168.x.x!
    Und ich glaube, das auch sehr deutlich während der Konfiguration zum Ausdruck gebracht zu haben!
  • Nebenbei ein paar IPV6-Pakete, die ich aber ignorieren kann.
  • Außerdem ein paar IGMPs (mit diesen ominösen Gruppen kann ich eh nichts anfangen - ich ignoriere sie also erstmal auch...)
-> Wie bringe ich dem Linux denn jetzt die korrekten Netzwerkeinstellungen bei?
-> Erstmal diesen Begrüßungsbildschirm weg!

Start (aias "Computer") -> ....??! - Ihhhh! Was haben DIE denn da gemacht!?!
Die haben ja dieses eklige Windows-Klicki-Bunti kopiert!
Pfui Teufel! Wie kriege ich denn DAS nun wieder abgewöhnt?
Die haben das sicherlich drauf gehabt, auch noch die dauernde Veränderung der Menüs abzukupfern! So treffe ich ja nie im Leben das, was ich will!

Ach was - ich will jetzt ERSTMAL das Netzwerk in Ordnung bringen!
Da gibt es ja sogar einen Eintrag dazu im Startmenü rumhängend...
"Aktivierbar" scheint der zu sein...
Klick darauf macht aber nichts...
Nochmaliger Klick: Nichts passiert. Ich gehe aus der VBox raus und wieder rein, mache das Startmenü nochmal auf und klicke nochmnal drauf: Nchts passiert.
Inzwischen ist aber ein neuer Eintrag im Startmenü aufgetaucht (oh ja: exakt wie GENAU DAS, was ich beim Windows immer gleich als erstes abstelle, was ich mir NIE und nimmer bei einem System WÜNSCHEN würde...). Klick auf DEN bringt auch nichts zustande...

PLÖTZLICH gehen etliche Fenster übereinander auf...
Aha: Das war wohl der VM anzulasten? Oder vielleicht eher einem trägen Linux-System?
Gut, jetzt warte ich einfach mal ab, ob irgendwann was passiert...
Ahhh, ja: Nach rund 15 Sekunden geht der nächste Dialog auf...

Netzwerkeinstellungen

Bei Hostname/DNS ist kein DNS-Server eingestellt... -> 192.168.... eingetragen
Was das Zeug mit dem Domänen-Namen soll, ist mir soweit schleierhaft...
Nebenbei deaktiviere ich mal IPv6 (das wird von meinem Provider eh nicht unterstützt - und wer zur Zeit IPv6-Adressen überhaupt zur Verfügung stellt, ist mir soweit auch noch schleierhaft. Letztlich sind es nur sinnlose Pakete im Netzwerk...).

So, jetzt hätte ich gern eine Konsole...
Auf allen bisher mir untergekommenen Live-CDs war das genau ein Klick. Da wurde man von Konsolen regelrecht erschlagen.
Jetzt muß ich erstmal suchen, wie ich so eine Bash oder was auch immer überhaupt gestartet kriege, damit ich mal so was simples wie ein ping machen kann...

Im "Filter" mal eben "konsole" oder "bash" einzutragen bringt exakt: Null
OK: Wir haben aber ein GUI MIT PING! Das ist soweit AUCH OK...
Gut:
  • Sich selbst (192.168.1.3) sieht er.
  • Den Wirt (192.168.1.1) aber schon nicht mehr...
  • Das Gateway (192.168.1.254) auch nicht...
Mal ein Gegentest auf dem Wirt...
  • Der sieht das Linux jetzt auch nicht mehr...
    (er HATTE es schon mal anpingen können - BEVOR ich die "Brücke" auf dem Wirt eingeführt hatte...)

Was sagt Wireshark?
  • Es laufen ununterbrochen ARP-Handshakes über die Leitung:
    2614 2007-10-21 16:49:21.790107 CadmusCo_06:d9:1a Broadcast ARP Who has 192.168.1.254? Tell 192.168.1.3 2615 2007-10-21 16:49:21.790804 BillionE_1a:d6:92 CadmusCo_06:d9:1a ARP 192.168.1.254 is at 00:04:ed:1a:d6:92
Aber irgendwie scheinen die wohl nicht zurück in die VBox zu finden, oder?

Was sagt die Firewall?
  • Die sagt so gut wie nichts, während beim Wireshark am laufenden Band neue Pakete durchlaufen...
  • -> Könnte es sein, daß ich das Loging bei der Firewall irgendwann mal stark eingeschränkt hatte, so daß nur noch Dinge gelogged werden, die ich als kritisch ansehe?
  • Möglich, daß die Firewall in diesem Bridge-Modus überhaupt nicht mehr korrekt funktioniert: Es werden offenbar NUR Pakete überhaupt angeguckt, die über den "Netzwerkanschluß" der "LAN-Verbindung" für den Wirt gehen. Die über die Bridge oder den anderen "Anschluß" werden überhaupt nicht erst beachtet.
  • -> Ja: genau: Egal, ob ich die Firewall auf "alles durchlassen" oder "alles blocken" stelle, die Pakete zwischen dem Linux und meinem Modem/Router (mit dem DNS-Server für mein LAN) gehen unbeeinflußt weiter...
Nun gehen aber Anwendungspakete immer noch nicht vom Linux nach draußen. Und vor allem kommen immer noch vereinzelte Pakete vom Linux durch, die auf diese ominösen 224er-Adressen lauten! Was soll der Scheiß denn bitte?!

Ein bißchen Stöbern in den Tiefen des Linux fördert auch dort genau dasselbe Wireshark zutage... DAMIT läßt sich doch schon richtig was anfangen...
Wireshark auf Linux sagt also: Die Anfragen
2614 2007-10-21 16:49:21.790107 CadmusCo_06:d9:1a Broadcast ARP Who has 192.168.1.254? Tell 192.168.1.3
gehen dort durchaus raus, aber es kommen keine Antworten mehr rein...

Die Verbindung an sich steht also. Die Bridge an sich arbeitet.
Das Netzwerk an sich im Linux auch.
Das Netzwerk im Wirt sowieso.
Aber irgendwas oder wer blockiert das Zurückschicken der Pakete vom DNS-Server an das Linux...

...Leider vergeht zwischen diesen Erkenntnissen immer wieder massenhaft Zeit, weil ich im Internet suche oder familiäre Sachen erledige oder weiß der Kuckuck was noch... Insgesamt verbrät diese Geschichte einfach schon wieder viel zu viel Zeit. Andererseits scheine ich doch NUR um die Winzigkeit einer virtuellen - und einseitigen - Mauer von meinem Ziel entfernt zu sein!

WER BLOCKT die DNS-Antwort-Pakete?!

Die Suchen im Internet ergeben ausschließlich Treffer in Foren, wo fast nur von Linux-Wirtssystemen ausgegangen wird, vor allem aber extrem weitschweifig gelabert und zitiert und gesigniert...

Ein weiterer Versuch betraf die Linux-Firewall: Abgeschaltet kommt allerdings genausowenig zurück...

Zwischendurch versuche ich, alle greifbaren Werkzeuge zur Prüfung des Netzwerkes durchzuprobieren. Dabei funktioniert auf einmal auch der Zugrif auf meinen Apachen im Wirtssystem nicht mehr (während ich weiter nach draußen zugreifen kann).

Letztlich beschließe ich, die "Brücke" wieder zu entfernen: Ich wüßte nicht, warum ich sie brauchen sollte, wenn ich doch gar keine getrennten Subnetze betreiben will - außer, daß sie eventuell aus irgendeinem internen philosopischen Grund für die Macher der VBox notwendig wäre...

Beim Entfernen der Brücke (also erst dem Trennen der Netzwerkadapter von der Brücke) allerdings gibt es einen BlueScreen - und zwar vom TDIMonitor (den ich zwischendurch mal angeschmissen hatte, der mir aber nichts nutzte).

Nach einem Neustart ist erstmal alles im Wirtssystem wieder da...

Wo kam eigentlich der "Netzwerkmonitortreiber" im Wirtssystem her, der jetzt auf einmal in den Netzwerkverbindungen als Protokoll eingetragen ist? Vom Wireshark?
Ich starte den mal kurz und mache ein paar Netzwerkaktivitäten: Er zeichnet gar keine Pakete mehr auf! Obwohl er auch nicht meckert, wenn ich ihm die Interfaces zuweise - wo übrigens die eben entfernte Brücke auch anstandsgemäß nicht mehr aufgezählt wird.
Ich entferne die "Netzwerkmonitortreiber" ganz aus den "Netzwerkanschlüssen"...

Ich gehe mal ne Wette ein, daß in den Verwaltungsinformationen von Windows jetzt irgendetwas faul ist. Ich starte mal spaßenshalber neu...

Wireshark arbeitet weiter ganz normal...
Tja: Diese "Netzwerkmonitortreiber" waren schon recht seltsam...
Aber bevor ich mich jetzt damit um das nächst tiefere Stack-Level von Seltsamkeiten kümmere, möchte ich doch nochmal die VBox zum Laufen bringen...

Ich habe die Netzwerkverbindung "VirtualBox Hostinterface 1" nochmal umkonfiguriert: Vielleicht ist die Sache ja noch GANZ ANDERS, und zwar von ihren Erzeugern GEMEINT...
Was die sich dabei an Funktionalität GEDACHT hatten, haben sie ja nirgendwo dokumentiert. Anhand der Begriffe, die sie in der Hilfe verwendet haben, kann man nur vermuten, was dieses "VirtualBox Hostinterface 1" für eine Bedeutung haben sollen könnte...

Möglicherweise ist es ja doch als etwas gedacht, das identisch zu einem normalen Hardware-Netzwerk-Adapter funktionieren soll, indem Pakete, die AUF dieses Ding geleitet werden, an die VM weitergeleitet werden?

Was ich bisher vermutete, war, daß das Ding eine ähnliche Funktion haben könnte wie der Netzwerkadapter, das im Wirtssystem bei VMWare zusätzlich auftaucht: DA ist es so, daß das Ding gewissermaßen eine SPIEGELUNG eines Stücks Hardware des Gastsystems darstellt. Man kann es in dasselbe Subnetz wie den Wirtsrechner hängen und ihm dieselben Einstellungen für DNS und Gateway mitgeben. DIE wirken dann NICHT FÜR das Wirtssystem, SONDERN FÜR das Gastsystem.
Die Erzeuger des "VirtualBox TAP Adapter" waren da aber möglicherweise anderer Ansicht? Vor allem schweigen sie sich offenbar über ihre Ansicht aus: Im Internet finde ich AUSSCHLIEßLICH Diskussionen von Leuten, die genausowenig oder noch weniger Ahnung haben wie bzw. als ich in Foren, nie aber eine Referenzdokumentation.

Ich konfiguriere den Adapter also mal auf ein nebenliegendes Subnetz (das Nuller)...
Außerdem stelle ich die Betriebsart des "VirtualBox TAP Adapter" namens "Media Status" wieder sicherheitshalber auf das, was ich ursprünglich vorgefunden hatte: "Anwendungskontrolliert".

Ping auf das Nuller Netz geht jetzt von Wirt aus genau dann, wenn die VM gestartet ist (was Sinn ergibt). Allerdings zeigt der Wireshark auf dem Wirt KEINERLEI Netzaktivität an, wenn ich den Ping auf das Nuller Netz mache.
Das bedeutet MIT SICHERHEIT, daß das ganze NICHT so funktioniert, wie ich es mir jetzt gerade als Variante gedacht hatte.

OK, aber das Ping aus dem Gast zum Wirt klappt jetzt: Auch der Wireshark zeichnet es mit. Und mir erleuchtet es jetzt, wie das ganze gemeint sein kann: Der "VirtualBox TAP Adapter" stellt also tatsächlich eine Art Netzwerkkarte im Wirt dar, ÜBER DIE ein weiteres Subnetz gebildet wird, AN DEM dann die verschiedenen Gastsysteme hängen können.
DASS ich dem Adapter im Wirt die "0.1" verpaßt habe, erweist sich also als passend...
Ping vom Wirt zum Gast sollte jetzt auch klappen: Ja! Und es wird vom Wireshark mitgezeichnet...
Daß das Ping vom Wirt aus auf den Adapter "0.1" nicht mitgezeichnet wird, könnte daran liegen, daß die betreffenden Pakete gar nicht erst innerhalb des "VirtualBox TAP Adapter" bearbeitet werden, sondern von diesem oder vielleicht sogar schon von einem Netzwerk-Layer im Windows aus dem TCP/IP-Treiber-System herausgehalten werden...

OK, wir sind auf dem besten Weg...
Sicherheitshalber nochmal mit Wireshark im Gast kontrolliert, daß die Beantwortungen auch wirklich vom Gast kommen und nicht irgendwie vom Treiber der VBox:
...Jetzt bin ich aber ein wenig stutzig: Im Linux gibt es bei den Netzwerkadaptern, an denen man ein Capture starten kann, einen Punkt für "an allen". DER fehlt im Windows-Wireshark! Warum?

Jau: Die beiden Wiresharks protokollieren identisch.

SOOOO... JETZT wäre nochmal die Zeit gekommen, um über eine Brücke nachzudenken...
...ODER auch über die Benutzung des NAT-Modus...
Weil: Das zusätzlich innerhalb der VM-Umgebung gebildete Subnetz ist ja nun erstmal getrennt... Was soll ich mit einem Subnetz, das vollkommen abgeschlossen ist? - Es sei denn, ich MÖCHTE, daß es vollkommen abgeschlossen ist...

EIGENTLICH will ich nur einfach weitere Rechner in das schon vorhandene Subnetz einhängen können.
Nicht dagegen wollte ich das Subnetz in 8-Bit-Netze aufteilen oder so ähnlich.
Am glücklichsten wäre ich, wenn ich das 16-bit-Subnetz so bestehen lassen könnte, wie es ist.
Das ist nämlich bei Besuchern mit Rechnern, die für IRGENDWELCHE IPs im 192.168-Bereich eingestellt sind, immer noch die sicherste Methode, mit meinem privaten LAN Kontakt aufnehmen zu können - falls ich das wünsche, was meistens der Fall ist, wenn Besucher bei mir sind.

Wenn ich das jetzt erstmal (auf der ersten Stufe) funktionierende System so lasse, werde ich aber definitiv getrennte Subnetze haben...

Was ich EIGENTLICH BRÄUCHTE wäre eine Möglichkeit, Pakete vom Subnetz der VM(s) ins "richtige" LAN weiterzuleiten, solange sie nicht gerade für den Wirt gedacht sind. Eine einfache Router-Funktion also. Oder auch "Brücke". Wie immer man Begrifflichkeiten bevorzugen möge...

Allerdings: MEINT Microsoft mit SEINER Brücke auch dasselbe wie ich?

UND außerdem bräuchte ich eine Möglichkeit, das Subnetz der VM's, das ja offenbar (nach meinem momentanen Kenntnisstand) nur über den ominösen "VirtualBox TAP Adapter" oder aber NAT (und damit ohne explizit im "realen LAN" zu sehen zu sein) an den Rest der Welt angeschlossen werden kann, SO festlegen zu können, daß es immer noch in das 16-bit-LAN paßt...

RRRRrrrr... Ich gehe gleich die Decke hoch!
Jetzt habe ich die VM über ihr Dateimenü ausgeschaltet und dabei war noch das Häckchen bei "Zurückkehren zum letzten Sicherungspunkt" gesetzt!
SOWAS gehört RAUS!
Das melde ich noch als Bug...

Glücklicherweise ist der Schaden nicht allzu groß: Lediglich die Hardware-Konfiguration muß nochmal akzeptiert werden...
So, damit mir das nicht nochmal passiert, werde ich jetzt erstmal die Sicherungspunkte verwerfen...
Vorher allerdings nochmal mit den Grafikeinstellungen experimentiert...
Offenbar geht die Grafikauflösung nicht im laufenden Betrieb umzustellen. Das Linux zeigt unabhängig von der eingestellten Grafikkarte (wo man verschiedene Vesa-Modi ansetzen kann) und dem Monitor (wo man dasselbe tun kann) grundsätzlich nur die beim Initialisieren des Systems existent gewesene Auflösung an. Und die hatte ich "damals" sicherheitshalber so gelassen, wie sie war (800*600).
Nach einem Neustart allerdings wird die Auflösung dann geändert.
Mit der Installation der "Geräteerweiterungen", die ich irgendwann auch mal machen werde, nachdem viele andere Schwierigkeiten aus dem Weg geräumt sein werden, wird sich das hoffentlich noch verbessern...

So, eine Stunde später sind die Snapshots endlich gelöscht: Die VBox braucht gut doppelt bis dreimal so lange, einen Snapshot zu verwerfen, wie ihn frisch anzulegen! Ich frage mich, was die da großartig herumzaubern?! Schließlich geht es doch nur ums VERWERFEN von gespeicherten Dingen, oder?

Wo kam ich her? Ach ja: Vom Wiedereinrichten der Bridge...
Ich teste nochmal, wieweit das jetzt funktioniert...

Dabei auch gleich nochmal ein bißchen Herumstochern, wie dieses scheußliche Menü ersetzt werden kann...
-> ES KANN:
  • Rechtsklicks unterstützt Gnome auch!
  • -> Alles bis auf die Uhr aus dem Menü unten rausschmeißen!
  • "Zum Panel hinzufügen"...
    • Was die Leute als "Anwendungsstarter" bezeichnen, ist unter Windows heutzutage ein "Link" bzw. war früher mal ein "Pif"
      -> DIE ergeben dasselbe wie die Schnellstarteinträge...
    • Eine "Schublade" ist praktisch ein selbsterzeugtes Untermenü
    • "Traditionelles Hauptmenü" ist DIE ERLÖSUNG!
-> GOTT! Es hat Hirn geregnet! Geheiligt seien die Erleuchteten, die das klassische Gnome-Startmenü erzeugt hatten!
-> Das Ding ist FAST genauso wie mein seit 15 Jahren gewachsenes persönliches Windows-Startmenü gestaltet (Hauptgliederung und sogar im wesentlichen die nächste Unterebene)! DAS nenne ich mal Komfort!
Und etwas, wo offenbar mehrere Leute unabhängig die gleichen Ideen hatten!
-> Auf Anhieb fühle ich mich wie zu Hause!

So, wo kam ich her? Ach ja: Ping machen, um Netzwerk zu prüfen...

Ja: Alles OK: Internet, Rechner-Austausch. Ich beginne, es zu mögen...

Häusliches Einrichten

Das kommt bei nächster Gelegenheit...

Vor dem Schlafengehen konnte ich mich nicht beherrschen, nochmal schnell ein bißchen einzustellen und Programme auszuprobieren: JETZT geht die eigentliche Arbeit mit dem System erst los: Analog zur Einrichtung von Windows wird das sich noch Wochen hinziehen. Ich gehe mal davon aus, daß ich das System so um Jahreswende soweit haben kann, daß es ein vollwertiger Ersatz fürs Windows-System werden kann. DANN steht eventuell eine Parallel-Installation auf dem großen Rechner (also auf richtiger Hardware) an.