expertenaustausch > comp.hardware.* > comp.hardware.misc

Werner Tann (25.01.2019, 15:42)
Frank Möller <butterspiegeleiauftoast42> schrieb:

>Dann spielt man 1. sein System und 2. seine VMs zurück.


Software ist scheiße, wenn man vor jedem Update ein
Windows-Komplettbackup machen muss.

>Und wenn man keine Lösung finden sollte, kann man auch durchaus bei einer
>bestimmten VirtualBox bleiben.


Eben nicht. Eine "zerschossene" Virtualbox-Installation ist in > 50 %
der Fälle nicht wiederbelebbar oder eben nur durch aufwendige
Recherche.

>> Wenn man nicht gerade das Windows-Backup (inkl. Progs) zurückspielen
>> will,

>Warum sollte man das nicht wollen, wenn es doch das Mittel der Wahl ist?


Software ist scheiße, wenn man vor jedem Update ein Komplettbackup
machen muss.

>Nun ja, wenn ein Ultra-DAU unbedingt mit VMs herumspielen zu müssen meint,
>muß er halt eine Lernkurve hinlegen und sich aus seiner DAU-Niederung
>erheben.


Das hat nichts mit Lernen zu tun, das einem für irgendetwas anderes
auch noch nützlich sein könnte. Hier geht es um Wissen, das einzig für
die Virtualbox taugt. Wissen, das deswegen erworben werden muss, weil
die Programmierer so unfähig/faul sind, eine Oberfläche zu
programmieren, für deren Troublehandling externes Wissen nötig ist.

Ich gebe dir ein anderes Beispiel: Es kann (konnte?) etwa sein, dass
irgendwas deshalb nicht klappte, weil man zwar das Update installiert
hatte, aber nicht dieses dämliche Expansionpack. Warum muss man dieses
extra installieren, wenn es doch ohnehin zwingend ist?

>Bullshit. 1. hat man System-Backups. 2. fertigt man, wenn man schon
>System-Backups vorhält, vernünftigerweise auch Backups seiner
>VirtualBox-VMs. Bei denen kann man auch beim normalen Herumspielen was
>zersägen. Dann macht man so eine VM zu, klickt kurz den Restore an, wartet
>ein paar Sekunden, startet die VM wieder neu - und ist glücklich.


Haha, nicht wirklich. Das ist das Tückische. Backups der Virtualbox
helfen auch nicht immer. Ich habe mich fluchend gefragt, in welchem
versteckten Ordner diese Idioten noch eine Konfig-Datei hingetan haben
könnten, die kaputt ist. Alles andere war nämlich zurückgesichert.
Trotzdem klappte es nicht.
Werner Tann (25.01.2019, 15:42)
Frank Möller <butterspiegeleiauftoast42> schrieb:

>> Das Testen von Utilities, die auf richtige Hardware zugreifen wollen,
>> ist natürlich von vornherein auch zum Scheitern verurteilt.

>Deswegen ist die Frage "Entweder Parallelinstallation oder VMs?" auch
>irgendwie hirnrissig. Praktischerweise hat man beides - jedes für seinen
>Zweck.


Ich habe ja auch beides. Und wenn du mich fragst, was mir mehr
Schmerzen macht, ist die Antwort für mich klar.
Frank Möller (25.01.2019, 16:11)
Werner Tann schrieb:
> Frank Möller <butterspiegeleiauftoast42> schrieb:


>> Dann spielt man 1. sein System und 2. seine VMs zurück.


> Software ist scheiße, wenn man vor jedem Update ein
> Windows-Komplettbackup machen muss.


Wenn man will, daß alles funktioniert, kann man ja dafür sorgen, daß das so
ist. Wenn Du jammern willst, kannst Du's ja so machen, daß es genug zum
Jammern gibt.

>> Und wenn man keine Lösung finden sollte, kann man auch durchaus bei einer
>> bestimmten VirtualBox bleiben.


