FreeBSD 14.3 - in VM, neuer Anlauf, UTM/QEMU oder VMware Fusion & weitere Fragen

Der große Unterschied, du verwendest die amd64 Version (auf Intel Mac?), ich aber die aarch64 ARM (läuft auf Apple Silicon)
Ab einer gewissen Version von FreeBSD lief nach Upgrades bestehender und funktionierender VMs nichts mehr.
Wenn ich mehr Zeit habe will ich FreeBSD unter VMware Fusion probieren.
 
Code: 
/etc/rc.conf
Bildschirmfoto 2025-09-09 um 18.20.12.webp
 
Bei reiner FreeBSD Installation:
Code: 
pkg install xorg ctwm xdm
startx

"Server Error"

Was ich schon alles probierte, kommt immer aufs gleich raus!

Ich verwende die ARM Version!

----------

Now the same under VMware Fusion: (scheint tatsächlich irgendwie ein UTM/QEMU Problem zu sein - (!! ich verwende die FreeBSD ARM Version !!)

FreeBSD VMware Fusion.webp
 
Wenn ich recht verstehe, scheint es doch mit QUEMU bei @dettus zu funktionieren.
Die Fehlermeldung bei deinem letzten Post der xorg.0.log sagte ja, dass das Modul virtio nicht gefunden werden konnte. Wie ich das sehe, sind die virtio-Module keine externen Grafik-Treiber, denn sie liegen in /boot/kernel. Also ähnlich, wie vesa.ko, das ja auch hier liegt und das man vielleicht deshalb als eine Art System-Standard bezeichnen könnte.
Der X scheint ganz offenbar zu wissen, dass er dieses Modul für die gefundene (QUEMU)-Karte braucht, kann es aber dann nicht laden, während es bei @dettus funktioniert hatte. Man kann sich eigentlich kaum vorstellen, dass so ein Verhalten ARM-spezifisch sein soll.

Vielleicht kannst du gezielt in einer xorg.conf mal den vesa setzen und sehen, ob der dann geladen wird.
 
Das scheint eine AMD Version zu sein, ich verwende aber ARM
Vielleicht kannst du gezielt in einer xorg.conf mal den vesa setzen und sehen, ob der dann geladen wird.
Zum Vergrößern anklicken....
Ein Hinweis in welcher wäre da hilfreich
-----
Der Grundstein in Fusion ist nun gelegt, werd sicherheitshalber einen Kopie davon machen um ggf. wieder vom Neuen zu beginnen die GUI zu installieren.
VMware Fusion bietet zwar auch Snapshots an, aber am Mac ich eine Kopie nur Mausklick weit.

Hab mal 2 Kerne und 4GB RAM zugewiesen.
 
Zuletzt bearbeitet:
fredfrommac schrieb:
Ein Hinweis in welcher wäre da hilfreich
Zum Vergrößern anklicken....
das ist eigentlich egal, es sei denn, du hast mehrere und setzt darin sich widersprechende Dinge. Dann käme es auf die Reihenfolge an, denn die zuletzt gelesene würde sich durchsetzen.
Hattest du nicht zuvor schon mal von einer config geschrieben, ich meine sogar eine mit drivers?
 
Sorry .... manchmal vergisst man Dinge
(==) Using config directory: "/usr/local/etc/X11/xorg.conf.d
(==) (EE) Using system config directory: "/usr/local/share/X11/xorg.conf.d

Erstes Verzeichnis ist leer - da erstellte ich nun 2-vesa.conf
mit dem Inhalt von https://docs.freebsd.org/en/books/handbook/x11/#x-config
Example 5. Select VESA Graphics Driver in a File

Zweites Verzeichnis enthält 10-quirks.conf 20-evdev-kbd.conf 40-libinput.conf
 
wenn ich deinen weiter oben verlinkten Beitrag zur Problemlösung richtig im Kopf habe, wurde dort der scfb-Treiber benutzt. Ist auch im Handbuch beschrieben.
Generell braucht es aber überhaupt keine x.configs und wenn man sie benutzt, sollte man wissen, was man damit will.

Es wäre vielleicht nicht schlecht, wenn du alle verwendeten x.configs mal posten könntest oder erst mal alle weglassen würdest, nur, um mal zu sehen...
Dann nur den vesa und dann nur den scfb mal probieren und ebenfalls sehen. Damit meine ich, nicht nur hinsehen, sondern die xorg.0.log ansehen.
 
Funktioniert xf86-video-scfb auch in einer ARM Umgebung?

PS: Unter VMware Fusion läuft FreeBSD mit Mate ganz passabel, nur einige Einstellungen muss ich noch anpassen, Tools & Programme fehlen.
 
pit234a schrieb:
wenn ich deinen weiter oben verlinkten Beitrag zur Problemlösung richtig im Kopf habe, wurde dort der scfb-Treiber benutzt. Ist auch im Handbuch beschrieben.
Generell braucht es aber überhaupt keine x.configs und wenn man sie benutzt, sollte man wissen, was man damit will.

Es wäre vielleicht nicht schlecht, wenn du alle verwendeten x.configs mal posten könntest oder erst mal alle weglassen würdest, nur, um mal zu sehen...
Dann nur den vesa und dann nur den scfb mal probieren und ebenfalls sehen. Damit meine ich, nicht nur hinsehen, sondern die xorg.0.log ansehen.
Zum Vergrößern anklicken....

Wie kann man diese Dateien für das System unlesbar machen ohne diese zu löschen oder zu verschieben - nur mit Namen ändern?
 
ehrlich gesagt: ich glaub, es wird am einfachsten und sinnvollsten sein, wenn du unter VMWARE weiter machst.
Wozu erst noch mit QUEMU plagen, wo es so viele Berichte von Leuten gibt, bei denen es nicht funktioniert hat? Es gibt da schließlich doch keine Garantie, dass man es nach großer Anstrengung damit überhaupt hin bekommt.

Wenn du damit besser klar kommen willst, ist es mit die wichtigste Sache, die Information aus der Xorg.0.log zu lesen und richtig zu deuten.
Ich kann das nicht anhand deiner Bilder.
Im letzten Bild sieht man nun zwar einige EE-Zeilen, aber ich fürchte, dass davor schon wichtige Dinge passiert sind, die dieses Verhalten vielleicht erklären können. Vielleicht auch nicht. Immerhin sind alle von dir verlinkten Seiten mit Lösungen nicht so weit gegangen, ihre Logs mal zum Vergleich zu posten und hier scheint auch niemand eine konkrete Erfahrung zu haben, die dir schnell weiter helfen könnte.
 
Du wirst zumindest eine minimale Config brauchen:

Code: 
Section "Device"
  Identifier "Card0"
  Driver "scfb"
EndSection
Denn ohne die geht er auf xf86-video-modesetting und das scheitert am fehlenden KMS für die Grafikkarte durch den Kernel. Wenn das nicht hilft, bin ich ratlos und würde "geht nicht" sagen.
 

@Yamagi is Possessed With Psi Powers​

Deshalb macht man, wozu er einem rät!

Ich hatte irgendwie das Gefühl, dass vorher die Karte womöglich nicht am rechten Platz erkannt wird und dass man das deshalb einer config vielleicht mitgeben sollte. Das sieht man aber nur, wenn man die Xorg.0.log vernünftig lesen kann.

Yamagi schrieb:
Code:
Code: 
Section "Device"
  Identifier "Card0"
  Driver "scfb"
EndSection
Zum Vergrößern anklicken....
würde dann etwa so aussehen:

Code: 
Section "Device"
  Identifier "Card0"
  Driver "scfb"
  BusID "PCI:0:2:0"
EndSection
Wobei ich nun die von dir veröffentlichte Adresse aus dem Kopf eingefügt habe, also bitte zuvor prüfen, wenn überhaupt....
 
pit234a schrieb:

@Yamagi is Possessed With Psi Powers​

Deshalb macht man, wozu er einem rät!
Zum Vergrößern anklicken....
Nein, das brauchte keine Psi-Kräfte. Ich musste nur meinen Link lesen ;) Aber guter Tipp mit der BusID. Das steht ja sogar in dem Screenshot mit der Log drin, was ich dann selber überlesen bzw. übersehen habe... -_-
 
