NetBSD(-Probleme) auf einem X201 als Newbie

[nikolas777]

Servus euch,
Vor ca. zwei Wochen habe ich spaßeshalber mal NetBSD 10.1 auf meinem ThinkPad X201 installiert, mal einfach so aus reiner Neugier und um mal den Umgang mit *nix-Systemen außerhalb von macOS und Linux weiter zu erlernen.
Ziel des ganzen (Noch-)Experiments ist es für mich NetBSD als "Desktop"-OS einzurichten und nebenbei zu verwenden.

Installationsprozess lief erstaunlicherweise gut, dafür dass ich noch WLAN im Installer einrichten musste. Überraschenderweise nicht viel komplizierter als systemd-lose Linux-Distros, die im Installer nicht NetworkManager mitpacken.
Installiert habe ich soweit ich mich erinnern kann das "volle Paket" mit X11/ctwm, pkgin. Ansonsten müsste so gut wie alles Default geblieben sein.

Nach der Installation habe ich meine Standard-Anwendungen installiert (opendoas, vim, zsh, git, Firefox, mpv, pcmanfm, zathura und sonst noch einiges) um mal ein Gefühl für das OS zu kriegen. Ersteindruck ist nicht schlecht; dafür, dass NetBSD sich in einer Niche einer Niche (einer Niche) positioniert. Es fühlt sich nicht schrecklich langsam an, Pakete lassen sich dank pkgin wie auf jedem Linux-System bequem installieren und Sound scheint OOB zu funktionieren, auch wenn ich nicht dazu gekommen bin, die Lautstärke (per Keybind) anpassen zu können.

Schnell sind mir aber doch einige Probleme aufgefallen:
1. Grafik bzw beschleunigte Grafik funktioniert nicht wirklich
Zwar ist die Auflösung richtig, aber der Start einer OpenGL-Anwendung (in meinem Fall glxgears, mpv, SuperTux und ClassiCube) lässt das System kurz einfrieren, und wenn das Programm nicht abstürzt läuft alles SEHR langsam oder hat korrupte Grafik wie kaputte Textboxen etc als Folge.
Ich dachte mir, dass eine 10-intel.conf in /etc/X11/xorg.conf.d/ mit folgendem Inhalt helfen kann:

Section "Device"
    Identifier "Intel Graphics"
    Driver "intel"
    Option "AccelMethod" "uxa"
    Option "DRI" "2"
EndSection

Damit hat zwar SuperTux kein Ruckeln mehr ausgelöst, aber nach Beenden hatte ich immer noch kaputten Text zur Folge. MPV und selbst glxgears haben sich dadurch nicht verbessert. Stand jetzt ist das mein größtes Problem.
Ich habe etwas von DRM/DRI gelesen, aber ich verstehe nicht so ganz, ob es bereits integriert ist im GENERIC Kernel, oder ob ich besser mal meinen eigenen Kernel bauen sollte.

2. Scrollen mit dem TrackPoint durch Halten der mittleren Maustaste
Wäre nett, wenn mir jemand helfen könnte, wie es unter NetBSD geht.

3. Der Beeper ist SEHR laut
Ein- und Ausstecken vom Ladekabel macht mich fast taub, sowas hatte ich unter Linux nicht.

4. Powermanagement
Habe mich einfach bisher nicht damit beschäftigt, aber wäre vielleicht ganz cool, wenn einer von euch weiß, worauf ich achten soll. Habe etwas von powerd und sysctl gelesen, aber das nehme ich sowieso erst in Angriff sobald ich funktionierende Grafik habe.


Ansonsten habe ich eher eine Frage als ein Problem, nämlich was es mit den Ports/pkgsrc auf sich hat, denn bisher hatte ich die nur kurz bei FreeBSD und OpenBSD benutzt, aber noch nicht hier auf NetBSD. Sind Ports und pkgsrc das gleiche? Ist pkgsrc überflüssig wenn man Pakete per pkgin installiert? Also beziehen sich pkgin und pkgsrc auf dieselben Quellen? Und welchen Vorteil hat man denn mit Ports oder pkgsrc?


Aufgeben will ich NetBSD nicht so schnell, da es doch irgendwo ein angenehmes System ist, obwohl es nicht einem so sehr die Hände wie manch Linux-Distro hält. Leider gibt es nicht allzu viele Online-Ressourcen und mMn sind die man-pages und der NetBSD-Guide nicht ausführlich genug, um "auf den richtigen Weg zu kommen".

