• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

NetBSD auf Raspberry Pi 2

meilenstein

Well-Known Member
Themenstarter #1
Hallo

bis jetzt war ich mehr oder weniger stiller Mitleser hier im Forum und habe mich mit dem Thema BSD nur ein wenig beschäftigt.

Jetzt habe ich mir einen Raspberry Pi 2 gekauft und dachte mir ich versuche einmal etwas neues und schaue mir NetBSD an. Ich bin der Anleitung von NetBSD für das Raspberry gefolgt und habe es geschafft, die SD Karte vorzubereiten und NetBSD das erste mal auf dem Rechner zu booten. Nach der Einrichtung des Netzwerks und des Benutzers komme ich jetzt aber irgendwie nicht mehr weiter wenn es um die Pakete geht.

Mangels passendem Bildschirm logge ich mich über SSH auf dem Raspberry ein und möchte jetzt nach und nach weitere Anwendungen installieren. Wenn ich hier aus den Quellen mittel pkgsrc installiere klappt dies, aber dauert sehr sehr lange.
Laut Anleitung soll es ja Binärpakete geben, welche ich mittels pkgin installieren können sollte.
In der INSTALL heißt es:
Precompiled binaries can be found at ftp://ftp.NetBSD.org/pub/pkgsrc/packages/NetBSD/
usually in the evbarm/7.99.25/All subdir. If you installed pkgin(1) in the sysinst post-installation configuration menu, you can use it to automatically install binary packages over the network.
Leider finde ich jetzt aber weder diesen genannten Pfad auf dem ftp Server, noch verstehe ich wo ich pkgin im sysinst Post-Installation Konfigurationsmenü auswählen kann.

Hat jemand diese Kombination am Laufen und kann mir weiterhelfen?
Code:
uname -a
NetBSD raspberry2 7.99.25 NetBSD 7.99.25 (RPI2.201601010200Z) #0: Fri Jan  1 03:53:56 UTC 2016  builds@b47.netbsd.org:/home/builds/ab/HEAD/evbarm-earmv7hf/201601010200Z-obj/home/source/ab/HEAD/src/sys/arch/evbarm/compile/RPI2 evbarm
 

darktrym

Fahnenträger
#2
Da bin ich mal wieder gefragt. Zuallererst, wie du an der Kernelversion sehen kannst, benutzt du eine Entwicklerversion(x.99.y), weshalb sicher keine Pakete gerade für diese Version da sind.
Dank abwärtskomp. gehen alle möglichen Versionen aber um die Schmerzen möglichst klein zu halten, nimm 7. Das erspart die reihenweise symb. Links zu setzen.

Eine kurze Recherche meinerseits ergab, es sieht nicht so aus als wären irgendwo aktuelle vorkompilierte Pakete vorhanden.
Kommen wir zum nächsten Punkt, was nun? Da der Bau der Pakete direkt auf dem Gerät nicht viel Sinn macht, IO ist keine Stärke vom Pi, eine Crosscompiling Enviroment in einer VM oder realen Maschine sollte hierfür eingerichtet werden.
Dann pkgsrc wenn's geht vom letzten stabilen Branch drauf und dann die gewünschten Pakete bauen. Ganz faule Typen setzen dann noch PKG_PATH zu dieser Maschine und nutzen pkg_add für's installieren.

Und wenn dir das alles zu viel ist, ich bin mir sicher es gibt Leute da draußen, die haben das schon mal für dich gemacht. Dann ist die Mailingliste von pkgsrc-users sicher eine Stelle zum nachharken.

PS: Einer von uns, einer von uns ...
 

Chu

Well-Known Member
#3
Hallo meilenstein,

willkommen bei NetBSD.

Im Installer solltest du bei der Konfiguration des Passwortes, Zeitzone, etc etc auch weiter unten das Kapitel finden, ob du die Vorbereitung von binären Paketinstallationen möchtest.

Nach meiner kurzen Recherche sieht es aber auch so aus, dass du
a) NetBSD current (7.99) und nicht die normale 7.0 installiert hast
b) es noch keine binär vorkompilierten Pakete für deine Plattform gibt

lieben Gruß
Chu
 

Sickboy

Müßiggänger
#4
Binärpakete für NetBSD 7 (ARMv7) können problemlos mit den Package-Tools oder pkgin installiert werden. In beiden Fällen ist der Paket-Pfad festzulegen. Für die Shells "csh" und "tcsh" reicht folgender Aufruf:

Code:
# setenv PKG_PATH "ftp://ftp.NetBSD.org/pub/pkgsrc/packages/NetBSD/earmv7h/7.0/All"
Der Pfad kann mit einem Eintrag in "/root/.cshrc" dauerhaft festgelegt werden (siehe auch das NetBSD-Handbuch).