Grundsätzlich ist die Anleitung https://docs.freebsd.org/en/books/handbook/preface/ nicht schlecht, nur scheint mir diese in manchen Sachen nicht gerade aktuell zu sein. Befasse mich nun schon seit Jahren mit FreeBSD. Damals noch auf Intel Mac und VirtualBox. Hatte FreeBSD + Mate laufen, ab einem gewissen FreeBSD Upgrade ging nichts mehr. Trotz intensiver Internet Recherchen und diversen Postings in Foren konnte ich dies nicht lösen. Vorherige Upgrades funktionierten noch mit einigen Anpassungen.
Nach dem Switch auf Apple Silicone / ARM ist das unter VMware Fusion nun die erste Version die mit einer GUI, in dem Fall Mate, läuft.
Was noch lästig ist, dass die Maus nicht automatisch freigegeben wird denn ich das VM Fenster verlassen will, unter UTM geht das problemlos.
Auch funktioniert die Vergrößerung des Bildschirms noch nicht, usw. Da muss ich wohl den default Bildschirm vergrößern.
Laufen unter Mate auch Tools die eigentlich für GNOME geschrieben sind, ohne gleich GNOME selbst zu installieren. Oder GDE anstatt lightdm?

Leider gibt es GhostBSD nur für Intel/AMD. Laut Anfrage fehlt denen die Kapazität auch eine ARM/aarch64 Version heraus zu bringen.

OpenIndiana (OpenSolaris) wäre noch interessant, hatte ich vor Jahren in einer VM mal laufen, aber auf den älteren Intel Mac ziemlich langsam. Wird das noch weiterentwickelt?
 
Nur zur Information, bin nicht beruflich damit befasst, reizt mich mit FreeBSD (und anderen OS) nur Interesse Halber zu beschäftigen. Ist nichts produktives geplant.

Auf meinem alten MacBook “white“ 5.2 early 2009, 4GB RAM 500GB SSD läuft seit einiger Zeit Debian Trixie, das gar nicht so schlecht. Sogar WLAN und Trackpad funktionieren, Bluetooth leider nicht, hatte schon unter ElCapitan Probleme mit neuen Bluetooth Geräten.
 
mr44er schrieb:
forum.proxmox.com

VM Guest: OS Type: FreeBSD

Id like to suggest creation/addition of OS Type: FreeBSD. The only real setting I'm aware of, and my therefore make this irrelevant, is: FreeBSD supports UEFI. FreeBSD does NOT support Secure Boot. ...Yet. Suggestion being: Adding a selection item for OS Type = FreeBSD. This would set a...
forum.proxmox.com forum.proxmox.com
Zum Vergrößern anklicken....

Ziemlich viel anzupassen, vielleicht wenns mich mal juckt, könnte ich das mit einem Clone der VM durchspielen.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben