OpenSolaris 2009.06 Installation NIC-Treiber

[fiestaforever]

Hallo,

zunächst vorab: (Open)Solaris ist natürlich kein Linux, aber dieses Unterforum soll lt. Untertitel ja auch für andere Unix-Derivate sein.
Und dass OpenSolaris tot und veraltet ist, weiß ich. Es passt aber zum einzigen vernünftigen Buch, das ich zu (Open)Solaris ergattern konnte (Solter/Jelinek/Miner, OpenSolaris Bible). Bitte keine Distro-Debatte aus meiner Frage machen.

Zur Sache:

Ich bin gerade am Verzweifeln mit der Installation von Treibern für die Netzwerkkarte Broadcom 4401 in einem Fujitsu/Siemens Amilo M7400 (ca. Baujahr 1994). Mit diesem Rechner und einer OpenSolaris 2009.06-Installation will ich mich ein bisschen mit (Open)Solaris vertraut machen (Produktiveinsatz ist nicht geplant). Leider habe ich keine Ahnung von Unix (und auch kaum welche von Linux). Z.B. habe ich keinen Plan, wie man etwas kompiliert.

Zur Netzwerk-"Karte" wurde kein Treiber mitgeliefert. Nach einigem Suchen habe ich hier einen Treiber gefunden (bfe-2.6.2), dar aber anscheinend nur im Quellcode vorliegt (was der Unterschied zwischen 1.1.1 und 2.6.2 ist, ist mir auch unklar, ich habe mich aber vorerst für 2.6.2 entschieden).
Es ist mir gelungen, das Archiv mittels USB-Stick auf den Läppie zu übertragen und zu entpacken. Nun weiß ich aber nicht mehr weiter. Ich werde weder aus der Readme-Datei schlau noch aus einer Anleitung, die ich hier gefunden habe. Beide scheinen sich auch z.T. zu widersprechen.

In der Readme-Anleitung (ist an diesen Post angehängt) bin ich schon an folgendem Punkt steckengeblieben:
> 3. Preparing for installation
> (...)
> (3) Add hostname for the NIC card into the /etc/hosts file

In der im Web zu findenden Anleitung (s. Link oben) ist das so beschrieben:

>edit /etc/hosts, and add 'ip hostname' for this machine - eg:
>192.168.6.23 phaal

Ich weiß nicht, wo ich einen "hostname" für die Karte hernehmen soll.
Das OS hat zwar ein "Device Driver Utility", das die Karte sieht und den Treiber als "missing" meldet, aber anderswo (dladm, ifconfig) finde ich die Karte nicht, sondern nur die WLAN-Karte (als "ipw0"; und 2 x "lo0", was wohl ein Loopback-Device ist).

Und warum soll ich eine IP-Adresse für meine eigene Netzwerkkarte in die hostsfile schreiben, wenn das Ding später via DHCP seine IP-Adresse beziehen soll?

Die WLAN-Karte steht auch nicht in der hostsfile, sondern nur
>::1 <Computername> <Computername>.local localhost loghost
>127.0.0.1 <Computername> <Computername>.local localhost loghost

Kann mir als Unix-Noob jemand weiterhelfen?

BTW: WLAN funktioniert trotz Treibern auch nicht richtig, sondern verliert immer wieder sofort die Verbindung (weshalb ich zum USB-Stick greifen musste), aber das ist ein anderes Thema. Für meine Zwecke ist WLAN irrelevant. Dumm nur, dass ich jetzt gar keine Netzwerkverbindung habe. Sonst scheint alles zu funktionieren.

Grüße
f.

 

[mensch183]

Bring erstmal den bfe-Treiber zum Laufen. Über die IP-Konfiguration kannst du dir danach den Kopf zerbrechen. Punkt (3) in der readme also einfach mal ignorieren. Das danach ist wichtig. Erst wenn bei "ifconfig -a" das Interface bfe0 auftaucht, hast du den schwierigeren Teil geschafft und kannst dich um die IP-Konfiguration kümmern.

