NetBSD: Die ersten Eindrücke

C

CrimsonKing

Guest
NetBSD hatte mir in meiner Sammlung ja noch gefehlt. Ein System, dessen Nutzer trotz knapper Ressourcen wenige, aber zufriedene zu sein scheinen, imponiert mir; insbesondere, wenn es nicht gerade der aktuelle "Shooting Star" ist. Ich bin Bastler, ich mag Basteln mit Software, die nicht "einfach funktioniert". ;)

Weil ich ihn kaum benutze (habe die BSDs momentan aus Zeitgründen außerhalb von Servern nicht so richtig aktiv im Einsatz), habe ich jetzt mal spaßeshalber meine OpenBSD-Surfmaschine plattgemacht und stattdessen NetBSD 7.99 (Build von gestern) draufgespielt. Es sollte ja nicht so schwierig sein, eine (abgesehen von der Vollverschlüsselung) ähnliche Konfiguration zusammenzukleben. Dachte ich. Aber so richtig begeistert bin ich noch nicht so ganz.

1. Die Installation: Schmucklos, flexibel und voller verwirrender Fehlermeldungen. Mit der Bootkonfiguration von OpenBSD kam der Installer jedenfalls nicht zurecht. Da musste ich mit GParted nachhelfen, um die "device busy"-Meldung wegzubekommen. Stellte sich raus: der Bootsektor war komplett hinüber. Das hatte ich bis dahin auch noch nicht. Na gut, wahrscheinlich Bedienfehler meinerseits. Da war ich doch recht verwöhnt von den anderen BSDs. Die funktionieren einfach mit "Eingabetaste drücken und warten". Das Netzwerk zum Laufen zu bekommen war auch nicht so problemlos möglich. WTH ist ein "autoselect" und wo kann ich da meine SSID eingeben? - Sei's drum, ging ja auch ohne (Installationsimage sei Dank). Allerdings führt mich das schon irgendwie zu 2):

2. WLAN. Juchhu, wpa_supplicant! Eine durchaus willkommene Ergänzung im Kernsystem, macht einem das Leben doch geringfügig leichter. Funktioniert sogar mit dem Strokel-ThinkPad (FreeBSD hatte seinerzeit ja große Probleme mit dem wpi0-Treiber - wieso auch immer). Den Unterschied zwischen dhclient und dhcpcd (was'n das?) müsste ich jetzt gerade erraten, WLAN-Anleitungen im Web nutzen abwechselnd beide, was so natürlich nicht funktioniert. Mit einem angepassten ifwatchd-Script (feyrer.de) läuft zumindest das Internet. Heute Abend versuche ich auch mal rauszufinden, was das eigentlich genau tut. :D

3. Standarddienste: ntpd beschwert sich über rlimit und blocking_getaddr und ich glaube, ich schalte ntpd einfach ganz ab, weil mir irgendwie die Muße fehlt, das zu verstehen. :rolleyes:

4. Desktop: Raff' ich nicht. Ich hatte xdm bei der Ersteinrichtung ausgewählt, aber krieg' trotzdem nur Konsolenlogins. Weiß der Geier, wie ich das TTY wechsle, Kombinationen mit den Funktionstasten malen mir nur Zahlen auf den Bildschirm. Ach, ach.

Morgen mehr.
 
Ich experimentiere auch gerade mit NetBSD (und Dragonfly BSD), weil es Spaß macht und mir da noch etwas "Praxis" fehlt...

Meine Eindrücke von NetBSD waren vergleichbar. Ich verstehe den Installer nicht: NetBSD ist ein System für wahre Bastler, aber an jeder Ecke gibt es eine Sicherheitsabfrage "Wollen Sie wirklich... (y/n)". Die Zielgruppe braucht das glaube ich nicht, man sollte wie bei ZFS handhaben: Ein Entwickler schrieb mal sinngemäß: "Wofür denn eine Sicherheitsabfrage beim Zerstören eines Pools?!? Wenn ich "zpool destroy <poolname>" tippe, ist das Wort "destroy" doch wohl Siecherheitsabfrage genug...". :)