> Eben nicht. Eine "zerschossene" Virtualbox-Installation ist in > 50 %
> der Fälle nicht wiederbelebbar oder eben nur durch aufwendige
> Recherche.


Deswegen sorgt man halt dafür, daß nix zerschossen wird, bzw. spielt den
funktionierenden Stand zurück - und zwar vom Host mit der funktionierenden
VirtualBox-Installation _und_ von den VMs.
Ralph Aichinger (25.01.2019, 17:02)
Werner Tann <wtann> wrote:
> Eben nicht. Eine "zerschossene" Virtualbox-Installation ist in > 50 %
> der Fälle nicht wiederbelebbar oder eben nur durch aufwendige
> Recherche.


Hä? Eine Virtualbox-Installation ist mehr oder weniger eine
Datei. Die kann man auf jeden anderen Rechner kopieren und
von dort starten.

Das ist so als würde man sagen: "Eine zerschossene Word-Installation
ist in 50% der Fälle nicht wiederbelebbar". Mag sein, aber das
was es geht, das Gastbetriebssystem verhält sich wie ein Dokument,
das man überall aufmachen kann.

> Haha, nicht wirklich. Das ist das Tückische. Backups der Virtualbox
> helfen auch nicht immer. Ich habe mich fluchend gefragt, in welchem
> versteckten Ordner diese Idioten noch eine Konfig-Datei hingetan haben
> könnten, die kaputt ist. Alles andere war nämlich zurückgesichert.
> Trotzdem klappte es nicht.


Selbst wenn irgendeine Konfig-Datei kaputt ist, solanage man das
virtuelle Festplattenabbild hat kann man die Maschine überall
wieder starten.

/ralph
Frank Möller (25.01.2019, 17:17)
Ralph Aichinger schrieb:
> Werner Tann <wtann> wrote:


>> Eben nicht. Eine "zerschossene" Virtualbox-Installation ist in > 50 %
>> der Fälle nicht wiederbelebbar oder eben nur durch aufwendige
>> Recherche.


> Hä? Eine Virtualbox-Installation ist mehr oder weniger eine
> Datei.


Es sind mehr oder weniger mehrere Dateien, die außerdem mit den
Einstellungen der Host-Installation korrelieren.

> Die kann man auf jeden anderen Rechner kopieren und von dort starten.


Theoretisch.

>> Haha, nicht wirklich. Das ist das Tückische. Backups der Virtualbox
>> helfen auch nicht immer. Ich habe mich fluchend gefragt, in welchem
>> versteckten Ordner diese Idioten noch eine Konfig-Datei hingetan haben
>> könnten, die kaputt ist. Alles andere war nämlich zurückgesichert.
>> Trotzdem klappte es nicht.


> Selbst wenn irgendeine Konfig-Datei kaputt ist, solanage man das
> virtuelle Festplattenabbild hat kann man die Maschine überall
> wieder starten.


Tja, so weit die Theorie. In der Praxis ist es dann so, daß z. B. meine
VMs, die mit VirtualBox 5.2.24 einwandfrei tun, nach der Inst. von
VirtualBox 6.0.2 plötzlich ziemlich stotternd laufen und der Sound kratzt.
Keine Ahnung, wieso. In den Einstellungen ist nix besonderes zu finden. Das
passende Extension-Pack ändert nix daran.

Gut, ich muß jetzt nicht zwingend sofort auf 6.0.2 updaten. Mal schauen,
was kommt. Entweder eine folgende Vers. der Host-Software behebt das
und/oder ich kann mich mal gelegentlich auf die Suche machen. Notfalls kann
ich auch bei Vers. 5.2.24 bleiben.

Schaung mer moi, nacha seng ma's scho.

Fakt ist aber, daß, wenn das schon auf ein- und demselben Host passiert,
man sowas nach Kopieren der bloßen VM auf einen anderen Host jetzt nicht
einfach ausschließen kann.
Takvorian (25.01.2019, 19:28)
Werner Tann schrieb:

> Takvorian <norbert.staak> schrieb:
>>Win 10 nur eine normale Datenpartition. Es gibt auch kein Bootmenü beim
>>Start, ich boote das andere System aus dem laufenden Windows heraus,
>>Win 10-A fährt dann runter und es bootet automatisch Win 10-B und umgekehrt.

> Um 10-B zu haben, musst du erst 10-A booten? Naja, umständlich geht
> immer.


Nein, wenn das umständlich wäre, würde ich's ja wohl kaum tun. Wenn 10-A
dein Standard-System ist, das du in 99,9% der Fälle immer verwendest, willst
du nicht wirklich bei jedem Bootvorgang ein Bootmenü haben, das dir
überflüssigerweise beide Systeme zur auswahl anbietet. DAS wäre dann
umständlich und zeitraubend.
Wenn ich allerdings vor jedem Booten überlegen müsste, welches der beiden
Systeme ich jetzt verwenden will, wäre ein Bootmenü angesagt.
Man kann aber auch mit Bootmenü immer noch autark installieren, also ohne
"Dualboot-Installation".
Takvorian (25.01.2019, 19:33)
Frank Möller schrieb:

> Werner Tann schrieb:
> Er ist halt wieder mal'n bißchen dohv[TM].


Du sprichst mal wieder von dir selbst.

> Selbst mit 10 geht eine
> Parallelinstallation mit Bootmanager, ohne daß man dann erst umständlich
> ein anderes System starten müßte.


Es geht natürlich, was allerdings nicht bedeutet, dass man sich nicht
zusätzlich die Möglichkeit einrichtet, das eine System aus dem anderen
heraus starten zu können.

> Der einzige Haken ist, daß bei jedem Start jenes System an erster Stelle im
> Boot-Manager angezeigt wird, welches zuletzt gestartet wurde.


Falsch, nur weil du die passende Einstellung nicht kennst, ist deine
Behauptung nicht wahr.
Takvorian (25.01.2019, 19:39)
Marc Haber schrieb:

> Takvorian <norbert.staak> wrote:
> Erstes Windows herunterfahren, Platte mit zweitem Windows dazustecken,
> starten, etwas damit arbeiten, herunterfahren, Platte mit zweitem
> Windows wieder abziehen, erstes Windows kaputt. Große Augen.
> Ok, streng genommen war das kein Dual Boot.


Das müsste man dann genauer untersuchen. Wenn man mehrere Systeme bootet,
sollte auf jeden Fall der hirnrissige Schnellstart in Windows deaktiviert
sein. Ist er aktiv, haben sich schon viele Leute deswegen ihre Dateisysteme
zerschossen. Wenn alles korrekt gemacht wird, gibt es jedenfalls keine
schädlichen Wechselwirkungen.
Takvorian (25.01.2019, 19:47)
Manfred Ullmann schrieb:

> On Thu, 24 Jan 2019 16:30:51 +0100, Takvorian
> <norbert.staak> wrote:
> Gerade SSD-Platten möchte ich keinesfalls einauen.


Das ist eben die krasse Fehlentscheidung.

> Wurde mir
> schon oft empfohlen. Möchte ich nicht, denn die
> Bootgeschwindigkeit ist mir recht wurscht (ob zwei, drei
> Sekunden oder - wie momentan bei mir - 20, spielt für mich keine
> Rolle).


Die Geschwindigkeit von Windows selbst profitiert natürlich ebenfalls.
Es ist z.B. ein krasser Unterschied, ob eine Suche auf C: 5 Sekunden oder 40
Sekunden dauert, zumindest bei der nicht gecachten Erstsuche.

> Mir ist wichtiger, datenreste recht exakt zu schreddern.


Auch SSDs lassen sich sicher löschen.

> Außerdem scheinen "alte" HDs schlicht länger zu halten.


SSDs halten üblicherweise länger als der User sie braucht.

> Ich möchte weiterhin vor dem Booten entscheiden, ob ich WIN oder
> LIN nutzen möchte.