(Bei statischen IPs schreibt man bei Slowlaris pro Interface in ein File namens /etc/hostname.<interface>, bei dir also in /etc/hostname.bfe0, einen Hostnamen rein und in die /etc/hosts jeweils ein Paar aus IP und diesem Hostnamen. Darüber bekommt das Interface beim Booten seine IP zugeordnet. Beispiel:
$ echo meinhost > /etc/hostname.bfe0
$ echo "192.168.11.11 meinhost" >> /etc/hosts
)

Ich weiß nicht, wo ich einen "hostname" für die Karte hernehmen soll.

Denk dir irgendwas aus. "meinhost" ist nicht besser oder schlechter als "krokofant" oder sonstwas. Das ist einfach der dem Interface zugeordnete Name, den man gern auch im DNS einträgt. Was man im Linuxjargon üblicherweise den "Hostnamen" nennt, steht bei Slowlaris in /etc/nodename.

 

[fiestaforever]

Bring erstmal den bfe-Treiber zum Laufen. Über die IP-Konfiguration kannst du dir danach den Kopf zerbrechen. Punkt (3) in der readme also einfach mal ignorieren. Das danach ist wichtig. Erst wenn bei "ifconfig -a" das Interface bfe0 auftaucht, hast du den schwierigeren Teil geschafft und kannst dich um die IP-Konfiguration kümmern.
(...)
Denk dir irgendwas aus. "meinhost" ist nicht besser oder schlechter als "krokofant" oder sonstwas. Das ist einfach der dem Interface zugeordnete Name, den man gern auch im DNS einträgt. Was man im Linuxjargon üblicherweise den "Hostnamen" nennt, steht bei Slowlaris in /etc/nodename.

So (bzw. so ähnlich) habe ich das inzwischen auch schon zu lösen versucht. Ich habe mir gedacht, ich nenne ihn - analog zu "ipw0" - einfach "bfe0", und nehme irgendeine IP 192.168.1.x.
Nun stecke ich aber an einem anderen, wahrscheinlich viel böseren Punkt fest.

Lt. Readme:

(7) Making binaries only for OpenSolaris users.
Bfe driver likely work with GLD v3, known as Nemo, under OpenSolaris.
You can enjoy the new functions by recompiling bfe source code with
OpenSolaris source code.
% rm Makefile.config
% ln -s Makefile.config_gld3 Makefile.config
% vi Makefile.config (fix ONUTSDIR macro to point uts directory in opensolaris kernel source)
% /usr/ccs/bin/make

Das "uts directory in opensolaris kernel source" soll ja wohl ein Verzeichnis /uts in dem Verzeichnis sein, in dem die Kernel-Sourcen sind (lt. diverser Fundstellen im Netz /usr/src/uts oder ein entsprechendes Verzeichnis in einem Download-Verzeichnis). Ich habe aber kein Verzeichnis /usr/src/uts (bzw. halt nur ein Verzeichnis /usr/src/ mit nix drin, oder ist das src gar nur ein Link ins Nichts?), auch sonst nirgendwo ein Verzeichnis mit Kernel-Sourcen. Weder auf der Installation noch auf der CD, von der ich installiert habe.

Nichts, niente, nada.

 

[mensch183]

Dann installiere die Sourcen, falls sie für den Treiber tatsächlich benötigt werden. Wundert mich bischen, da man beim "richtigen" Solaris keine Kernelquellen dazu brauchte. Aber klingt schon so in der readme.
Wie schon oben: laß einfach den Punkt erstmal weg und schau was beim make passiert. Das make bzw. der Compiler wird sich brav darüber beschweren, was er benötigt aber nicht findet.

 

[fiestaforever]

Danke für die (nochmalige) Antwort.

Leider kann ich gerade nicht weitermachen. Die Kiste will nämlich jetzt nicht mehr booten

(Hat vermutlcih nichts mit dem Treiber zu tun, denn die eigentliche Treiber-Installation habe ich noch gar nicht versucht.)

Edit: Hatte wohl doch was mit der Treibersache zu tun. Habe gesehen, dass er auf der Konsole irgenddwas "blabla misconfigured" ausgegeben hat.
Wenigstens war ich so schlau, vorher einen Boot Environment-Snapshot zu machen. Der bootet noch.
Kann also weitergehen. Aber nicht jetzt sofort, weil ich im Moment keine Zeit habe.

 