Mit "pkg_add" lassen sich die Pakete "mozilla-rootcerts", "vim" und "tmux" dann wie folgt installieren:

Code:
# pkg_add mozilla-rootcerts vim tmux
# pkg_info
"pkgin" muss hingegen erst noch installiert werden:

Code:
# pkg_add pkgin
Dann das Repository hinzufügen und die lokale Datenbank aktualisieren:

Code:
# echo ftp://ftp.NetBSD.org/pub/pkgsrc/packages/NetBSD/earmv7h/7.0/All > /usr/pkg/etc/pkgin/repositories.conf
# pkgin update
Und schon können auch mit "pkgin" Pakete installiert werden:

Code:
# pkgin install mozilla-rootcerts vim tmux
 

meilenstein

Well-Known Member
Themenstarter #5
Super vielen Dank für die Hinweise, werde ich am Feiertag mal in aller Ruhe ausprobieren und freue mich schon jetzt dass ich so prompte Hilfe bekomme.
Einzig wundert es mich jetzt wie Du den Pfad für die Binärpakete gefunden hast, hatte ich dann scheinbar irgendwo übersehen... egal :-)
 

SierraX

Well-Known Member
#6
Einzig wundert es mich jetzt wie Du den Pfad für die Binärpakete gefunden hast, hatte ich dann scheinbar irgendwo übersehen...
Der von dir im ersten Post gezeigte Pfad ../evbarm/.. ist ein symbolischer link auf das Verzeichnis ../arm/.. das keine Pakete für 7.0 enthält... der Ordner ../earmv7hf/.. ist ein Verzeichnis auf der gleichen ebene wie arm enthält aber 7.0 Pakete
Den Unterschied zwischen earm, arm oder evbarm kenn ich aber leider nicht.
 

darktrym

Fahnenträger
#7
Ich weiß nur das evbarm für ARM-basierende Evaluation Boards steht, also Platinen "nacksch" wie Gott sie schuf zum rumspielen. Das e steht ja meinst für Embedded und v7 weil es auch andere ARM-Architekturen gibt, v8 soll es ja auch für NetBSD geben.
 

meilenstein

Well-Known Member
Themenstarter #8
Binärpakete für NetBSD 7 (ARMv7) können problemlos mit den Package-Tools oder pkgin installiert werden. In beiden Fällen ist der Paket-Pfad festzulegen. Für die Shells "csh" und "tcsh" reicht folgender Aufruf:

Code:
# setenv PKG_PATH "ftp://ftp.NetBSD.org/pub/pkgsrc/packages/NetBSD/earmv7h/7.0/All"
Vielen Dank für die sehr ausführliche Beschreibung. (mein NetBSD verwendet als Shell "sh", daher müssen die Befehle wie im Handbuch beschrieben angepasst werden)
Habe jetzt testhalber mein erstes Binärpaket mittels pkg_add installiert, der von Dir genannte Pfad funktioniert bestens:-)
Werde mich mal ein wenig einlesen.
 

meilenstein

Well-Known Member
Themenstarter #9
Nachtrag da ich gerade selbst noch mal darüber gestolpert bin
Der Pfad heißt korrekterweise ftp://ftp.NetBSD.org/pub/pkgsrc/packages/NetBSD/earmv7hf/7.0/All
 

TCM

Well-Known Member
#14
Für Scripte sollte man sich auf /bin/sh beschränken. Als interaktive Shell gehört zsh auf den Rechner, und alles andere gehört abgeschafft!
 

meilenstein

Well-Known Member
Themenstarter #18
Ich hoffe hier benutzt nicht wirklich jemand noch sh statt ksh.
sh scheint hier bei der Installation von NetBSD current für Rasberry Pi 2 automatisch als Voreinstellung/-installation ausgeliefert zu werden :confused:
Da ich aber was die Unterschiede der Shells angeht auch keine Ahnung habe, würde ich mich hier ebenso über Infos freuen (auch wenn es am ursprünglichen Thema vorbeigeht) ;)
 

SierraX