Ansonsten lief NetBSD 7 bei mir auf einiger der alten Hardware zunächst nicht, auf der ich es einsetzen wollte: IBM T23, IBM X30, Toshiba T4900CT und einige Nicht-x86-Plattformen (ich weiß nicht mehr genau, welche liefen, es ging um VAX, HPPA, Alpha, SPARC, MIPS, Itanium und so weiter. [TODO to myself: Liste machen!]. Wo es lief (zB IBM T42p) funktionierte es nicht schlechter als beispielsweise Open/FreeBSD, wenngleich NetBSD für mich mehr Neuland bedeutet - macht aber Spaß, und Du hast Recht, dass die Community eine ausgesprochen freundliche ist.

Zu 3., rlimit: Kann das mit der geplanten Anzahl der User, die das System benutzen sollen, zusammenhängen? Ich glaube, da sollte man auch als Einzeluser 16 oder so angeben, weil sonst einige Ressourcen zu eng bemessen werden. Siehe auch http://netbsd.gw.com/cgi-bin/man-cgi?setrlimit++NetBSD-current

Zu 4., X: Auch NetBSD hat ja mittlerweile diese verdammte KMS... ich installiere daher immer zunächst ohne X und baue das Stück für Stück auf (mit Remote-SSH für root, um den Kram ohne Neustart abschießen zu können, falls KMS mal wieder keine Textkonsole zeigen mag). Ging auf dem IBM T42p mit Radeon9600-Grafik probelmlos.


Michael
PS: Überraschend funktioniert übrigens OpenBSD auf sehr viel dieser alten Hardware, auch wenn man da ab und zu einen Kernel-Parameter ändern muss. Das hätte ich andersherum erwartet. Aber OpenBSD-Experimente (aktuell: Sun T5220 T2 mit 8x8 1.4GHz-Kernen und 64 GByte RAM) gehört in einen anderen Thread....
 
Ich experimentiere auch gerade mit NetBSD (und Dragonfly BSD), weil es Spaß macht und mir da noch etwas "Praxis" fehlt...

Bei Dragonfly BSD finde ich nur wenig Ungewöhnliches, so auf Anwendungsebene. Ich hätte gern mal die Infrastruktur, um HAMMER sinnvoll ausprobieren zu können, aber das kann ich ja später sicherlich noch nachholen. :) Gehört vermutlich auch nicht hierher.

Zu 3., rlimit: Kann das mit der geplanten Anzahl der User, die das System benutzen sollen, zusammenhängen? Ich glaube, da sollte man auch als Einzeluser 16 oder so angeben, weil sonst einige Ressourcen zu eng bemessen werden. Siehe auch http://netbsd.gw.com/cgi-bin/man-cgi?setrlimit++NetBSD-current

Keine Ahnung, steht nicht dabei. Das ist ja das Ärgerliche. Ich bin da OpenBSD-verwöhnt anscheinend. Da läuft es einfach.

Zu 4., X: Auch NetBSD hat ja mittlerweile diese verdammte KMS... ich installiere daher immer zunächst ohne X und baue das Stück für Stück auf

Warum fragt mich das Ding dann nach xdm, wenn es mir keinen xdm starten will? :grumble:
 
Warum fragt mich das Ding dann nach xdm, wenn es mir keinen xdm starten will?
Das ist Fortschritt. Früher musste man grübeln, probieren, lesen und alles von Hand konfigurieren. Heute hat man Automatismen und einen Grafikmodus. Und somit muss man heute grübeln, probieren, lesen und versuchen, die verdammte Automatik und die nicht funktionierende Grafik irgendwie abzuschalten, bevor man grübeln, probieren, lesen und X von Hand konfigurieren kann... :grumble:
 
Nur mal kurz am Rande. Du installierst da eine Entwicklerversion, wo gerade massive Änderungen an den untersten Layern des Netzwerk-Subsystem gemacht werden und bemerkst Bugs bei Netzwerkgeschichten. Ich bin schwer erschüttert. Und wo sind wir gerade .36, da kommen fast noch genauso viele Versionen. Ich hätte ja den LLVM Build getestet.

