planetknauer.net

Als ich meinen Desktop und Server zusammenstellte, hatte ich bewusst für beide Geräte das gleiche Mainboard verwendet. Somit muss ich alle Mainboard-bedingten Probleme nur einmal lösen. Soweit hat das alles ganz gut funktioniert, aber unterdessen hat der Hersteller ein paar BIOS-Updates herausgegeben, welche Performance und Stabilität (nicht, dass das ein Problem wäre) verbessern würden. Na dann, spielen wir die mal ein. Da das Board von flashrom unterstützt wird, geht das total simpel direkt von Linux aus.

Erst das alte BIOS sichern:

flashrom -r old-bios.rom

Dann das neue BIOS flashen:

flashrom -w new-bios-image.rom

Vor einigen Wochen war erst der Desktop fällig. Nach dem Neustart durfte ich feststellen, dass die MAC-Adresse der Netzwerkkarte sich geändert hatte. Das ist halb so wild, da wird die /etc/udev/rules.d/70-persistent-net.rules gelöscht oder modifiziert und anschliessend neu gestartet.

Heute war der Server dran. BIOS geflasht, die udev-Regeln gelöscht, neu gestartet, alles bestens. Per SSH versucht anzumelden. Geht nicht. hmmm. Mal die Netzwerkkarten geprüft. Alles bestens. Ping von Server und Desktop zu jedem anderen Host klappt, nur nicht untereinander. dmesg geprüft:

br0: received packet on eth0 with own address as source address

Nochmals genau hingeschaut und ifconfig eth0 auf beiden Maschinen eingetippt und die MAC-Adresse genauer angeschaut. Un-glaub-lich! Identisch auf beiden Kisten. Die Deppen bei Asus haben es doch tatsächlich fertiggebracht, ein BIOS-Image zu verteilen, in welchem die MAC-Adresse für die onboard-Netzwerkkarte hartcodiert ist! Ja ist es denn wirklich so viel zuviel verlangt, wenigstens ein Mal mit Profis (oder zumindest nicht komplett inkompeteten Amateuren) zu arbeiten???

Würgaround:

ifconfig eth0 hw ether 00:e0:12:34:56:77

Unter Debian macht man dies permanent durch einen Eintrag in der /etc/network/interfaces:

allow-hotplug eth0
iface eth0 inet dhcp
hwaddress ether 00:e0:12:34:56:77

Nicht mehr ganz so trivial wird das, wenn nun eth0 gebridged wird, damit KVM oder XEN Virtual Machines das Netzwerk mitbenutzen können. In diesem Fall ist eth0 nicht in der interfaces konfiguriert (bzw auf manual gesetzt), so dass jegliche Einträge aus der Sektion nicht gelesen werden. Hier muss der Konfiguration von br0 ein pre-up Befehl mitgegeben werden:

iface eth0 inet manual

auto br0
iface br0 inet static
pre-up ifconfig eth0 hw ether 00:e0:12:34:56:77
bridge_ports eth0
address 192.168.0.XXX
netmask 255.255.255.0
gateway 192.168.0.XXX

Mit den Standardoptionen macht ein Systemstart mit per NFS verbundenen Laufwerken nur so lange Spass, wie der Server erreichbar ist. Ist der Server bzw das Netzwerk nicht erreichbar, so führen die Standardoptionen dazu, dass Debian während dem Systemstart minutenlang versucht zu mounten - und in der Zwischenzeit nicht weiterbooten will. Die Mountversuche lassen sich auch nicht mit CTRL-C oder anderen Tastenkombinationen abbrechen. Da kann man nur warten und sich ärgern... oder die /etc/fstab gleich von Anfang an mit den richtigen Optionen ausstatten.

Jetzt schauen meine Einträge für NFS-mounts so aus:

nas:/storage /mnt/storage nfs4 bg,retry=0,timeo=2,_netdev 0 0

Was passiert hier? Die Freigabe /storage vom Server nas wird nach /mnt/storage per NFS4 eingebunden. Schlägt der erste Mountversuch fehl (retry=0), geht der Mountprozess in den Hintergrund (bg) und versucht es dort weiter. Als Fehlschlag wird der Mountversuch gewertet, wenn die Antwort vom Server nicht innert 0.2s eintrifft (timeo=2). retry=0 zu setzen ist ganz wichtig, da der Wert bei Verwendung von bg standardmässig auf 10000 Minuten gesetzt ist. Da wartet man im dümmsten Fall fast eine Woche lang.
_netdev sorgt dafür, dass ein Mountversuch erst stattfindet, nachdem das Netzwerk gestartet wurde.

Sehr nützlich ist das auch für Notebooks.

Falls das Serverlog daraufhin Fehlermeldungen der Art "rpc-srv/tcp: nfsd: sent only 180288 when sending 524352 bytes - shutting down socket" enhält, sollte der Wert für timeo etwas erhöht werden.

Lesematerial dazu:

man 5 mount