Danke im Vorraus und GaLiGrü

 

[cabriofahrer]

1. Grafik bzw beschleunigte Grafik funktioniert nicht wirklich

Ist Dein User in der Gruppe "video"? Was sagt id? Wie verhält es sich, wenn Du X als Root startest?

Sind Ports und pkgsrc das gleiche? Ist pkgsrc überflüssig wenn man Pakete per pkgin installiert?

Ja, ich glaube pkgsrc ist das Gleiche wie die Ports bei FreeBSD. Allerdings stellt NetBSD relativ wenige Packages per pkgin zu Verfügung, deshalb wird man gewisse Dinge nur in pkgsrc finden.
Die Anleitung von NetBSD ist aber nicht so schlecht.

 

[nikolas777]

Erstmal Danke für deine Antwort.

Ist Dein User in der Gruppe "video"? Was sagt id? Wie verhält es sich, wenn Du X als Root startest?

ID spuckt folgendes aus:

uid=1000(nikolas) gid=100(users) groups=100(users),0(wheel)

Tatsächlich scheint es keine "video"-Gruppe zu geben, zumindest kann ich meinen Nutzer per usermod -G video nikolas nicht hinzufügen und cat /etc/group | grep video bleibt auch leer.
Ich denke ich habe das Problem auf OpenGL zurückführen können, immerhin scheint der Desktop nicht extrem langsam zu sein und die Lags treten erst auf, wenn irgendwas mit OpenGL passiert soweit ich feststellen konnte.
Wenn ich SuperTux in der Konsole per supertux2 --renderer sdl starte, läuft es ohne Probleme. Sobald ich aber --renderer opengl verwende, stürzt das Spiel sofort ab mit folgender Meldung:

[FATAL] /pbulk/work/games/supertux/work/SuperTux-v0.6.3-Source/src/supertux/main.cpp:672 Unexpected exception: GLVideoSystem: GlewError: Missing GL version

Ob ich das als User oder Root mache, scheint auch keinen Unterschied zu machen.

Die Anleitung von NetBSD ist aber nicht so schlecht.

Ich sag mal so, ich bin halt sehr das Arch-Wiki gewohnt und es ist doch sehr ausführlich und so gut wie zu jedem Problem gibt es einen Eintrag, soll jetzt aber nicht heißen, dass NetBSDs Ansatz schlecht ist. Da hab ich schon viel schlimmeres aus der Linux-Welt gesehen. NetBSD hat halt Leute wie mich nicht als Zielgruppe, was ja ok ist. Ich bin aber auch aus einer anderen Generation, da hat man es nicht so mit "ausführlich lesen" und "selber recherchieren" (da bin ich froh, zumindest etwas Eigenleistung reingesteckt zu haben)

 

[cabriofahrer]

usermod -G video nikolas

Also zumindest im FreeBSD Handbook sieht der Befehl so aus: pw groupmod video -m username
In der Anleitung von NetBSD habe ich leider nichts dazu gefunden. Aber vielleicht hilft das hier:

drm(4) - NetBSD Manual Pages

man.netbsd.org

Ist drm überhaupt installiert? Ich habe keine Ahnung, was NetBSD standardmässig installiert, wenn man in sysinst die Installation vom X Window System auswählt.

Edit: Der o.g. Befehl unter NetBSD scheint doch korrekt zu sein:

Chapter 5. The first steps on NetBSD

Ich tippe also darauf, dass bei Dir noch nicht alles gegeben ist, wie in der man page von drm beschrieben ist.

 

[nikolas777]

Ist drm überhaupt installiert? Ich habe keine Ahnung, was NetBSD standardmässig installiert, wenn man in sysinst die Installation vom X Window System auswählt.

Ich tippe also darauf, dass bei Dir noch nicht alles gegeben ist, wie in der man page von drm beschrieben ist.

libdrm scheint standardmäßig installiert zu sein über sysinst, zumindest gibt pkgin search libdrm nur suse_libdrm-Pakete zurück, und der Versuch libdrm über pkgsrc zu installieren gibt einen Fehler:

ERROR: This package has set PKG_SKIP_REASON:
ERROR: Package set is using native X11 component

