Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
mkinitfs: terrible hack to mount rootfs over NFS (WIP) #547
Very hacky proof of concept for #511: this mounts /boot and / on Nexus 6P (angler) over NFS over USB.
Do not merge this.
I'm serving NFS using my host system (Ubuntu 14.04)'s nfs-kernel-server, and I've rebuilt my device's kernel to add NFS support. The scripts I used on the host system to start NFS is here.
The way it's currently implemented prevents mounting the root FS normally. What would be a good way to integrate this into the normal initfs? Also, can we serve NFS from inside the Alpine chroot or do we need to serve NFS from the host system?
I would check the kernel parameters, like we do for disabling the log redirection already.
It would be in the spirit of the current pmbootstrap code, to automatize everything as much as possible and therefore to set it all up from inside the Alpine chroot with pmbootstrap. From a user's point of view, I would like to have it as simple as possible. One example I can think of right now:
During the installation, we already mount the device chroot in the native chroot, so you will probably also need to do that, in order to have the nfs server running inside the native chroot.
Please note that I did not make a code review yet, please tell me when you think it is ready to be reviewed or if you would like to have one right now anyway.
Thank you for working on this, I'm really looking forward to this feature. With this, we could really develop postmarketOS on devices without changing them at all, even if they do not have an sdcard slot!
I think we need to modify the DHCP server on the phone so it only gives out a single IP address to the host machine (like 172.16.42.2) and then start the NFS kernel server and bind it to that IP address.
I think we could implement it neater in the initfs by checking a kernel parameter for nfs booting. like passing pmos.nfsboot=true to the kernel cmdline.
@MartijnBraam This PR does limit the DHCP IP to a single address; in an actual implementation one would switch the range based on whether NFS is enabled on the kernel command line.
@ollieparanoid For NFS in a Chroot, one needs:
The first can be done using similar code to the losetup code we already have. The second I'm a bit iffy about, since distccd only uses one process, while this one needs two. We would probably detect the host nfsd somehow and tell the user to disable it.
Also, should we NFS mount the image directly, or do we need to make a copy of the system root partition prior to mounting?
Finally, this does require NFS client to be enabled in the device's kernel. Should we use a different protocol instead (e.g. a FUSE-based FS) so that we don't have to change the kernel config?
The generated system image is just the device chroot copied into an image file. Unless we get performance problems, I would prefer to directly use the device chroot if possible.
That way we would not have any size limitations (the system image is just as big as the chroot and gets resized when copied to the device, see the qemu wiki article on how to resize it) and the test cycle would be much faster:
This would be all, that is necessary to install a program - no need to rebuild the whole image and loose all changes you may have made. (And if you want to rebuild it, simply
With that being said, I think a blockdevice is probably faster, which would speak for
How about implementing the
@ollieparanoid I would appreciate some guidance on getting this to a working state. I originally tested this by manually exporting the NFS directories from my host operating system. I would like to automate that, but I have a few questions.
My ideal user interface for this would be an extra
Is it possible to even run an NFS server in a chroot? (I can get the server daemon to start, but I have not tested actually exporting any filesystems).
What if the user already has an NFS server running outside the chroot? I don't think one cannot run two NFS servers at the same time, since a special
NFS is not one daemon but several (rpcbind, rpc.nfsd, and (for NFSv3) rpc.mountd). How would we check all their statuses/shut them all down at once?
Should we use NFSv3 (the most common protocol), NFSv4 (newest version), or use something other than NFS, such as NBD?
NFS is kinda ugly to deal with in a chroot, I think you might need a seperate network namespace to run nfs on the host and a chroot at the same time (and thus making the chroot dangerously close to a container). It might be neater to do the nfs server on the host (since you need the stuff on the host anyway to make it work in the chroot so this doesn't really add another dependency)
@MartijnBraam Most Linux distros install the NFS kernel module by default but not the actual NFS server, so pmbootstrap would have to install that through the host's package manager. That might be annoying to setup for multiple distros.
As for NFS conflicts: can I just assume that no-one is serving NFS from the host system? It's not exactly a commonly run service...
Yes, I think that would make it easy to use and
I couldn't find a source that says: Yes it is possible, so we need to try that out. But I am confident that it is possible one way or the other. What I found:
I think we can assume that the host system doesn't run NFS. With that being said, it should be possible to run the user-mode implementation side by side with the host system daemon.
When introducing the NFS daemon(s), I think it makes sense to refactor some functions from that file and make them usable for daemons in the chroot in general (
(NOTE: We also have the
From reading up on this, NFSv4 seems to be simpler, and it is around for quite a long time now, so we should be fine with NFSv4 only (for the official server, when using the alternative server linked above we should get additional NVSv3 without extra effort as I understand).
I prefer NFS over NDB, because with NFS we could implement something like:
and you could seamlessly access the chroot and make changes from your PC with:
In contrary with NDB we would need to generate the image file and resize it appropriately, which takes up more space and more time (to copy everything to the image). And to access the image, you would have to mount it, and there's no easy way to chroot into it with