NFS-Mount geht nicht automatisch

h^2

hat ne Keule +1
Ich habe hier schon seit einiger Zeit ein ziemliches nerviges Problem undzwar mountet er NFS-Dateisystem nicht automatisch nach dem Start. Das obwohl diese das late flag haben.

Meine Analyse ist, dass das Networkdevice erst danach hochkommt, was aber ziemliche Unsinn wäre (das müsste die init-Skripte doch machen). In der Dmesg finde ich sowas:
rpc.statd: Failed to contact host X.X.X.X: RPC: Port mapper failure - RPC: Unable to send
alc0: link state changed to UP

Wenn ich dann bei late das mounten abbreche, kann ich mich mit root einloggen und ein
Code:
mount -t nfs -al
läuft sofort durch.
Nervt mich aber, der boot dauert schon lange genug und ich würde gerne auto-login in X machen, wozu ich das home brauche.

Ich habe bei den alc0 flags in der rc.conf auch extra noch ein UP hinzugefügt, was auch nicht hilft (habe ich fürher auch nie gebraucht).

edit: FreeBSD-9.0-Beta1, amd64
 
Das selbe Problem hab ich auch. Komischerweise triit es bei mir nur mit Gigabit Ethernetkarten auf. Mit einer 100MBit Karte hab ich das Problem nicht. An einer Lösung wäre ich also auch interessiert.
 
Nutzt du vielleicht DHCP? Wenn ja, wolltest du dir mal die rc.conf-Optionen "synchronous_dhclient" und "background_dhclient" anschauen. Damit kannst du (auf Kosten etwas längerer Bootzeit) erzwingen, dass die Interfaces einsatzbereit sind, bevor spätere rc-Scripte ausgeführt werden.

Ansonsten gibt es einige Netzwerkkarten - ich weiß nicht, ob deine dazu gehört, aber ihre Vorgänger mit age(4) tun es - die IP-Adressänderungen nicht sofort übernehmen. Die Adresse wird gesetzt, das Kommando geht durch und der Kernel denkt sie sei da, die Hardware legt allerdings noch eine Bedenkpause ein um ihre Firmware neu zu starten oder so. Das kann schon mal einige Sekunden dauern. Da würde es helfen an der richtigen Stelle in den rc-Scripten ein dezentes "sleep" einzufügen und eine Wartezeit erzwingen.
 
Nutzt du vielleicht DHCP? Wenn ja, wolltest du dir mal die rc.conf-Optionen "synchronous_dhclient" und "background_dhclient" anschauen. Damit kannst du (auf Kosten etwas längerer Bootzeit) erzwingen, dass die Interfaces einsatzbereit sind, bevor spätere rc-Scripte ausgeführt werden.
Ne setup ist statisch.

Ansonsten gibt es einige Netzwerkkarten - ich weiß nicht, ob deine dazu gehört, aber ihre Vorgänger mit age(4) tun es - die IP-Adressänderungen nicht sofort übernehmen. Die Adresse wird gesetzt, das Kommando geht durch und der Kernel denkt sie sei da, die Hardware legt allerdings noch eine Bedenkpause ein um ihre Firmware neu zu starten oder so. Das kann schon mal einige Sekunden dauern. Da würde es helfen an der richtigen Stelle in den rc-Scripten ein dezentes "sleep" einzufügen und eine Wartezeit erzwingen.
Das würde im Prinzip Sinn machen, es ist aber so dass ich beliebig lange warten kann und NFS ja auch weiterhin versucht zu mounten, ohne dass es klappt. Erst wenn er zu lange retried hat oder ich abbreche geht es weiter und dann kann ich auch mounten.
Das spricht gegen eine leicht Verzögerung im Hintergrund.
 
Da ich ähnliche und auch einige andere Probleme mit dem Einhängen von NFS-Freigaben über die fstab beim Booten hatte, habe ich das ganz und gar sein lassen und mounte quasi-manuell durch ein script automatisch. Dabei mache ich eine einzige Haupt-Abfrage vorab, nämlich, ob mein Server auf Ping antwortet.
Das sieht etwa so aus
ping=$(ping -c1 $IP | grep time), wobei IP= die IP-Adressen meiner Server sind, die durchlaufen werden.
Später schaue ich dann
if [ "$ping" != "" ]
then....
und bei einem Server zeigte es sich, dass es außerdem notwendig war, den Export einer Freigabe zu checken und deshalb habe ich dann da etwas mit showmount -e ... | sed ... eingefügt, um nachzusehen.

Damit kann ich insgesamt flexibler reagieren und binde dann meine NFS-Server ein, wenn die da sind und wenn nicht, kann trotzdem das System hochlaufen und eben das Arbeiten, was ohne diese Freigaben geht.
Das Einbauen einer Warteschleife, bis ein entsprechendes Ergebnis erscheint, ist auch simpel und kann natürlich auf eine maximale Zeit (Anzahl von Abfragen) beschränkt werden.

Dass es so viel besser funktioniert, weiß ich erst recht zu würdigen, seit ich meinen PC regelmäßig abschalte. Und da funktioniert es so gut, dass ich das unbedingt weiter empfehlen möchte.
Über die fstab würde ich das nicht mehr machen und auch im Vergleich zu anderen Automatismen, wie etwa durch HAL und so, bin ich mit so einem einfachen Script glücklicher.

Das ist nun aber allgemein gesprochen und hat nicht mit dem Wechsel auf ein 9er FreeBSD zu tun.
 
Gibt es noch irgendwas was ich hier tun kann um das Problem einzugrenzen? Es nervt mich nämlich ziemlich...

Ich habe übrigens festgellt, dass wenn ich in single-user-mode starte, dann direkt wieder raus gehe, läuft der boot normal durch, mit nfs-mounts.

Auch scheint insgesamt nicht nur das hochkommen, sondern auch das runterkommen der Netzwerkkarte später zu passieren, so habe ich bei einem reboot ein
Code:
alc0: link state changed to DOWN
erst NACH allem anderen, also nach die Puffer gesynct werden...
 
hattest du es mal mit einem script probiert?
Du könntest ja zunächst ifconfig auswerten und sehen, ob deine NIC eine IP hat.
Dann sehen, ob der Server da ist, antwortet und exportiert.
Danach mounten und vielleicht melden.

Das sollte doch gehen?
Bei einem PC hatte ich die IP-Adresse ausgewertet (er wurde an unterschiedlichen Orten/Netzen genutzt) und in Abhängigkeit davon dann unterschiedliche Freigaben passend gemountet.

Die rc-Scripte dürften erst nach Durchlauf von fstab laufen und da sollte auch das Netzwerk schon da sein, wenn auch evtl noch nicht mit gültigen Parametern versehen. Deshalb glaube ich an die Lösung über ein Script.
 
Also ich habe da noch was rumprobiert. Wenn ich ein normales rc-Skript schreibe und per REQUIRE dafür Sorge, dass es nach allen anderen geladen wird, dann klappts trotzdem nicht. Wenn ich aus Skript rausforke, sleep 5 davor tue, dann gehts. Sehr merkwürdig. Wie gesagt, wenn ich ihn einfach idlen lasse ausm rc-Skript klappt es auch nach einer Weile nicht. Wenn ich rausgehe, dann klappts :confused:
 
Zurück
Oben