Verstehe ich hier richtig, dass damit impliziert wird, dass libdrm bereits gebundled ist? Selbes passiert mir auch, wenn ich versuche xf86-video-intel per pkgsrc zu installieren.

Jedenfalls habe ich mich heute nochmal rangesetzt und das ergänzt, was mir aus der man-page fehlt. Scheinbar war das nur DRI in der X Config zu aktiveren. Also die Datei /etc/X11/xorg.conf.d/10-drm.conf mit folgendem Inhalt erstellt:

 Section "Module"
    Load  "dri"
    Load  "dri2"
    Load  "glx"
EndSection

Section "DRI"
    Group "wheel"
    Mode 0660
EndSection

Laut grep LoadModule /var/log/Xorg.0.log werden die Module nach einem X11-Neustart definitiv geladen, und glxinfo -B bestätigt mir auch, dass DRI eigentlich aktiviert sind (wobei ich nicht mehr weiß, ob es vorhin anders war):

name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel Open Source Technology Center (0x8086)
    Device: Mesa DRI Intel(R) Ironlake Mobile  (0x46)
    Version: 19.1.17
    Accelerated: yes
    Video memory: 384MB
    Unified memory: yes
    Preferred profile: compat (0x2)
    Max core profile version: 0.0
    Max compat profile version: 2.1
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 2.0
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Ironlake Mobile
OpenGL version string: 2.1 Mesa 19.1.17
OpenGL shading language version string: 1.20

OpenGL ES profile version string: OpenGL ES 2.0 Mesa 19.1.17
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16

Aber trotzdem selbiges Verhalten von mpv. SuperTux und glxgears. Ein Blick in dmesg zeigt irgendwas von wegen stopped heartbeats und context resets (dmesg reduziert mit grep drm):

[     1.018976] i915drmkms0 at pci0 dev 2 function 0: Intel Iron Lake Integrated Graphics Device (rev. 0x02)
[     2.988535] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[     2.988535] [drm] Driver supports precise vblank timestamp query.
[     2.988535] i915drmkms0: interrupting at msi4 vec 0 (i915drmkms0)
[     3.018535] [drm] Initialized i915 1.6.0 20200114 for i915drmkms0 on minor 0
[     3.038536] intelfb0 at i915drmkms0
[     3.038536] [drm] DRM_I915_DEBUG enabled
[     3.038536] [drm] DRM_I915_DEBUG_GEM enabled
[    32.558535] warning: /usr/src/sys/external/bsd/drm2/dist/drm/i915/gt/intel_engine_cs.c:1234: WARN_ON_ONCE(hex_dump_to_buffer(buf + pos, len - pos, rowsize, sizeof(u32), line, sizeof(line), 0) >= sizeof(line))
[    32.558535] i915drmkms0: notice: Resetting chip for stopped heartbeat on rcs0
[    32.558535] i915drmkms0: notice: glxgears[1692] context reset due to GPU hang
[   230.308536] i915drmkms0: notice: Resetting chip for stopped heartbeat on rcs0
[   230.308536] i915drmkms0: notice: mpv[4258] context reset due to GPU hang
[   236.348536] i915drmkms0: notice: Resetting chip for stopped heartbeat on rcs0
[   236.348536] i915drmkms0: notice: mpv[4258] context reset due to GPU hang
[   242.388536] i915drmkms0: notice: Resetting chip for stopped heartbeat on rcs0
[   242.388536] i915drmkms0: notice: mpv[4258] context reset due to GPU hang
[  1173.168535] i915drmkms0: notice: Resetting chip for stopped heartbeat on rcs0
[  1173.168535] i915drmkms0: notice: glxgears[3678] context reset due to GPU hang
[  1179.168535] i915drmkms0: notice: Resetting chip for stopped heartbeat on rcs0
[  1179.168535] i915drmkms0: notice: glxgears[3678] context reset due to GPU hang

Was mir aufgefallen ist: die man-page erwähnt, dass options DRM_DEBUG DRI "erheblich verlangsamen soll" und dmesg zeigt mir ja scheinbar, dass Debugging aktiviert ist. Kann ich das auch per config deaktivieren, oder ist das fest im Generic-Kernel aktiviert und nur durch Selbstbauen des Kernels zu lösen?

(Un)Glücklicherweise konnte ich nach kurzer Suche finden, dass ich wohl nicht der einzige mit diesem Problem bin. Zumindest sind einige der Symptome beschrieben, die ich auch erlebe. Stellt sich nun die Frage, ob das also ein Problem bei meiner Konfiguration oder tatsächlich bei NetBSD selbst ist.

 