Natürlich, deshalb fügt man im Windows-BCD einen Starteintrag für Linux ein.
Der MBR bleibt dadurch unvermurkst. Und jedes System bleibt autark auf
seiner Disk.
Marc Haber (25.01.2019, 19:51)
Frank Möller <butterspiegeleiauftoast42> wrote:
>Werner Tann schrieb:
>> Virtualbox kann von jetzt auf gleich aufhören zu funktionieren, am
>> ehesten nach einem Update.

>Dann spielt man 1. sein System und 2. seine VMs zurück.


Vor allen Dingen weil man mit Virtualbox wunderbar Backups und
Snapshots machen lassen. Alleine Snapshots sind das Killer-Argument
dafür, Testsysteme nicht direkt auf Hardware laufen zu lassen.

Grüße
Marc
Werner Tann (25.01.2019, 19:57)
Ralph Aichinger <ra> schrieb:

>Hä? Eine Virtualbox-Installation ist mehr oder weniger eine
>Datei. Die kann man auf jeden anderen Rechner kopieren und
>von dort starten.


Definitiv nicht. Lies einfach die diversen Supportanfragen.

Für dich hab ich extra noch meine (eigene) Reparaturanleitung
herausgesucht. Ob die heute noch gilt, weiß ich nicht. Damals musste
ich so vorgehen:

1) Das gescheiterte Update deinstallieren (läßt K:VIRTUAL unberührt)
2) Die vorige, alte Version wieder installieren.
3) c:\benutzer...\.virtualbox und c:\programme\oracle\virtualbox aus
dem Windows-Image zurückkopieren.
WENN NACH UPDATE WIN XP NICHT MEHR STARTET, CHECKEN OB IN DEN
GASTEINSTELLUNGEN (Maschine --> System) erstens die VT... aktiviert
ist, zweitens die Nesting-Option gesetzt.

So viel zu deiner "Datei", die man einfach kopiert. Und ... leichtes
Troublehandling schaut anders aus.
Frank Möller (25.01.2019, 20:06)
Werner Tann schrieb:

> Für dich hab ich extra noch meine (eigene) Reparaturanleitung
> herausgesucht. Ob die heute noch gilt, weiß ich nicht. Damals musste
> ich so vorgehen:


> 1) Das gescheiterte Update deinstallieren (läßt K:VIRTUAL unberührt)
> 2) Die vorige, alte Version wieder installieren.
> 3) c:\benutzer...\.virtualbox und c:\programme\oracle\virtualbox aus
> dem Windows-Image zurückkopieren.
> WENN NACH UPDATE WIN XP NICHT MEHR STARTET, CHECKEN OB IN DEN
> GASTEINSTELLUNGEN (Maschine --> System) erstens die VT... aktiviert
> ist, zweitens die Nesting-Option gesetzt.


LOL. Wenn Du Deine Backup- und Restore-Strategie für a) das Host-System und
b) für die VMs nicht im Griff hast, was kann VirtualBox dann dafür?
Frank Möller (25.01.2019, 20:32)
Marc Haber schrieb:
> Frank Möller <butterspiegeleiauftoast42> wrote:
>> Werner Tann schrieb:


>>> Virtualbox kann von jetzt auf gleich aufhören zu funktionieren, am
>>> ehesten nach einem Update.


>> Dann spielt man 1. sein System und 2. seine VMs zurück.


> Vor allen Dingen weil man mit Virtualbox wunderbar Backups und
> Snapshots machen lassen. Alleine Snapshots sind das Killer-Argument
> dafür, Testsysteme nicht direkt auf Hardware laufen zu lassen.


Für andere Gegebenheiten ist es ein "Killer-Argument", _gerade_ auf
Hardware (etwa auf einem Parallelsystem) zu testen. Kommt immer auf die
konkreten Anforderungen an. Deswegen kann ich diesem dümmlichen XOR-Streit
darum, ob man nun entweder auf Hardware oder in VMs testen "muß", nix
abgewinnen. Praktischerweise macht man's mal so oder mal so, je nach
Anforderungen/Gegebenheiten.