Well-Known Member
#20
Hab mir gestern (leider sehr spät das es bis Montag dauern kann bis ich das Paket in Händen halte) das Mega-Pack bestellt... Mal gucken ob ein 2er mit 7" Display auch auf NetBSD funktioniert. Mit Touch rechne ich jetzt mal noch nicht.
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
#22
Wo sind denn die Unterschiede zu, zum Beispiel, tcsh?
Ich nutze praktisch seit dem Anbeginn aller Zeiten die tcsh. Seit einiger Zeit nervt sie mich aber immer mehr. Das sind für sich genommen keine kritischen Punkte, es läppert sich aber. Mal grob zusammengefasst:
  • Es geht damit los, dass die tcsh eher fragilen Code hat. Bei jeder neuen Version gibt es neue Bugs, wenn man in der Systemumgebung etwas vom Standard abweicht, muss man erstmal patchen. So funktioniert die tcsh z.B. mit unverändertem Code nicht mit der musl libc. Das aufzuräumen ist eine Sysiphusarbeit, da man die diversen Eigenheiten der Shell aus Kompatibilitätsgründen allenfalls sanft ändern kann. Entsprechen hat es in den letzten 25 Jahren keiner gemacht und wird es in den nächsten 25 Jahren auch nicht.
  • Beim Thema Bugs muss man dann auch all die Mängel und Eigenheiten nennen, über die man mit den Jahren so stolpert. Es gibt die offensichtlicheren Probleme, wie z.B. das mehrere zur gleichen zeit beendete Shells sich gegenseitig die History überschreiben. Das ist inzwischen zwar gepatcht, aber damit hat sich ein neues Problem ergeben. Beim Crash im falschen Moment bleiben Lock-Dateien liegen... Dann die weniger offensichtlichen Macken, wie z.B. das einige Konstrukte je nach Situation anderes Verhalten zeigen oder einfach plötzlich illegal werden.
  • Die tcsh hat eine sehr bescheidene Scriptsprache. Sie ist in sich fürchterlich inkonsistent, es fehlenden essentielle Dinge wie echte Funktionen und Quoting klappt maximal so halb. Nun muss man in der tcsh nicht scripten, aber selbst das Schreiben einer einfachen Schleife ins Prompt wird damit schon zum Kramp. Der Klassiker zu diesem Thema ist: http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/
  • Es gibt in der tcsh keinen vernünftigen Umgang mit File Descriptoren. Am offensichtlichsten ist, dass stderr und stdout nicht getrennt umgeleitet werden können. Unter der Haube ist der Abgrund aber viel tiefer. Man kann File Descriptoren beispielsweise kaum duplizieren, geschweige denn schließen.
  • Die tcsh ist anders. Während die ganze Welt Bourne-Shells nutzt, hat man eigene Konstrukte. Ein prominentes Beispiel ist 'setenv' zum Setzen von Variablen. Nicht nur, dass man umdenken muss. Dinge wie 'LD_PRELOAD=/tmp/meinelib.so ./cmd' gehen einfach nicht so wirklich.
Daher begann ich mir andere Shells anzuschauen. Die lassen sich grob in zwei Klassen unterteilen. Einmal die speziellen Shells, die ihr eigenes Ding machen. Das sind Perl- oder Haskell-Shells, aber auch DInger wie 'fish'. Sie sind meist nicht schlecht, aber von einer Speziallösung in eine andere zu wechseln, ist nicht unbedingt das Ziel der Übung. Dann die Bourne-Shells in ihren diversen Geschmacksrichtungen. Alle noch verbreiteten Shells der Familie sind gute Shells, die man durch die Bank empfehlen kann. Also bleibt es Geschmackssache. Die Bash mochte ich noch nie. Ich empfand sie immer als recht fett und langsam, was durch den Funktionsumfang nicht gerechtfertigt ist. Außerdem ist sie eng in andere GNU-Spezialitäten wie libreadline integriert. Die zsh ist zweifelsohne die umfassenste Shell und wie TCM schreibt, die vielleicht einzige Shell, die man nutzen sollte. Aber ich brauche 98% des Funktionsumfangs nicht. Und auch wenn ich ihn nicht nutzen muss oder sogar abschalten kann, wieso dann das Ganze? Bleibt die ksh-Familie. ksh88 und ksh93 sind in meinen Augen für den interaktiven Einsatz zu eingeschränkt, gerade was die Command History betrifft. Mit dem CMD-Editor könnte man sich noch arrangieren. So kam ich zur mksh.

Die mksh ist einerseits sehr schlank. Wenig Code, beschränkt sich in Sachen Features auf die wichtigsten Dinge. Aber andererseits kann sie alles für mich Wichtige. Sie kann den kompletten Satz an Pipe- und File Descriptor Operationen, alle gängigen Substituierungen und einen großteil des ksh88 Syntax. Sie hat eine vernünftige Command History und der interaktive CMD Editor ist durchaus okay.

Im Moment nutze ich die mksh nur auf meinem Arbeitsdesktop. Ob ich meine anderen Systeme umstelle, weiß ich noch nicht. Sicher nicht alle Server, denn da müsste man halt durchgehend ein weiteres Paket installieren und sich mit den Kollegen einig werden.