[cabriofahrer]

Was mir aufgefallen ist: die man-page erwähnt, dass options DRM_DEBUG DRI "erheblich verlangsamen soll" und dmesg zeigt mir ja scheinbar, dass Debugging aktiviert ist. Kann ich das auch per config deaktivieren, oder ist das fest im Generic-Kernel aktiviert und nur durch Selbstbauen des Kernels zu lösen?

In der man page selbst steht ganz unten:

"Debugging output can be enabled and disabled by setting the sysctl(8)
node hw.dri.debug. Additional information can be obtained from the
sysctl(8) nodes hw.dri, hw.dri.card0, hw.dri.card1, etc."

Vor ca. zwei Wochen habe ich spaßeshalber mal NetBSD 10.1 auf meinem ThinkPad X201 installiert, mal einfach so aus reiner Neugier und um mal den Umgang mit *nix-Systemen außerhalb von macOS und Linux weiter zu erlernen.
Ziel des ganzen (Noch-)Experiments ist es für mich NetBSD als "Desktop"-OS einzurichten und nebenbei zu verwenden.

Vielleicht ist das Experiment mit NetBSD auf dem X201 doch nicht so spaßig? Um den Umgang mit *nix-Systemen außerhalb von MacOS und Linux weiter zu erlernen, ist vielleicht auf diesem Laptop (Baujahr 2000) FreeBSD die bessere Wahl? Da sollte es mit der 3D-Beschleunigung keine Probleme geben. Probiere mal eine Installation mit dem "mini-memstick" Image von 14.1(!), nicht 14.2, weil das drm-Modul für 14.1 kompiliert ist, siehe z.B. hier:

FreshPorts -- graphics/drm-515-kmod: DRM drivers modules

amdgpu, i915, and radeon DRM drivers modules. Currently corresponding to Linux 5.15 DRM. This version is for FreeBSD 14.0 and above.

www.freshports.org

Welches der Module (510, 515, 61 oder 66) nun das beste für den Iron Lake ist, weiß ich nicht.
Mit dem mini-memstick kann man gleich bei der Installation schon das WLAN konfigurieren, bzw. sehen, ob es überhaupt unterstützt wird, bevor man mit der eigentlichen Installation beginnt.

NetBSD ist eigentlich nur interessant, wenn man Hardware hat, die von FreeBSD nicht unterstützt wird, wohl aber eben von NetBSD. Dabei handelt es sich aber meist um sehr alte und komische Fritten.

 

[nikolas777]

In der man page selbst steht ganz unten:

"Debugging output can be enabled and disabled by setting the sysctl(8)
node hw.dri.debug. Additional information can be obtained from the
sysctl(8) nodes hw.dri, hw.dri.card0, hw.dri.card1, etc."

Das habe ich auch vor dem Posten des Beitrags eingestellt, keine Sorge. Aber ich meine mich erinnern zu können, dass Debug-Builds - mal hiervon abgesehen - generell langsamer sein sollen. Kann aber selbst nicht sagen ob es hauptsächlich daran liegt, dass neben der eigentlichen Ausführung noch nebenbei Sachen ausgegeben werden. Daher kam meine Frage.

Vielleicht ist das Experiment mit NetBSD auf dem X201 doch nicht so spaßig? Um den Umgang mit *nix-Systemen außerhalb von MacOS und Linux weiter zu erlernen, ist vielleicht auf diesem Laptop (Baujahr 2000) FreeBSD die bessere Wahl?

NetBSD ist eigentlich nur interessant, wenn man Hardware hat, die von FreeBSD nicht unterstützt wird, wohl aber eben von NetBSD. Dabei handelt es sich aber meist um sehr alte und komische Fritten.

Also Spaß hatte ich schon und bisschen dazu gelernt habe ich auch, würde es zumindest nicht als vergeudete Zeit sehen, insbesondere da es sich eh nicht um mein Main-Gerät handelte. FreeBSD ist mir tatsächlich irgendwo zu "langweilig"; klar ist FBSD irgendwo "rationaler", aber noch will ich auch bisschen Spaß am Verwenden von Computern haben. Ist auch derselbe Grund warum ich als Linux kein Ubuntu, Debian oder Fedora benutze; irgendwas reizt mich an den """Schwierigkeiten""".
Verwunderlich finde ich es trotzdem, dass Hardware aus dem Jahre 2010 doch noch Probleme macht, aber naja. Wenn NetBSD nix wird, probiere ich es erst mit OpenBSD. Je nach dem wie das läuft, bleibt es dabei oder FreeBSD ist an der Reihe. Ansonsten hätte ich noch einen meiner zwei PowerBook G4s, die geeigneter für Net- oder OpenBSD wären.