Der Rest, ja der Installer macht bei einigen Festplatten ziemlich merkwürdiges Zeug, nicht sehr vertrauenswürdig. Keine Ahnung was du mit SSID meinst, ich verbinde mich vorher zum Netzwerk. Der Unterschied zwischen dhclient und dhcpd, muss ich dir das wirklich in einem Technikforum erklären?
Es gibt zwei Möglichkeiten warum kein grafisches Login sichtbar ist, entweder fehlt der Eintrag in rc.conf und/oder eine xorg.conf.
 
Stabile Versionen sind was für Babys und Kommunisten (und meine Server). Ginge es mir um "machste an und läuft", hätte ich damit gar nicht erst angefangen. :)

dhcpcd war mir bis dato nie begegnet, bitte vielmals um Verzeihung. Was die X-Konfiguration angeht: das Installationsprogramm ist doch sonst so gesprächig, warum nicht auch hierbei?

Mit SSID meine ich: Es ist auch für den nicht mehr ganz unbelesenen Benutzer nicht einfach herauszufinden, wie man NetBSD während der Installation an ein bestimmtes WLAN hängt. Vermutlich irgendwie über die Shell, aber über keinen Eintrag im Installer. Kabel-LAN hab ich nun nicht getestet, würde aber wahrscheinlich besser funktionieren. Warum kriegen die NetBSDler keine übersichtlichere Installation hin?
 
Soweit ich mich entsinne, verbindet er sich auch nicht automagisch mit dem Netzwerk, wenn das LAN-Kabel steckt. Von daher fehlt ohnehin das komplette Setup.
Und zur X-Konfiguration, die findet doch gar nicht statt. Oder hast doch vorher xsession und/oder xorg.conf angelegt?
 
Verstehe. Der Network-Punkt in der Installation ist also eigentlich völlig überflüssig und die Frage nach xdm prinzipiell auch? Nein, ich habe außer der Partitionierung vorher nichts angerichtet.
 
In der Form ganz sicher. Ich habe auch nie xdm vermisst. Es sieht nicht nur grottig aus, die Konfiguration für die dt. Tastatur ist recht tricky.
Und da hier keiner weiß was für Grafik-Hardware du hast, bleibt die Frage offen warum scheinbar das Umschalten der VT nicht funktioniert.
Ich habe hier zwei Installationen, beide funktionieren.
 
Na, hervorragend. Testen die ihren Installer überhaupt auch mal selber? Hmpf.

Äh, Standardhardware. ThinkPad T60 ohne irgendwelche Anpassungen meinerseits. :confused:
http://thinkwiki.de/T60

NetBSD lädt da standardmäßig den radeon-Treiber, wie vorher auch OpenBSD.
 
Normalerweise reicht ein ALT+STRG+F[1-3]. Wenn beim booten auch auf den beschleunigtem TTY wechselt, sollte das auch funktionieren. Vielleicht gibt dmesg Hinweise warum es nicht funktioniert. Hab hier nur noch einen T40 für meinen Willem, mal schauen vielleicht richte ich da noch ein Dualboot ein. Der müsste auch Radeon benutzen.
 
Der Spaß geht weiter: ich kann weder Binärpakete noch irgendwas aus pkgsrc (anoncvs-Version) installieren: "libssl.so.10 not found". :grumble:
 
Das "nächste" Release ist immer "noch nicht da". Dann müsstest du ja auch, sobald 8.x da ist, 8.99 benutzen, weil 9.x noch nicht da ist.

Also warum 7.99 und nicht ein offizielles Release? Die Vorgabe, dass -current stabil genug zum Benutzen ist, gibt's nur bei OpenBSD.
 
Darum hab' ich auf den Geräten, bei denen es auf Stabilität ankommt, ja auch OpenBSD und nicht NetBSD.
Bei dem ThinkPad hier isses mir aber wurscht. Das ist mein Experimentiergerät. Ich will mir NetBSD mal eine Weile angucken und da ist -current vermutlich nicht das Blödeste. Lerne ich gleich ein paar zusätzliche Fallstricke kennen. :)
 
