atari-home.de - Foren
Software => Alternative Betriebssysteme => Thema gestartet von: Nervengift am Fr 20.11.2015, 22:13:12
-
Moin, moin,
ich dachte mir, ich bringe meinen PowerMac G5 (Mac OS 10.5) und meinen Milan040 (easymint 1.90) per NFS zusammen wobei der G5 den Server macht. Folgende Freigaben sind dort in der "/etc/exports" gesetzt:
/Volumes/Daten/Music -ro -mapall=nobody -network 192.168.2 -mask 255.255.255.0
/Volumes/Filme/Filme -ro -mapall=nobody -network 192.168.2 -mask 255.255.255.0
/Volumes/Daten/Transfer -mapall=nobody -network 192.168.2 -mask 255.255.255.0
Auf dem Milan klappt das Mounten über die Kommandozeile der Freigaben ohne Fehlermeldungen mit z. B. folgendem Kommando:
mount_nfs -v -o ro,rsize=1024,wsize=1024,retrans=10 192.168.2.201:/Volumes/Daten/Music /nfs/Musik
Auch in der fstab klappt das Mounten beim Booten ohne Probleme mit folgenden Einträgen:
c / dos root wheel 700
d / ext2 root wheel 777
e / dos root wheel 700
192.168.2.201:/Volumes/Daten/Music /nfs/Musik nfs 1024 10
192.168.2.201:/Volumes/Daten/Transfer /nfs/Transfer nfs 1024 10
192.168.2.201:/Volumes/Filme/Filme /nfs/Filme nfs 1024 10
Das war's dann leider aber auch schon, was ohne Probleme klappt. Versucht man mit Thing 1.29 auf den "/nfs"-Ordner zugreifen stürzt Thing ab (Screenshot der Fehlermeldung als Anhang). Greift man mit der bash auf den "/nfs"-Ordner zu, dann kommt man in den Ordner rein und die gemounteten Freigaben werden dort auch aufgelistet, aber sobald man versucht auf eine der Freigaben zuzugreifen, stürzt die bash ab (Screenshot der Fehlermeldung als Anhang). >:(
Hat jemand vielleicht eine Idee wo der Fehler liegt? Habe ich in meiner Konfiguration Mist gebaut oder liegt das an MiNT 1.19.cur bzw. dem dazugehörigen XaAES?
Andreas
-
Die Absturzadresse ist jedesmal gleich, und nicht im Text des abgestürzten Programms. Jetzt müsste man wissen, wem 0x1055c80 gehört. XaAES schreibt seine Text-Adresse ins xa_boot.log, aber ich kann mir nicht vorstellen, dass es was damit zu tun hat. Mehr weiß ich leider nicht.
Ich würde mal INIT=u:/bin/bash oder so, also ohne AES versuchen. Aber wenn die dann gekillt wird, und MiNT ist der parent-Prozess, ist Ende, also vorher nochmal bash starten.
-Helmut
-
Wenn ich über die Kommandozeile auf die Freigaben zugreifen möchte, funktioniert das auch nicht. :( Führt auch zum Absturz. Insofern fällt XaAES wohl raus als Übeltäter? Anbei noch ein Foto der Fehlermeldung.
Mit meinem Hackintosh (OS 10.10.5) kann ich problemlos auf die Freigaben zugreifen. Falls das von Belang sein sollte.
-
Bei mir klappt das ...
Um auszuschliessen das es doch an OSX liegt verwende mal den NFS Manager -> http://www.bresink.com/osx/NFSManager-de.html
... zuvor die alten Einträge in exports löschen. Bei mir habe ich den Zugriff für jeden freigegeben und nur das Netzwerkwerk begrenzt auf meins 192.168.2.0
Ich habe mir den NFS Manager gekauft. Da gibt es auch ältere Versionen für OSX 10.5.x ...
-
Um auszuschliessen das es doch an OSX liegt verwende mal den NFS Manager -> http://www.bresink.com/osx/NFSManager-de.html
@Lukas Frank: Der NFS Manager macht ja auch nichts anderes als die entsprechenden Einträge in die "/etc/exports" zu setzen. Interessanterweise klappt das Mounten ja ohne Probleme. Dann nur der Absturz, wenn man auf den Share zugreifen möchte. Ich habe auch schon andere Optionen ausprobiert wie z. B.:
/Volumes/Filme/Filme -ro -alldirs
/Volumes/Daten/Transfer -alldirs
/Users/andreas/Downloads/Atari -alldirs
Immer wieder dasselbe Verhalten. Mounten ist kein Problem und beim Zugriff dann der Absturz. :'(
Vielleicht kannst Du ja mal den Inhlat Deiner "/etc/exports" posten? Dann checke ich das mal gegen. NFS Manager möchte ich jetzt ungern kaufen, wenn es eh nicht funktionieren sollte auf dem Milan. Ich fürchte, das wird sehr wahrscheinlich an dem MiNT-Kernel liegen. Irgendwas läuft da schief oder nicht so wie es sollte.
-
Kann am Montag mal schauen aber ich meine den NFS Manager kannst du auch ausprobieren ohne den zu kaufen ...
Weiss nicht ob nur die exports Datei reicht, ich meine FTP und NFS ist gar nicht aktiviert beim OSX beim der normalen Version, es sei denn du hast die Server Version !?!
-
Ziemlich sicher liegt das an dem nfs.xfs, und nicht an der anderen Seite.
-
Das 1-19-cur MiNT/XaAES vom EasyMiNT 1.90 Paket ist ein älterer trunk von Anfang/Mitte 2015, oder ?
-
Ich habe jetzt mal den Trunk vom 22.11.2015 geladen (trunk-22112015.tar.bz2) und installiert. Da gibt's dann auch einen entsprechenden Absturz, aber die Fehlermeldung ist etwas anders. Ich kann den Inhalt nur nicht beurteilen. Deswegen wieder ein entsprechender Screenshot anbei. Ich habe auch MiNT 1.18.0 auspropiert und da verhält es sich tatsächlich anders. Nur leider nicht besser, da dann der komplette Rechner beim Zugriff auf einen Share über die bash einfach einfriert. :'(
Wär kümmert such denn in dem MiNT-Team um die nfs.xfs? Vielleicht könnte ich den ja mal ansprechen deswegen?
-
Das ist meine etc/exports ...
/Users/frank/Downloads/Atari -maproot=0:0 -network 192.168.2.0 -mask 255.255.255.0
-
Stürzt mit den Einstellungen leider auch ab. >:( :-[ :'( Wäre auch irgendwie zu schön gewesen, wenn das so "out of the box" funktioniert hätte.
-
NFS funktioniert bei mir wunderbar auf der FireBee mit dem alten 1.19er Kernel von Vincent. Das ging auch mal mit dem Mega ST, jetzt mit den aktuellen Builds aber nicht mehr. Ging schon mal nicht 2014 oder so und dann wurde das gefixt. Kann aber auch sein dass, das enec.xif auf dem ST mit MiNT bei mir nicht mehr richtig läuft.
Bei mir auf dem ST kommt immer ein "do_nfs_mount: RPC: Timed out" und "mount_nfs: could not do NFS mount" ...
Mein ping läuft auch sehr, sehr schleppend.
-
NFS funktioniert bei mir wunderbar auf der FireBee mit dem alten 1.19er Kernel von Vincent. Das ging auch mal mit dem Mega ST, jetzt mit den aktuellen Builds aber nicht mehr. Ging schon mal nicht 2014 oder so und dann wurde das gefixt. Kann aber auch sein dass, das enec.xif auf dem ST mit MiNT bei mir nicht mehr richtig läuft.
Also könnte das auch am Netzwerkkartentreiber liegen? Ich muss mal sehen, aber vielleicht kann ich das in der Mint-Mailingliste posten oder so, falls man dort so einfach reinkommt. Ich find's schon etwas schade, dass es nicht wirklich mehr eine MiNT-Webseite gibt, über die man z. B. auch Fehler melden könnte. Das wäre eine sehr nette Sache. So muss ich erstmal sehen und suchen wer sich dafür zuständig ist/fühlt.
-
Da ist die Mailing Liste, recht aktiv -> http://sparemint.org/mailinglist/
-> http://sparemint.atariforge.net/mailinglist/Mailing-Lists/MiNT-List.index.html
-
Gerade nochmal auf meinem Atari Mega ST unter MiNT probiert und bei mir läuft das mit NFS einwandfrei, meine NetusBee hatte Kontakt Probleme am Romport.
Ich nutze den aktuellen helmut build von der freemint.org Seite. Vielleicht kommt dein Problem vom Treiber für deine Netzwerkkarte ?
-
Ich nutze den aktuellen helmut build von der freemint.org Seite. Vielleicht kommt dein Problem vom Treiber für deine Netzwerkkarte ?
Ich hatte den Trunk Build geladen und installiert. Welche Unterschiede gibt es denn zwischen dem Trunk Build und dem Helmut Build? Der nfs-Treiber wird in beiden Builds wohl derselbe sein?
Kann schon sein, dass das auch ein Treiberproblem ist. Nur habe ich bei der verwendeten Karte nicht wirklich eine Alternative, fürchte ich:
http://assemsoft.atari.org/rtl8139/
Ansonsten funktioniert die Karte problemlos. Ich will das mit der MiNT-Mailingliste auch nochmal ausprobieren. Ich muss mich nur mal hinsetzen und die Infos zusammentragen und das dann alles in Englisch. Das schreckt mich etwas ab. ;)
-
Gibt gute Neuigkeiten zu Weihnachten: Ich habe den Übeltäter ausmachen können! :D Der NFS-Treiber, der bei MiNT 1.18.0 (totales Einfrieren des Milan) und bei MiNT 1.19.cur (siehe entsprechende Fehlermeldungen) dabei ist, funktioniert nicht ordnungsgemäß auf dem Milan und verursacht die beschriebenen Probleme. Der NFS-Treiber, der bei MiNT 1.17.0 enthalten ist (Version 0.57) läuft einwandfrei auf dem Milan! Ich kann jetzt endlich auf meine NFS-Shares zugreifen, was für mich Datenübertragungen um einiges einfacher gestaltet. 8) Die 0.57er Version läuft auch unter MiNT 1.19.cur. Also musste ich jetzt nur den NFS-Treiber austauschen.
Anbei auch noch ein Beweisscreenshot. ;D Was noch ein wenig doof ist, ist die Sache mit den Umlauten bzw. der Zeichencodierung, aber das ist letzten Endes nebensächlich. Ich bin auch am Überlegen ob ich das mal in der MiNT-Mailingliste melden sollte, falls sich jemand dafür zuständig fühlen sollte?
-
Ich würde es mal in der Mailingliste erwähnen. Wir habe in unserem Hause auch ein Entwickler sitzen, der bei solchen Fehlern immer sagt: Uh, da habe ich eine klitze, klitze kleinigkeit vergessen...
-
Ich würde es mal in der Mailingliste erwähnen. Wir habe in unserem Hause auch ein Entwickler sitzen, der bei solchen Fehlern immer sagt: Uh, da habe ich eine klitze, klitze kleinigkeit vergessen...
Ich fürchte nur, den Bugbericht muss ich an mich selbst schreiben und ordentlich Asche auf mein Haupt streuen! :-[ Manchmal sitzt das Problem eben doch vorm Rechner. MiNT 1.19.0 und das dazugehörige nfs.xfs trifft keine Schuld. Zumindest nicht primär, würde ich mal sagen. Aber eben mal der Reihe nach bzw. die Erklärung, was da nicht in Ordnung war:
Ich hatte mit verschiedenen MiNT Versionen Tests durchgeführt, was NFS betraf. Mit MiNT 1.17.0 funktionierte NFS dann. Danach hatte ich das nfs.xfs von MiNT 1.17.0 unter MiNT 1.19.0 ausprobiert und siehe da, NFS funktionierte. Dann fiel mir aber heute auf, dass ich in TOSWIN2 die Console nicht mehr öffnen konnte und der entsprechende Menüpunkt ausgegraut war. Also hatte ich überprüft ob da noch alles an seinem Platz war und ordnungsgemäß konfiguriert war. Das war der Fall. Da stand ich schon fast der Verzweifelung nahe. :'( Bis mich dann ein fieses Gefühl beschlich! Die Reihenfolge der Treiber im MiNT-Odner spielt eine ähnliche Rolle wie die der Programme im Autoordner. Also bin ich dabei gegangen und habe das alles in eine logische Reihenfolge gebracht. Dabei habe ich dann auch das nfs.xfs von MiNT 1.19.cur wieder verwendet. Und siehe da ... nach dem Reboot ging die Console wieder so wie sie sollte und NFS auch. :D Das fällt dann unter die Rubrik: "Ich bin zu dämlich!"
Also vergesst das mal, was ich alles geschrieben hatte. Ist letzten Endes alles Mumpitz! :-X
-
Also eigentlich kann man vom Anwender wohl kaum erwarten, dass es die Treiber im MiNT-Ordner irgendwie sortiert, oder hab ich da was falsch verstanden? Sonst denke ich, es ist immer noch ein Fall für die mailing-Liste. Mit möglichst einfach zu reproduzierender Beschreibung, wenn's geht.
-Helmut
-
Also eigentlich kann man vom Anwender wohl kaum erwarten, dass es die Treiber im MiNT-Ordner irgendwie sortiert, oder hab ich da was falsch verstanden?
Nein. Du hast das vollkommen richtig verstanden. Ich habe die Treiber im MiNT-Ordner sortiert: Erst die ganzen *.xxd-Dateien (serielle Schnittstellen, parallele Schnittstelle, Console, MiNT-Net), dann die *.xif-Dateien ( 1 x Netzwerkkartentreiber) und dann die *.xfs-Dateien (ext2-, Minix-, nfs- und CD-ROM-Treiber). Danach lief alles rund.
Sonst denke ich, es ist immer noch ein Fall für die mailing-Liste. Mit möglichst einfach zu reproduzierender Beschreibung, wenn's geht.
Versuchen kann ich's, aber ich fürchte, ich komme an meine alte Sortierreihenfolge nicht mehr ran. :-[
-
Vielleicht einfach alphabetisch? Oder wenn die Treiber alle aus dem selben Archiv sind, dann ist es vielleicht die Reihenfolge da drin?
Könnte jedenfalls schwierig werden, und dann fühlt sich keiner zuständig ...
-
Vielleicht einfach alphabetisch? Oder wenn die Treiber alle aus dem selben Archiv sind, dann ist es vielleicht die Reihenfolge da drin?
Könnte jedenfalls schwierig werden, und dann fühlt sich keiner zuständig ...
Ich hatte die entsprechenden Dateien in dem MiNT-Archiv markiert und dann in den MiNT-Systemordner rüberkopiert. Ich bin mir aber nicht 100 %-ig sicher ob ich alle Dateien aus dem MiNT-Archiv auf einem Mal rüberkopiert hatte oder in zwei/drei Schritten. Zwischendrin hatte ich auch auf jeden Fall den Netzwerktreiber und das spin.xfs rüberkopiert. Ganz rekonstruieren kann ich das nicht mehr, fürchte ich. Da war ich dann wohl wieder mal zu schnell bei der Sache.