[fiestaforever]

Ich bin wieder "dran". Im doppelten Sinne: Zum einen in diesem Thread, und zum anderen mit Herumprobieren.

Zwar ist es mir nach tagelangem (!) Suchen nun endlich gelungen, auf einem Zombie-Server unter sun.com etwas zu finden, was (zumindest für mich) wie ein Download der Source-Dateien aussieht, ich habe es aber auch zwischenzeitlich mit einer Synthese beider Anleitungen versucht, tendenziell der von spod.cx, weil mir die Aussage in der Readme irgendwie nach einer optionalen Neukompilierung der Treiber für neue Features aussieht.

Ich komme aber nicht wirklich weiter. Zum einen habe ich Schwierigkeiten mit der o.g. Zeile

$ echo meinhost > /etc/hostname.bfe0

Ich verstehe nicht, ob der Dateiname "hostname.bfe0" nun wirklich wörtlich gemeint ist oder ob ich für "hostname" im Dateinamen den Namen meines Computers eintragen muss, der kurz vor dem Konsolen-Login als "Hostname" angezeigt wird (in meinem Fall: "AmiloM7400").

Wenn ich die Datei tatsächlich "hostname.bfe0" nenne, dann bleibt der Rechner auf dem Weg zum Desktop stecken und zeigt beim Booten jede Menge Fehlermeldungen an (die ich abgetippt habe):

Failed to plumb IPv4 interface(s): bfe0
Moving addresses from missing IPv4 interface(s): bfe0 (not moved -- not in an IPMP group).
<Zeitangabe>svcstartd[7]: svc:/network/physical:default: Method "/lib/svc/method/net-physical" failed with exit status 96
<Zeitangabe>svcstartd[7]: network/physical:default misconfigured: transitioned to maintenance (see 'svcs -xv' for details)
Hostname: AmiloM7400
Configuring devices.
AmiloM7400 console login:

(Der Desktop erscheint aber nicht, es gibt nur endlose Zappelbalken, und die Fehlermeldungen sieht man nur nach Escape.)
Das dürfte der "Misconfigured"-Meldung entsprechen, die ich oben schon erwähnt habe.

Wenn ich die Datei in der Zeile

$ echo meinhost > /etc/hostname.bfe0

aber stattdessen "AmiloM7400.bfe0" nenne, dann bootet er bis zum Desktop.

Ich habe das zuerst für eine gelungene Reparatur gehalten, inzwischen glaube ich aber, dass es eher falsch ist.

Es scheint zwar dann weiterzugehen, aber ich bleibe nun bei

# devfsadm -i bfe

immer stecken, es kommt darauf als Antwort immer

devfsadm: driver failed to attach: bfe

Versuche ich dann trotzdem den nächsten Schritt

# ifconfig bfe0 plumb

dann bekomme ich darauf als Antwort

ifconfig: cannot open link "bfe0": DLPI link does not exist

Ich habe übrigens bisher immer versucht, am Anfang NWAM auszuschalten:

# svcadm disable network/physical:nwam
# svcadm enable network/physical:default

weil ich gedacht habe, dass mir sonst irgendeine Automatik "dazwischenfunken" könnte, und ich nicht wusste, ob die Anleitungen evtl. für ältere Versionen sind, als es NVAM noch nicht gab.

Inzwischen habe ich es auch mal ohne diese Befehle versucht, das hat aber leider auch nichts geändert.

Ich versuche es jetzt noch einmal mit der Neukompilierung der Treiber über die Sourcen (k.A., ob ich mich da sinnvoll ausgedrückt habe).
Irgendwo habe ich, glaube ich, mal gelesen, dass es bei der Treiberinstallation Probleme mit dem "Linking" gibt, vielleicht ist das auch mein Problem, was weiß ich...

Mäusemelken ist wahrscheinlich lustiger als das hier.

P.S.: Leider muss das jetzt erst mal wieder bis Sonntag abend warten, weil ich erst dann wieder da bin.

 

[mensch183]

Ich verstehe nicht, ob der Dateiname "hostname.bfe0" nun wirklich wörtlich gemeint

