[RANT] Raspbian und /etc/fstab

Seite 1 von 1 - Forum: Linux and other OS auf overclockers.at

URL: https://www.overclockers.at/linux/rant-raspbian-und-etc-fstab_254986/page_1 - zur Vollversion wechseln!

UnleashThebeast schrieb am 04.01.2020 um 17:42

Ich muss hier jetzt mal kurz ranten, weil ich echt am auszucken bin mit diesem Mist.

Ich will auf einem Raspberry ein NFS-Share von meinem NAS mounten, um dort Datenbanken abzulegen (die SD-Karte mag Datenbanken ja nicht so super besonders).

Gut, also rein in die /etc/fstab:

Code:

192.168.0.253:/volume1/databases        /mnt/database   nfs auto,_netdev,nofail,noatime,nolock,intr,tcp,actimeo=1800 0 0

Aber, nach einem Reboot, Überraschung!

Code:

Jan 04 17:28:57 WetterPi rc.local[395]: mount.nfs: Network is unreachable
Jan 04 17:28:57 WetterPi mount[403]: mount.nfs: Network is unreachable
Jan 04 17:28:57 WetterPi dhcpcd-run-hooks[431]: wlan0: starting wpa_supplicant
Jan 04 17:28:57 WetterPi systemd[1]: rc-local.service: Control process exited, code=exited, status=32/n/a
Jan 04 17:28:57 WetterPi systemd[1]: rc-local.service: Failed with result 'exit-code'.
Jan 04 17:28:57 WetterPi systemd[1]: Failed to start /etc/rc.local Compatibility.
Jan 04 17:28:57 WetterPi systemd[1]: mnt-database.mount: Mount process exited, code=exited, status=32/n/a
Jan 04 17:28:57 WetterPi systemd[1]: mnt-database.mount: Failed with result 'exit-code'.
Jan 04 17:28:57 WetterPi systemd[1]: Failed to mount /mnt/database.

Komisch, dass du Kreuwl ein NFS-Share nicht mounten kannst, wenn du noch nicht mit dem Netzwerk verbunden bist, nün? :rolleyes:

Was macht man also als unglaublich schirchen Workaround? richtig!
/etc/rc.local bekommt vor dem exit noch ein

Code:
mount -a

Wird ja funktionieren, oder?

Code:

pi@WetterPi:~ $ df -v
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/root       30351740 6910820  22126152  24% /
devtmpfs          860916       0    860916   0% /dev
tmpfs             993012       0    993012   0% /dev/shm
tmpfs             993012    8612    984400   1% /run
tmpfs               5120       4      5116   1% /run/lock
tmpfs             993012       0    993012   0% /sys/fs/cgroup
/dev/mmcblk0p1    258095   53034    205061  21% /boot
tmpfs             198600       0    198600   0% /run/user/1000
pi@WetterPi:~ $

AHRGL!
Hat jemand noch eine Idee, wie ich das zum funktionieren bekomme?

issue schrieb am 04.01.2020 um 19:07

Pack bei den mountoptions "x-systemd.automount" dazu
https://wiki.archlinux.org/index.ph...ab_with_systemd

matiss schrieb am 04.01.2020 um 22:20

Könnte sein das du das gleiche Problem hast wie ich hier in der Firma. Falls du WLAN verwendest das startet sehr langsam/spät. Musste ein Script mit einem Wait in den Autostart packen damit er erst verzögert die Verbindung herstellt.

davebastard schrieb am 04.01.2020 um 22:31

bei systemd kann man abhängigkeiten amngeben wo man in einem file angibt welche services schon laufen müssen (in dem fall wlan) bevor das skript (welches den mount ausführt) gestartet wird.
Details weiß ich aber nicht aus dem FF musst in der doku nachschauen.

edit: so wie im letzten post müssts auch klappen, also ein script wird automatisch ausgeführt wenn das interface up ist:
https://www.linuxquestions.org/ques...25/#post5966141

UnleashThebeast schrieb am 04.01.2020 um 22:44

Ich habs jetzt nach zigmaligen hin und herprobieren anders gelöst

mittels raspi-config kann man einstellen, dass beim boot aufs Netzwerk gewartet wird. Funktioniert jetzt einwandfrei, ohne zusätzliche mountoptions oÄ.

Finds nur bisschen halblustig, dass sowas nicht default ist, ich mein ein NFS Share kann nicht anders kommen als übers netzwerk, aber ja.

Übrigens kein WLAN, sondern direkt mit Kabel am Switch und fixer IP.

davebastard schrieb am 04.01.2020 um 22:57

Zitat
mittels raspi-config kann man einstellen, dass beim boot aufs Netzwerk gewartet wird. Funktioniert jetzt einwandfrei, ohne zusätzliche mountoptions oÄ.

auch eine gute lösung.
default mäßig sollte das wirklich nicht sein wenns mit kabel ist.