Ich denke als letzte Option probiere ich mal mir ein modulares X aus den pkgsrc-Sourcen und einen eigenen Kernel zu bauen, wenn das nicht klappt, sehe ich das Experiment vorerst als gescheitert. Selbstverständlich werde ich über die Ergebnisse berichten.

 

[Andy_m4]

Aber ich meine mich erinnern zu können, dass Debug-Builds - mal hiervon abgesehen - generell langsamer sein sollen.

Ja. Wobei das zwei (letztlich sogar drei) Aspekte hat:
Der eine ist der, das in den Binaries Debug-Symbols eingefügt werden, was auf die Laufzeit erst mal nicht so dramatisch viele Auswirkungen hat, aber die Dateien größer werden lässt (Debug-Symbols kriegt man auch im nachhinein noch raus, wenn man z.B. strip(1) benutzt).
Ein größeren Performance-Impact hat aber die Tatsache, das man bei Debug-Builds auch gerne mal Compiler-Optimierungen ausschaltet (weils das Debugging behindern kann). Und das kostet dann schon deutlich mehr.

Wenn Du dazu auch noch Debug-Ausgaben hast (auf Konsole, auf Datei oder wohin auch immer), dann kostet das natürlich auch noch mal spürbar Zeit. Wobei Debug-Ausgaben nicht unbedingt und in jedem Fall zwingend Debug-Builds erfordern. Kommt drauf an, wie es das jeweilige Programm/Modul/Bibliothek realisiert hat.

Ich hoffe, damit hab ich ein paar Klarheiten beseitigt. ;-)

 

[sterum]

Vielleicht eine blöde Frage, aber hast du eigentlich mesa installiert?

 

[bsdfreak]

Probier doch OpenBSD aus, um Dir einen ersten Eindruck zu verschaffen. Aber vermutlich ist es Dir zu langweilig, weil es einfach zuverlässig funktioniert. An NetBSD haben sich schon andere Experten (wie Clas) mit Kompetenz die Zähne ausgebissen. Kann mich nicht daran erinnern, das irgendwer dauerhaft bei NetBSD geblieben wäre. Für mich ist OpenBSD die erste Wahl, die Gründe sind bekannt.

 

[dettus]

Probier doch OpenBSD aus, um Dir einen ersten Eindruck zu verschaffen. Aber vermutlich ist es Dir zu langweilig, weil es einfach zuverlässig funktioniert. An NetBSD haben sich schon andere Experten (wie Clas) mit Kompetenz die Zähne ausgebissen. Kann mich nicht daran erinnern, das irgendwer dauerhaft bei NetBSD geblieben wäre. Für mich ist OpenBSD die erste Wahl, die Gründe sind bekannt.

Sicher, OpenBSD ist einfacher.... Aaaaaaaaber: Wo bleibt denn da die Herrausforderung?
Man waechst ja schliesslich mit seinen Aufgaben!!!!
Weil ich ein aehnlich gelagertes Problem habe, habe ich z.B. gerade meinen ersten Pull Request ins NetBSD-Repository eingebracht!

 

[nikolas777]

Vielleicht eine blöde Frage, aber hast du eigentlich mesa installiert?

Mesa habe ich installiert, insofern MesaLib alles beinhaltet.