Ja, wörtlich gemeint.

Wenn ich die Datei tatsächlich "hostname.bfe0" nenne, dann bleibt der Rechner auf dem Weg zum Desktop stecken und zeigt beim Booten jede Menge Fehlermeldungen an (die ich abgetippt habe):
Failed to plumb IPv4 interface(s): bfe0
...

Für jede Daten namens /etc/hostname.<interfacename> wird beim booten versucht das Interface IP-mäßig zu konfigurieren. Da du den Treiber bfe noch nicht übersetzt und zum OS hinzugefügt hast, gibts gar kein Interface bfe0 und die Konfiguration schlägt fehl. bfe0 heißt das erste Netzinterface, für das der Treiber bfe sich als zuständig erkannt hat. Hast du mehrere im Rechner, heißen die anderen bfe1 bfe2 usw.

Deshalb schrieb ich, du sollst ERST den bfe Treiber übersetzen und zum Laufen bringen und dich DANACH um die IP-Konfiguration kümmern.

Es scheint zwar dann weiterzugehen, aber ich bleibe nun bei
# devfsadm -i bfe
devfsadm: driver failed to attach: bfe

Alles davor (make, make install, adddrv, modload) hat funktioniert?

 

[fiestaforever]

Es scheint zwar dann weiterzugehen, aber ich bleibe nun bei
# devfsadm -i bfe
devfsadm: driver failed to attach: bfe

Alles davor (make, make install, adddrv, modload) hat funktioniert?

Aus der Erinnerung: Ja. Zumindest gab es keine Fehlermeldungen.

P.S: Was machst Du eigentlich mit der Dampframme aus Deiner Sig so?

P.S.(2): Noch ein Nachtrag: Ich habe übrigens suncc und nicht gcc verwendet (weil ich irgendwo gelesen habe, dass gcc nicht mitgeliefert wird).

Ergänzung (24. Juni 2013)

So, ich habe mich diesen Abend nun also noch einmal drangesetzt, und es mit der Neukompilierung der Treiber versucht.

Praktisch strikt nach Readme vorgegangen

# rm obj Makefile
# ln -s Makefile.i386_suncc Makefile
# ln -s i386 obj
# rm Makefile.config
# ln -s Makefile.config_gld3 Makefile.config
# nano Makefile.config (ONUTSDIR geaendert auf /usr/share/src/b111b/usr/src/uts, wo die Kernel-Sourcen jetzt sein sollten)
# /usr/ccs/bin/make

bekomme ich nach make DIESE Fehlermeldung:

