Move /storage on NFS via WIFI

1st Official Post

    I am configuring a LibreELEC box on a RPi Zero, that will (probably) get powered off frequently, and do not want to have to deal with SD corruption.

    Is it possible to move "/storage" to a NFS share, using only WIFI? Has anybody done this before? Any hints?

    Many thanks!

    It's impossible to do it via wifi, as the initramfs doesn't have the means to set up a wireless connection. If you can make your RPi PXE boot then you could have /storage (and /flash) on NFS.

    Thanks for your help!

    Please notice that I just want to move "/storage" to NFS, not the whole SD card (the "/flash" partition is already mounted read-only, so I do not worry about it). As far as I know, the root filesystem in a LibreELEC configuration is inside the SYSTEM file on "/flash" (which I do not intend to move to NFS).

    I think it should be possible to boot the system just from "/flash", then start the wireless connection, and finally mount "/storage".

    Some progress:

    Following the instructions at "/storage/.config/system.d/nfs.mount.sample", I could mount a NFS share at boot; however:

    * I will be mounting the NFS share on top of the already mounted "/storage" filesystem (I can deal with this).

    * systemd refuses to mount on "/storage", as it is hard-coded as an "API file system" (I cannot change this).

    Looks promising.

    • Official Post

    My $0.02 is that the /boot partition is equally susceptible to card corruption as the /storage partition. Script/automate a nightly backup and just accept that things die once in a while instead of using fragile netboot workarounds over unreliable wifi.

    After some learning about LibreELEC, I think that the most critical part of /storage is the kodi folder. The media folders are not going to be updated never (all media will be on a remote server), and configuration folders are rarely going to be updated. Thus, if I move just the kodi folder to the NFS server, the probabilities of a power outage happening while some process is writing to the SD card are very low.

    So far, this seems like a good compromise. As you recommended, I will schedule frequent backups, and deal with card corruption when it happens.

    Many thanks!

    This is driving me crazy!

    I can mount the "/storage/.kodi" from NFS, just by creating the proper file at "/storage/.config/system.d/". So far so good: the system boots, the NFS folder is mounted, KODI works, and everything seems OK.

    Now I stop KODI, unmount the NFS share, and delete the contents of "/storage/.kodi" (since that content is not visible when the NFS share is mounted, there is no point keeping those files there, right?). But when I do this, the system stops mounting the NFS share on boot, and KODI has lost all its configuration. So, it looks like when the "/storage/.kodi" folder is empty, then WIFI connection is established too late.

    Why? I have not been able to guess what part of the boot process, prior to starting KODI, needs any file inside that folder.

    Quote from chewitt

    This is the correct way to put /storage on NFS: Network Boot - NFS - OpenELEC

    Yes, that works fine... as long as you use a wired connection, but I need to do this over a wireless connection.

    I am still convinced that this can be done; after all, then whole root filesystem is mounted read-only from a file in the boot partition. Buy I need to modify the squashfs, and modify it again on every update. This is getting out of hand, it's far too much work. I will mount everything from the SD card, configure a script to rsync /storage to a remote server daily, and deal with corruption when it happens.

    Thanks everybody for your help!

    Some time later...

    I finally opted for the solution outlined in my previous post: "mount everything from the SD card, configure a script to rsync /storage to a remote server daily, and deal with corruption when it happens". Since then, the device has been switched on and off almost daily, no one has ever bothered to shut it down properly, and it is still running.

    My conclusion is that card corruption is an issue that must be taken into account, but not exaggerated; a good backup strategy is probably "good enough" in most cases. Thanks for your help.