Mein lieber CrimsonKing, wenn man sein Paket gegen eine neuere Version von libressl baut, dann linkt er selbstverständlich auch auf diese Version. Das Problem kann man nur aus dem Weg gehen, wenn man nur eine Version erlaubt, in der Hoffnung das nichts bricht, was bei libressl aber eher Normalzustand ist.In die Zukunft haben wenige Einblick. Abhilfe, setze einen symbolischen Link oder baue das Paket aus den Quellen wenn du schon eine Entwicklerversion verwendest. Was meinst du wieviel Spaß Binärpakete machen bei einer Entwicklerversion.
 
Ich habe es jetzt mal mit einem Hardlink versucht (frage mich aber, wieso pkgsrc current und NetBSD current so schlecht miteinander umgehen können). Ergebnis: Es würde mir gern erst mal eine libarchive für pkg_install (oder so) installieren, bricht dann aber ab, weil es behauptet, ich hätte schon eine.

Bezaubernd.
 
Vielleicht war das nicht eindeutig formuliert also auf ein zweites. Man baut seine Pakete mit dem was auf dem Rechner sich befindet und linkt auch gegen diese Bibliotheken. Vorausgesetzt libressl ist nicht Teil des Grundsystems und man zieht sich die Pakete binär werden immer Referenzen enthalten sein sein als symb. Links. Du hast vermutlich zwei Pakete erwischt die von unterschiedlichen Buildvorgängen stammen. Normalerweise bedient man sich vom ein Repo oder baut es selbst. Gibts denn Repos für Current? Es gibt doch grundlegende Motivationen Current zu verwenden. Neugier, versiert, Entwickler oder man brauchts weil ein Feature bzw. Fehler es notwendig machen. Selbst bei Pkgsrc wird zwischen Stable und Current unterschieden weil nicht alle Kombinationen getestet werden können.
 
Ich hab' keine Repos für Current gefunden, weshalb ich versuche zu bauen (Current, weil tatsächlich Neugier). Allerdings scheint schon das Bauen selbst irgendwelche Abhängigkeiten nicht anständig aufzulösen. Jeder Versuch, irgendwo in .../pkgsrc ein make install durchzuführen, will erst mal die libarchive mitbauen und das geht anscheinend nicht.

Bei Paketen könnte ich mir das ja noch erklären...
 
Ich will nicht verleugnen, dass einige Current-Builds ziemlich kaputt sind, von unbenutzbaren USB bis merkwürdigen Abstürzen bei mc. Derzeit ist es häufig der Fall, dass das Netzwerk hinüber ist nach dem Aufwachen, aber dafür ist der Rest auffällig stabil. Mit ein wenig Handarbeit ist es recht schnell benutzbar:
  • Vernünftige Shell(>= Ksh) und User der Gruppe wheel zuordnen
  • alias für colorls setzen um Farbe in der Konsole zu bekommen
  • Xterm mit Farbe und X mit korrektem Tastaturlayout versorgen
  • TERM setzen und mc Tasten lernen lassen
  • PKG_PATH setzen und pkgin updaten
  • autologin und mehr VTs konfiguieren
  • Mit ttys Tastaturgeschmiere abgewöhnen
  • PKGSRC + WIP installieren
  • wpa_supplicant konfiguieren
 
Und welche Handarbeit lässt pkgsrc benutzbar machen, um u.a. "vernünftige Shell" (ksh93) und pkgin zum Laufen zu bekommen?
 
Mal spaßeshalber NetBSD 7.0.1 mit pkgsrc 2016-Q2 drübergebügelt, um zu gucken, ob ich wirklich selber schuld bin, dass es so einen grützigen Eindruck hinterlässt.

1. ntpd ist immer noch von irgendeinem blocking getaddrinfo überfordert.
2. Der Installer ist immer noch grauenhaft.
3. X funktioniert immer noch nicht wie erwartet (X -configure findet, ich hätte an meinem Laptop die falsche Anzahl an Bildschirmen?!).
4. WPA will dauernd seine Groups rekeyen. Muss mal gucken, wie ich das abstelle.
5. Mangels Netzwerk bei der Installation ist die Ersteinrichtung von pkgsrc immer noch ein ziemlich zeitintensiver Vorgang. Immerhin: Dinge zu kompilieren scheint zu funktionieren, die Installation von pkgin läuft aus /usr/pkgsrc durch.

Jetzt erst mal eine Pause.
 
Zurück
Oben