Hallo, ich möchte auf meinem Windows 7 Rechner Ubuntu in einer virtuellen Maschine (Virtualbox) installieren. Bei der Installation ist allerdings die Auflösung zu klein, sodass ich in einem Fenster nicht auf "weiter" klicken kann. Auch wenn man in den Einstellungen der Virtualbox die Anzeige auf z.B. 1024x768 setzt ändert sich nichts. Nach einigem googeln ist dieses Problem schon länger bekannt und wohl seit der Ubuntu Version 14.04 vorhanden. Ich habe natürlich alle aktuellen Versionen runtergeladen, also Virtualbox 5.0.16 und Ubuntu 15.10. Nach allem was ich so gelesen habe muss man zu der virtuellen Maschine noch die "Gasterweiterung" von Oracle installieren. Und genau hier komme ich nicht weiter: Wenn ich alles richtig verstanden habe, muss die Gasterweiterung innerhalb der Ubuntu Maschine installiert werden. Das Problem: Bevor ich in der Ubuntu Maschine was installieren kann, muss ja erstmal Ubuntu selbst (inklusive der Partitionen) installiert worden sein. Nur das schaff ich ja solange nicht, solange ich diese Gasterweiterung nicht installiert habe. Ich habe auch versucht Ubuntu erstmal von der DVD zu starten und dann mit einigen Befehlen die Gasterweiterung "zu erzwingen". Aber auch da bin ich nicht so richtig weitergekommen. Kann ja eigentlich auch nicht wirklich funktionieren, weil ja noch garkeine Partitionen erstellt wurden. Auch während der Installation habe ich versucht das Terminal zu öffnen und mit einigen Befehlen diese Gasterweiterung zu installieren... ohne Erfolg. Kann mir jemand helfen?? Vielen Dank!
Ok, es ist wohl nicht die beste Lösung, aber mit der Tab-Taste kann man natürlich zu dem Button springen auf dem "Weiter" oder "Jetzt installieren" oder sowas steht. Die Lösung war zu einfach um schnell drauf zu kommen. :-)
du kannst eventuell auch das fenster verschieben, indem du [alt] drückst, um mit maus/links irgendwo auf das fenster klickst.
Dirac I. schrieb: > Bevor ich in der Ubuntu Maschine was installieren kann, muss ja erstmal > Ubuntu selbst (inklusive der Partitionen) installiert worden sein. Wie kommst du darauf? Einfach mit Control+Alt+Fx in ne Konsole wechseln und dort mit apt das Packet installieren. Eventuell X neu starten, danach mit Alt+F7 zurück zur Grafikoberfläche wechseln.
Dirac I. schrieb: > Ich habe auch versucht Ubuntu erstmal von der DVD zu starten und dann > mit einigen Befehlen die Gasterweiterung "zu erzwingen". Aber auch da > bin ich nicht so richtig weitergekommen. Das ist keine besonders aussagekräftige Beschreibung des Problems. > Kann ja eigentlich auch nicht wirklich funktionieren, weil ja noch garkeine > Partitionen erstellt wurden. Das macht nichts. Die Änderungen werden in einer Ramdisk gespeichert. > Auch während der Installation habe ich versucht das Terminal zu > öffnen und mit einigen Befehlen diese Gasterweiterung zu installieren... > ohne Erfolg. Auch das ist keine adäquate Fehlerbeschreibung.
>ich möchte auf meinem Windows 7 Rechner Ubuntu in einer virtuellen >Maschine (Virtualbox) installieren. Mach es umgekehrt: Virtualisiere Dein Windows7, mache die Festplatte platt und installiere das Linux als Host-System. Kanns dann das Windows virtualisiert laufen lassen und wirst sehr bald feststellen, dass Du dies eh nicht mehr brauchst! p.s. Nimm Mint Linux (Cinnamon), basiert auf Ubuntu stabil, solid und alles dabei. (Ich hab diverse Distris (Ubuntu, Xubuntu, Lubuntu etc..) durchprobiert, Mint ist mit Abstand die beste und brauchbarste! https://www.linuxmint.com/ http://www.heise.de/download/linux-mint.html
:
Bearbeitet durch User
Da gibt es mehrere Möglichkeiten die zum Ziel führen: Du könntest dir die Installation sparen und dir Direkt nen fertiges Image laden, z.B. hier: http://virtualboxes.org/images/ubuntu/ Du kannst die Installation ohne GUI machen, da gibts beim Booten nen Parameter für. Oder wie Daniel schon gesagt hat, Installiere erstmal die Gast-tools, indem du entweder zu nem terminal Wechselst und das da machst, oder einfach in nem Terminal-Emulator. Die erste Variante ist wahrscheinlich die einfachste. Grüße, Dirk
Mein Ubuntu habe ich vor etlichen Generationen mit zwei angeschlossenen Monitoren installiert, seither ist der einzige verbundene Monitor als zweiter registriert. Das verursacht immer wieder solche Probleme, weil bei Problemen Ubuntu defaultmäßig auf 640*480 stellt, da Monitor 1 nicht erkannt wurde.
Christoph K. schrieb: > Mein Ubuntu habe ich vor etlichen Generationen mit zwei angeschlossenen > Monitoren installiert, seither ist der einzige verbundene Monitor als > zweiter registriert. Was hindert Dich daran xorg sich das neu konfigurieren zu lassen?
Ich hab mich einfach noch nicht drum gekümmert. Die guten Tips zu diesen conf-Dateien führen meistens ins Leere, weil die ständig wieder anderswo untergebracht werden. Derzeit muss ich auch noch die ACPI auf off stellen, weil der PC sonst abstürzt und neu bootet. Mit dem offenen Grafiktreiber passierte damals dasselbe, deshalb habe ich seither immer den proprietären laufen. Der hat wieder den Nachteil, dass Wine damit nicht läuft. Ein Bios-Update hat die Probleme wenigstens etwas reduziert.
:
Bearbeitet durch User
Vielen Dank für eure Hilfe und eure Vorschläge. Es funktioniert jetzt alles. :-)
Du startest Dein Ubuntu, klickst oben in der Menueleiste bei "Geräte" auf "Gasterweiterungen einlegen", dann erscheint ein CD-Symbol auf dem Desktop. Doppelklick und dann autorun.sh starten (rechte Maustaste und "Ausführen"). Durchklicken, ggf. Neustart und fertig. Geht bei jeder Auflösung.
Christoph K. schrieb: > Ich hab mich einfach noch nicht drum gekümmert. > Die guten Tips zu diesen conf-Dateien führen meistens ins Leere, weil > die ständig wieder anderswo untergebracht werden. Nö. Die liegen seit zwanzig Jahren immer an derselben Stelle. Und wenn Du sie mit den Distributionswerkzeugen neu konfigurierst, werden die immer an den richtigen Ort geschrieben -- den Du dazu nicht einmal kennen mußt. ;-) > Derzeit muss ich auch noch die ACPI auf off stellen, weil der PC sonst > abstürzt und neu bootet. Mit dem offenen Grafiktreiber passierte damals > dasselbe, deshalb habe ich seither immer den proprietären laufen. Der > hat wieder den Nachteil, dass Wine damit nicht läuft. Ein Bios-Update > hat die Probleme wenigstens etwas reduziert. Das ist ein wenig merkwürdig, denn anderswo funktioniert ACPI problemlos. Für Firm- und Hardwareprobleme sind allerdings meistens die Firm- oder Hardware verantwortlich.
Sheeva P. schrieb: > Christoph K. schrieb: >> Ich hab mich einfach noch nicht drum gekümmert. >> Die guten Tips zu diesen conf-Dateien führen meistens ins Leere, weil >> die ständig wieder anderswo untergebracht werden. > > Nö. Die liegen seit zwanzig Jahren immer an derselben Stelle. Und wenn > Du sie mit den Distributionswerkzeugen neu konfigurierst, werden die > immer an den richtigen Ort geschrieben -- den Du dazu nicht einmal > kennen mußt. ;-) Also vor 20 Jahren habe ich sowas noch in die XF86Config geschrieben, später dann in die xorg.conf. Seit einer ganzen Weile habe ich die aber gar nicht mehr. Die Konfiguration wird wohl irgendwie über udev-Magie gemacht oder so. Wo die Config-Files dazu stehen, weiß ich nicht. Kann also keine Rede davon sein, dass das seit 20 Jahren gleich wäre. > Das ist ein wenig merkwürdig, denn anderswo funktioniert ACPI > problemlos. Für Firm- und Hardwareprobleme sind allerdings meistens die > Firm- oder Hardware verantwortlich. Es ist wohl nichts ungewöhnliches, dass das ACPI in vielen BIOSen gravierende Bugs hat, weil ACPI an sich übermäßig komplex ist. Für Windows legen die Hersteller dann einfach entsprechende Treiber bei, die mit den Bugs umgehen können. Unter Linux ist man allerdings darauf angewiesen, dass das ACPI auch korrekt funktioniert, da die Hersteller dafür keine Work-Arounds für die BIOS-Fehler anbieten.
Rolf Magnus schrieb: > Seit einer ganzen Weile habe ich die aber > gar nicht mehr. Die Konfiguration wird wohl irgendwie über udev-Magie > gemacht oder so. Die xorg.conf wird immernoch eingelesen. Es ist nur so dass xorg beim Starten mit einigen Default konfigurationen aus irgendeinem Verzeichnis die fehlenden Teile ergänzen kann, bzw. die Konfig generieren.
Rolf Magnus schrieb: > Sheeva P. schrieb: >> Christoph K. schrieb: >>> Ich hab mich einfach noch nicht drum gekümmert. >>> Die guten Tips zu diesen conf-Dateien führen meistens ins Leere, weil >>> die ständig wieder anderswo untergebracht werden. >> >> Nö. Die liegen seit zwanzig Jahren immer an derselben Stelle. Und wenn >> Du sie mit den Distributionswerkzeugen neu konfigurierst, werden die >> immer an den richtigen Ort geschrieben -- den Du dazu nicht einmal >> kennen mußt. ;-) > > Also vor 20 Jahren habe ich sowas noch in die XF86Config geschrieben, > später dann in die xorg.conf. Seit einer ganzen Weile habe ich die aber > gar nicht mehr. Die Konfiguration wird wohl irgendwie über udev-Magie > gemacht oder so. Wo die Config-Files dazu stehen, weiß ich nicht. Kann > also keine Rede davon sein, dass das seit 20 Jahren gleich wäre. Die Datei wurde in den zwanzig Jahren beim Wechsel von XFree86 auf X.Org einmal umbenannt und heißt jetzt nicht mehr XF86Config, sondern xorg.conf. Sie liegt allerdings immer noch genau dort, wo vor zwanzig Jahren schon die XF86Config lag: in /etc/X11/. Es ist zwar richtig, daß die Datei heute nur noch selten nötig ist, weil die Autokonfiguration in der Regel prima funktioniert. Aber wenn sie vorhanden ist, dann wird sie auch verwendet. Sogar ihre Syntax ist noch weitestgehend dieselbe wie vor zwanzig Jahren. Aber daß die Datei "ständig wieder anderswo untergebracht" würde, wie mein Vorredner behauptet hat: davon kann offensichtlich keine Rede sein. > Es ist wohl nichts ungewöhnliches, dass das ACPI in vielen BIOSen > gravierende Bugs hat, weil ACPI an sich übermäßig komplex ist. Für BIOS-Bugs ist aber trotzdem immer noch der Hersteller verantwortlich, niemand sonst. Bei hochwertiger Hardware habe ich sowas schon sehr lange nicht mehr erlebt; ACPI ist ja auch nicht gerade neu und auch nicht so kompliziert, daß man das nicht fehlerfrei umsetzen könnte. Aber verbugte Hardware ist verbugte Hardware, und wer sowas kauft, ist selbst schuld, wenn es dann nicht richtig funktioniert.
Sheeva P. schrieb: >> Es ist wohl nichts ungewöhnliches, dass das ACPI in vielen BIOSen >> gravierende Bugs hat, weil ACPI an sich übermäßig komplex ist. > > Für BIOS-Bugs ist aber trotzdem immer noch der Hersteller > verantwortlich, niemand sonst. Gut erkannt. > ACPI ist ja auch nicht gerade neu und auch nicht so kompliziert, daß man > das nicht fehlerfrei umsetzen könnte. "Modern PCs are horrible. ACPI is a complete design disaster in every way. But we're kind of stuck with it. If any Intel people are listening to this and you had anything to do with ACPI, shoot yourself now, before you reproduce." (Linus Torvalds) "The fact that it takes more code to parse and interpret ACPI than it does to route traffic on the internet backbones should be a hint something is badly wrong either in ACPI the spec, ACPI the implementation or both." (Alan Cox) Und offenbar war es sogar geplant, ACPI so zu gestalten, dass es für Linux besonder schwer umzusetzen ist: "One thing I find myself wondering about is whether we shouldn't try and make the "ACPI" extensions somehow Windows specific. It seems unfortunate if we do this work and get our partners to do the work and the result is that Linux works great without having to do the work. Maybe there is no way to avoid this problem but it does bother me. Maybe we could define the APIs so that they work well with NT and not the others even if they are open. Or maybe we could patent something related to this." (Bill Gates) Auch interessant: "Wegen Fehlern in der ACPI-Implementierung vieler Hardwarekomponenten muss das Betriebssystem dieses undokumentierte Verhalten mit verschiedenen Methoden korrigieren. Das Betriebssystem Linux gibt sich dem BIOS gegenüber als Windows aus, um den besser getesteten Windows-Modus zu erhalten. Es gibt einen „ACPI-Machine-Language“-Compiler von Intel und einen von Microsoft. Die Hersteller bevorzugen die Microsoft-Implementierung, weil sie besser mit Windows zusammenarbeitet." (von https://de.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface#Kritik ) > Aber verbugte Hardware ist verbugte Hardware, und wer sowas > kauft, ist selbst schuld, wenn es dann nicht richtig funktioniert. Das stellst du dann aber doch etwas übertrieben einfach dar. Schließlich schreibt der Hersteller nicht drauf, ob ACPI richtig funktioniert oder nicht.
Rolf M. schrieb: > Sheeva P. schrieb: >>> Es ist wohl nichts ungewöhnliches, dass das ACPI in vielen BIOSen >>> gravierende Bugs hat, weil ACPI an sich übermäßig komplex ist. >> >> Für BIOS-Bugs ist aber trotzdem immer noch der Hersteller >> verantwortlich, niemand sonst. > > Gut erkannt. Ja, nicht wahr? >> ACPI ist ja auch nicht gerade neu und auch nicht so kompliziert, daß man >> das nicht fehlerfrei umsetzen könnte. > > "Modern PCs are horrible. ACPI is a complete design disaster in every > way. But we're kind of stuck with it. If any Intel people are listening > to this and you had anything to do with ACPI, shoot yourself now, before > you reproduce." > (Linus Torvalds) Das Zitat ist von 2003. Nicht, daß das Design von ACPI seitdem besser geworden wäre, aber es war schon vor dreizehn (13) Jahren klar, daß ACPI nicht mehr so schnell weggehen würde, und man damit leben und sich darauf einstellen mußte. Das ist offensichtlich geschehen, denn mit ordentlicher Hardware funktioniert es ja wunderbar -- und mit einer ganzen Reihe von problematischer Hardware ebenfalls. Und wenn es wirklich ganz und gar nicht will, kann man es sogar mit einem Kernelparameter ausschalten... Im Übrigen scheinst Du mich gründlich mißverstanden zu haben. Ich habe nur der Andeutung des OP widersprochen, der die Design- und Umsetzungsfehler von ACPI nicht den Designern und Umsetzern, sondern Linux vorgeworfen hat. Das ist im Moment so eine kleine Mode geworden, bei allem, was nicht wie gewünscht funktioniert, gleich zu kreischen, daran sei Linux schuld. Dabei liegt es in Wahrheit in 80% aller Fälle an OSI-Layer 8 und in 19,99% der übrigen Fällen an kaputter oder besch___ener Hardware. >> Aber verbugte Hardware ist verbugte Hardware, und wer sowas >> kauft, ist selbst schuld, wenn es dann nicht richtig funktioniert. > > Das stellst du dann aber doch etwas übertrieben einfach dar. Schließlich > schreibt der Hersteller nicht drauf, ob ACPI richtig funktioniert oder > nicht. Du verläßt Dich beim Kauf von Hardware ausschließlich auf die Angaben der Hersteller? Hm, ich verfolge da einen anderen Ansatz.
Dass ACPI an meinen unerklärlichen Ubuntu-Problemen schuld ist, habe ich erst nach dem letzten Update herausgefunden, ich habe das keineswegs Ubuntu angelastet. Ein "xorg.conf" hat Ubuntu bei mir überhaupt nicht angelegt, es gibt ein xorg.conf.failsafe, ein xorg.conf.original (da steht eignetlich nichts drin) und ein anscheinend gültiges xorg.conf.11082014 oder so ähnlich. Dort ist die Monitorerkennung auf "automatisch" gestellt, was anscheinend bei Abstürzen zu Fehlern führt.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.