cc -c -xO2 -D"__INLINE__=" -U_NO_LONGLONG -D_KERNEL -U_ASM_INLINES -D_SYSCALL32 -D_SYSCALL32_IMPL -Dsun -D__sun -D__SVR4 -DC2_AUDIT -Xa -xspace -v -xc99=%all -errtags=yes -errwarn=%all -xstrconst -Di86pc -UDEBUG -DDEBUG_LEVEL=0 -DGEM_DEBUG_LEVEL=0 -UTEST_RX_EMPTY -UTEST_SMALL_DMA_RANGE -UDBG_NOBURST -UDBG_FAIRSCHED -UDEBUG_DUMP_REGS -UCONFIG_FLOW_CONTROL -I /usr/share/src/b111b/usr/src/uts/common -I /usr/share/src/b111b/usr/src/uts/intel -erroff=E_STATEMENT_NOT_REACHED,E_INTEGER_OVERFLOW_DETECTED -DGEM_CONFIG_POLLING -DGEM_CONFIG_GLDv3 -DGEM_CONFIG_VLAN_HW -DGEM_CONFIG_CKSUM_OFFLOAD -DSOLARIS10 -DGEM_CONFIG_JUMBO_FRAME -UGEM_CONFIG_ND -DGEM_CONFIG_MAC_PROP -Unotdef -UNEVER -UGEM_GCC_RUNTIME -UGEM_COMPAT -USANITY -UGEM_CONFIG_FMA -UMODULE -UGEM_CONFIG_RX_DIRECT -DGEM_CONFIG_TX_DIRECT -DGEM_CONFIG_TX_HEAD_PTR -UOS_PUTBACK -DCONFIG_POLLING -UCONFIG_NEW_POLLING -DVERSION='"2.6.2"' bfe_gem.c -o i386/bfe_gem.o
sh: line 1: cc: not found
*** Error code 127
make: Fatal error: Command failed for target `i386/bfe_gem.o'

Versuche ich, das oben auf gcc umzustricken, bekomme ich nach make DAS:

gcc -c -O2 -D__INLINE__=inline -DGEM_GCC_RUNTIME -ffreestanding -U_NO_LONGLONG -D_KERNEL -U_ASM_INLINES -D_SYSCALL32 -D_SYSCALL32_IMPL -Dsun -D__sun -D__SVR4 -DC2_AUDIT -Wall -Wno-unknown-pragmas -Wno-missing-braces -Wno-sign-compare -Wno-parentheses -Wno-uninitialized -Wno-implicit-function-declaration -Wno-unused -Wno-trigraphs -Wno-char-subscripts -Wno-switch -Wno-format -Werror -Di86pc -UDEBUG -DDEBUG_LEVEL=0 -DGEM_DEBUG_LEVEL=0 -UTEST_RX_EMPTY -UTEST_SMALL_DMA_RANGE -UDBG_NOBURST -UDBG_FAIRSCHED -UDEBUG_DUMP_REGS -UCONFIG_FLOW_CONTROL -I /usr/share/src/b111b/usr/src/uts/common -I /usr/share/src/b111b/usr/src/uts/intel -erroff=E_STATEMENT_NOT_REACHED,E_INTEGER_OVERFLOW_DETECTED -DGEM_CONFIG_POLLING -DGEM_CONFIG_GLDv3 -DGEM_CONFIG_VLAN_HW -DGEM_CONFIG_CKSUM_OFFLOAD -DSOLARIS10 -DGEM_CONFIG_JUMBO_FRAME -UGEM_CONFIG_ND -DGEM_CONFIG_MAC_PROP -Unotdef -UNEVER -UGEM_GCC_RUNTIME -UGEM_COMPAT -USANITY -UGEM_CONFIG_FMA -UMODULE -UGEM_CONFIG_RX_DIRECT -DGEM_CONFIG_TX_DIRECT -DGEM_CONFIG_TX_HEAD_PTR -UOS_PUTBACK -DCONFIG_POLLING -UCONFIG_NEW_POLLING -DVERSION='"2.6.2"' bfe_gem.c -o i386/bfe_gem.o
sh: line 1: gcc: not found
*** Error code 127
make: Fatal error: Command failed for target `i386/bfe_gem.o'

Ich habe keine Ahnung, was diese Fehlermeldungen besagen. Heißt "cc: not found" bzw. "gcc: not found" einfach: Kein Kompiler installiert? Wird da keiner mitgeliefert?

Auf das im Internet aufgeschnappte Kommando zur Suche nach dem installierten Compiler

# pkginfo | grep -i compile

Darauf kommt dann das:

system SUNWlibC Sun Workshop Compilers Bundled libC

Was auch immer das heißen mag.

Ich habe dann noch ein bisschen ohne Kompiler rumgefrickelt, bin aber dann immer beim altbekannten

# devfsadm -i bfe
devfsadm: driver failed to attach: bfe

hängengeblieben.

Hmpf.

 

[mensch183]

Ich habe keine Ahnung, was diese Fehlermeldungen besagen. Heißt "cc: not found" bzw. "gcc: not found" einfach: Kein Kompiler installiert?

... oder installiert und nur nicht gefunden. Wie auch bei MS-DOS und Windows werden ausführbare Dateien nur in den Verzeichnissen gesucht, die in $PATH stehen.

Ich habe keine Ahnung, wohin Opensolaris die Compiler legt, wenn sie denn installiert sind. Früher landete bei Solaris der Sun-Compiler als /opt/SUNWspro/bin/cc auf der Platte - wird wohl bei Opensolaris nicht mehr so sein? Suche also entweder auf der Platte direkt nach nach cc ("find / -type f -name cc") bzw. gcc oder schau in der Paketverwaltung nochmal nach, ob doch noch irgendwelche Compiler-Pakete zu finden sind (vielleicht ohne das Wort 'compile' in der Paketbeschreibung - ok, ist unwahrscheinlich ^^). Du hast die Suche eigentlich schon richtig gemacht. Wird wohl kein Compiler installiert sein.