Probleme können hier und dort auftauchen. Ebenso kann man sie hier und dort
vermeiden, wenn man vernünftig an die Sache rangeht und es nicht gleich im
Hau-Ruck-Verfahren durchklotzt.
Manfred Ullmann (25.01.2019, 23:37)
On Fri, 25 Jan 2019 18:47:56 +0100, Takvorian
<norbert.staak> wrote:

>Manfred Ullmann schrieb:
>Das ist eben die krasse Fehlentscheidung.
>Die Geschwindigkeit von Windows selbst profitiert natürlich ebenfalls.
>Es ist z.B. ein krasser Unterschied, ob eine Suche auf C: 5 Sekunden oder 40
>Sekunden dauert, zumindest bei der nicht gecachten Erstsuche.


Für eine sehr rasche Suche (teils Zehntelsekunden) nutze ich
lang schom "Lokcate 32".

>Auch SSDs lassen sich sicher löschen.
>SSDs halten üblicherweise länger als der User sie braucht.
>Natürlich, deshalb fügt man im Windows-BCD einen Starteintrag für Linux ein.
>Der MBR bleibt dadurch unvermurkst. Und jedes System bleibt autark auf
>seiner Disk.


Danke für Deine Hinweise. Ich werde eine der angezeigten HDs
einbauen (KEINE SSD) und darauf einzig und allein Linux
installieren. Vor dem Booten weiß ich ja, was ich am PC arbeiten
möchte und welche Programme ich benötige. Habe ich mich bis
kommendes Jahr für meine Zwecke gut genug in Linux
eingearbeitet, werde ich eh nur noch den Pinguin nutzen.
Vielleicht deinstalliere ich dann WIN7 und nehme wieder mein
altvertrautes WINXP ohne jegliche Internet-Verbindung für einige
wenige Spiele, die Linus nicht bietet.
Takvorian (26.01.2019, 14:09)
Manfred Ullmann schrieb:

>>Die Geschwindigkeit von Windows selbst profitiert natürlich ebenfalls.
>>Es ist z.B. ein krasser Unterschied, ob eine Suche auf C: 5 Sekunden oder 40
>>Sekunden dauert, zumindest bei der nicht gecachten Erstsuche.

> Für eine sehr rasche Suche (teils Zehntelsekunden) nutze ich
> lang schom "Lokcate 32".


Da wäre eine MFT-Suche wie "Ultrasearch" besser, sie baut nicht erst einen
Index auf und läuft nur dann, wenn man etwas sucht. Kann man sich mit einer
SSD aber alles ersparen. Die Suche war auch nur ein Beispiel, ich könnte
noch tausend andere bringen. Es ist schlicht so: man kauft sich einfach
keinen Tretroller, wenn man sogar billiger einen Rennwagen bekommen kann.

>>Natürlich, deshalb fügt man im Windows-BCD einen Starteintrag für Linux ein.
>>Der MBR bleibt dadurch unvermurkst. Und jedes System bleibt autark auf
>>seiner Disk.


> Danke für Deine Hinweise. Ich werde eine der angezeigten HDs
> einbauen (KEINE SSD) und darauf einzig und allein Linux
> installieren.


Wobei darauf zu achten wäre, dass sich das Zeug nicht im MBR einnistet. Legt
man Grub in den MBR, ist die Sache mit dem nächsten Windows-Upgrade im
Eimer. Legacy-Installation wäre sinnvoll, man kann dann mit zwei/drei
Mausklicks via EasyBCD im Windows-BCD einen Starteintrag für Linux
hinzufügen - oder man ruft beim Booten via F(x) das BBS-Bootmenü auf und
wählt dort einfach die zu bootende Disk aus...
Bei UEFI-Installation ist die Windows/Linux Koexistenz eher schlimmer als
besser geworden.

Ähnliche Themen