Ich bin aber doch noch einen Schritt weitergekommen.
Gestern habe ich erst den Kernel rekompiliert (dabei andere DRI-Treiber außer der von Intel und noch paar andere Geräte rausgeschmissen), mit keiner Änderung; hätte ich mir auch denken können.
Dann habe ich nach dieser Anleitung alle X-Sets entfernt, dasmodular-xorg-Metapaket über pkgsrc installiert und XFCE4 über Nacht kompilieren lassen. In der tty startxfce4 ausgeführt, Terminal geöffnet, Ausgabe von glxinfo abgecheckt. glxinfo und glxgears nicht gefunden, scheinbar mit den Sets entfernt. Also ebenso glx-utils per pkgsrc installiert, und glxinfo scheint bei dem Intel Mesa DRI-Gerät zu bleiben und nicht aufs llvmpipe-Fallback auszuweichen. Dann die eigentliche Prüfung glxgears... und es funktioniert? Keine Bildfehler, kein Aufhängen des Systems etc. Soweit so gut, also SuperTux und mpv abgecheckt und... selbes Problem wie am Anfang.
Meine Vermutung: Das Entfernen der X-Sets ist entweder nicht vollständig passiert (die werden in /etc/mtree noch gelistet), oder ich benutze noch irgendwelche Konfigurationen von der Installation, die mir alles ruinieren. Genauso ist mir aufgefallen, dass meine /etc/X11/xorg.conf.d/-configs beim Start mit startx oder startxfce4 ignoriert werden (Tastatur bspw. bleibt trotz config auf Englisch), und dass ich auf einmal nicht mehr dmesg als User aufrufen kann, obwohl es vorher geklappt hat.
Dieser kleine Erfolg hat mir aber nochmal die Motivation gegeben, NetBSD komplett neuzuinstallieren (eigentlich wäre es besser, wenn ich herausfinde, wo wirklich was schief gegangen ist, aber hey, man muss es sich ja nicht unendlich kompliziert machen), dieses mal aber ohne die X11-Sets. Gut, dass ich zur Zeit Semesterferien habe


@bsdfreak @dettus
Wie gesagt, das Experiment NetBSD geht vorerst weiter, OpenBSD kommt dann, wenn ich absolut nicht mehr weiter weiß. Leider habe ich auch nicht die tiefergehende Expertise um die bestehenden Probleme konkret zu analysieren und ggf die Lösungen der Community beizusteuern. Aber immerhin kann/konnte ich mich amüsieren.

 

[nikolas777]

Kleines Update:
Tagsüber noch die Neuinstallation ohne X11-Sets vorgenommen und stattdessen auf modulares X über pkgsrc gesetzt. Stellt sich heraus, dass man keine grafischen Anwendungen per pkgin mehr installieren kann, da die Binaries logischerweise auf das native X setzen (hängen beispielsweise von libs in /etc/X11R7/libs/ ab, die logischerweise nicht durch das modulare X gestellt werden). Ist doch ein größeres Problem für mich, da große Anwendungen wie Firefox nämlich nicht so spaßig auf so einem alten Laptop zu kompilieren sind.
Nach ewigem Kompilieren konnte ich auch SuperTux mit --renderer opengl testen... ohne Erfolg. mpv hingegen konnte endlich Videos abspielen, ohne den X-Server einzufrieren oder Grafikfehler zu erzeugen. Das zeigt zumindest, dass NetBSD nicht fundamental kaputt ist, was es DRI angeht.
Mal sehen, ob ich natives X doch noch so zum Laufen kriege, wie ich es will - würde mir zumindest ewig langes Kompilieren ersparen.

 

[nikolas777]

(Vorerst?) Letztes Update und "Fazit" zu meinem Experiment:
Ich werde wohl NetBSD mit OpenBSD ersetzen müssen. Ich bin doch noch ein letztes Mal auf die nativen X-Sets gewechselt, meine xorg.conf.d-Configs sorgfältig geprüft, mehrere Optionen probiert etc, aber DRI will einfach nicht. Beim besten WIllen begreif ich nicht, woran es liegt, schließlich funktioniert es reibungslos mit dem modularen X aus pkgsrc.
Nur um auszuschließen, dass es sich um die Hardware selbst handelt, habe ich die NetBSD-SSD in mein X61 gepackt, und damit hatte ich dieselben X/DRI-Probleme wie auf meinem X201.

Nichtsdestotrotz hat mir NetBSD irgendwo auch Spaß gemacht und irgendwo gefällt es mir, wie "roh" es doch ist. Leider kam ich nicht dazu, es wirklich zu einem Desktop einzurichten, aber was solls. Vielleicht beim nächsten Release.

 

[bsdfreak]

Dann wünsch ich Dir viel Erfolg mit OpenBSD. NetBSD habe ich auch nur probehalber ausprobiert, um mal über den Tellerrand zu schauen. Mein Arbeits OS bleibt trotzdem OpenBSD, mit dem ich rundherum vollumfänglich zufrieden bin.