SUNWlibC, was du gefunden hast, ist jedenfalls nur die C-Laufzeitbibliothek, nicht der Compiler. Früher hieß das Paket mit dem Sun-Compiler SUNWspro.

Da ich der einzige bin, der hier antwortet, und ich selbst null Opensolaris-Erfahrung habe, findest du vielleicht woanders bessere Hilfe als hier im Forum. Ich würde dir ja einfach zu einem Linux für deinen Rechner raten. Gerade der Hardwaresupport ist da richtig gut.

 

[fiestaforever]

Suche also entweder auf der Platte direkt nach nach cc ("find / -type f -name cc")

Da find' sich nix außer /usr/share/screen/utf8encodings/cc.
Das dürfte es wohl nicht sein.

bzw. gcc oder schau in der Paketverwaltung nochmal nach, ob doch noch irgendwelche Compiler-Pakete zu finden sind (vielleicht ohne das Wort 'compile' in der Paketbeschreibung - ok, ist unwahrscheinlich ^^). Du hast die Suche eigentlich schon richtig gemacht. Wird wohl kein Compiler installiert sein.

Sieht wohl so aus.

Da ich der einzige bin, der hier antwortet, und ich selbst null Opensolaris-Erfahrung habe, findest du vielleicht woanders bessere Hilfe als hier im Forum.

Wenn ich denn wüsste, wo. Seitdem Oracle OpenSolaris kaputtgeschlagen hat (die ganze Plattform, opensolaris.org, die Repositorien, diverse Blogs etc.), sind die meisten Quellen versiegt, wie mir scheint. Ich bin ja froh, dass überhaupt jemand mit mir spricht. Danke übrigens nochmal dafür.

Ich würde dir ja einfach zu einem Linux für deinen Rechner raten. Gerade der Hardwaresupport ist da richtig gut.

Es geht mir ja gar nicht um den Rechner sondern gerade um Open-/Solaris. Der Rechner ist nur das Versuchskaninchen, aber leider das einzige, was ich zu diesem Zweck zur Verfügung habe.

Mit Linux läuft die "Karte", weshalb ich einen Hardwaredefekt eigentlich ausschließen kann.

Inzwischen habe ich als Alternative mal eine Cardbus-Netzwerkkarte (D-Link DFE-690TXD mit Realtek RTL 8139) reingesteckt.
Ergebnis: Der Rechner (bzw. OpenSolaris) bootet damit nicht. Wenn ich die Karte später reinstecke, friert der Rechner ein.

Nachtrag: Wie ich inzwischen festgestellt habe, läuft auch die DFE-690TXD, mit der OpenSolaris "hängt", unter Linux...

 

[mensch183]

Der Rechner ist nur das Versuchskaninchen, aber leider das einzige, was ich zu diesem Zweck zur Verfügung habe.

Wäre es nicht angenehmer, statt auf dem Laptop auf einer virtuellen Maschine zu arbeiten?

 

[fiestaforever]

Wäre es nicht angenehmer, statt auf dem Laptop auf einer virtuellen Maschine zu arbeiten?

Das war ja auch mein erster Gedanke gewesen, und ich habe es auch so installiert.
Aber erstens es war es *viel* zu langsam (mein Desktop - Pentium 4 3 GHz - ist auch nicht wirklich schneller als dieser Laptop, es läuft auf dem Läppie mit 512 GB RAM deutlich besser als in der virtuellen Maschine mit 1GB zugewiesen). Und mein Macbook Pro ist derzeit nicht verfügbar.

Zweitens möchte ich gerne mit ZFS auf "echter" Hardware herumprobieren. Das Plattenherumwechseln ist auf der virtuellen Maschine ziemlich fummelig und nicht wirklich zielführend. Ich würde gerne ein paar so coole Experimente machen wie in diesem schon etwas älteren Kultvideo