Krisbee wrote: > Triode, > > Errors on storage.html ? Something seems to have happened at the update > to soa-web a couple days ago. > > 1. Umount results in this: > > '[image: http://s28.postimg.org/vybmy4j3d/soa8.jpg]' > (http://postimg.org/image/vybmy4j3d/) > > '[image: http://s30.postimg.org/lsxth7x0d/soa10.jpg]' > (http://postimg.org/image/lsxth7x0d/) > > There's no "remount" > > > 2. Remove results in an error page: > > '[image: http://s1.postimg.org/gla09wgtn/soa9.jpg]' > (http://postimg.org/image/gla09wgtn/) > > > Can you reproduce these errors? > > > 3. I have a more general question about NFS under ARCH. After reading > the ARCH WIKI https://wiki.archlinux.org/index.php/NFS, it seems you > need to enable *nfs-client.target* to use the Wandboard, or other host, > as a NFS client, but in the Wandboard ARCH image this is disabled. I > couldn't get a NFS share to mount at boot without enabling this target. > Can you reproduce this behaviour?
Triode, A. STORAGE.HTML Can confirm remove error is fixed. Remove button triggers correct action and entry in /etc/fstab is removed and filesystem unmounted correctly. More details on error one. I realised my post was when using webui via localhost as opposed to ip addr. None the less, I would have thouhgt both should work. On re-testing the is still an error whether using http://127.0.0.1/storage.html or http://192.168.0.88/storage.html. The error actually is this: 1. add nfs written to /etc/fstab - yes appears on web page - yes mounted - yes 2. umount written to /etc/fstab - no (that's OK) umounted -yes but mount/remount button disappears, so no way to remount. B. NFS UNDER ARCH Triode wrote: > I need to look at nfs later. How many people really want an nfs mount? Well, apart from the fact that cifs, nfs and nfs4 are all on the WebUI, surely for an all Linux network, nfs is the natural choice? It ought to be straightforward, but ARCH + systemd seem to have made it tricky. I hope you can look at this soon, as when using a version 3 nfs server, which is commonplace on a home network, you have to enable *nfs-client.target* , and ensure these services are running: Code: -------------------- rpc-gssd.service loaded active running RPC GSS-API Client Daemon rpc-statd.service loaded active running NFS v2/3 Network Status Monitor Daemon rpcbind.service loaded active running RPC Bind -------------------- Even then you could well face another problem that the nfs share will not mount on boot due to the order in which systemd initialise services. In my testing on a i686 VM, I get this: Code: -------------------- Jun 14 12:39:15 soapvm systemd[1]: Reached target Remote File Systems (Pre). Jun 14 12:39:15 soapvm systemd[1]: Mounting /mnt/disk1... Jun 14 12:39:15 soapvm systemd[1]: Starting Sound Card. Jun 14 12:39:15 soapvm systemd[1]: Reached target Sound Card. Jun 14 12:39:15 soapvm mount[191]: mount.nfs: Network is unreachable Jun 14 12:39:15 soapvm systemd[1]: mnt-disk1.mount mount process exited, code=exited status=32 Jun 14 12:39:15 soapvm systemd[1]: Failed to mount /mnt/disk1. Jun 14 12:39:15 soapvm systemd[1]: Dependency failed for Remote File Systems. Jun 14 12:39:15 soapvm systemd[1]: Unit mnt-disk1.mount entered failed state. Jun 14 12:39:15 soapvm systemd[1]: Starting Trigger Flushing of Journal to Persistent Storage... Jun 14 12:39:15 soapvm ifplugd[178]: client: Starting network profile 'enp0s3'... -------------------- i.e. Systemd attempts to mount nfs share before network card has been started. Code: -------------------- [root@soapvm ~]# systemd-analyze blame 701ms systemd-vconsole-setup.service 666ms systemd-remount-fs.service 652ms systemd-logind.service 623ms rpcbind.service 537ms systemd-modules-load.service 532ms tmp.mount 531ms sys-kernel-debug.mount 530ms dev-mqueue.mount 525ms dev-hugepages.mount 482ms rpc-statd.service 355ms systemd-udev-trigger.service 353ms kmod-static-nodes.service 329ms rpc-gssd.service 215ms systemd-tmpfiles-setup-dev.service 142ms systemd-udevd.service 80ms systemd-random-seed.service 75ms systemd-update-utmp.service 72ms systemd-journal-flush.service 70ms systemd-sysctl.service 65ms systemd-tmpfiles-setup.service 59ms user@0.service 17ms mnt-disk1.mount 17ms systemd-user-sessions.service 15ms dev-disk-by\x2duuid-29c57a28\x2d5b0c\x2d449f\x2d9568\x2dd219361b23f6.swap 3ms sys-kernel-config.mount 2ms var-lib-nfs-rpc_pipefs.mount -------------------- The ArchWIKI suggest using systemd automount service to overcome this timing problem, but it doesn't work for me. https://wiki.archlinux.org/index.php/NFS#Client Perhaps all is OK an the Wandboard, it's certainly not for i686/x86_64. However, changing from netctl/ifplugd to NetworkManager and invoking the NetworkManager-wait-online.service solves this problem. NFS shares mount on boot without problem, but then of course you'd have to use a nm-applet to confgure the network. So I'd be v. interested if there's a systemd solution to mounting NFs shares when network is controlled by netctl/ifplugd. ------------------------------------------------------------------------ Krisbee's Profile: http://forums.slimdevices.com/member.php?userid=59080 View this thread: http://forums.slimdevices.com/showthread.php?t=101624 _______________________________________________ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
