If this belongs in Buildroot instead of Busybox, apologies. I'm not sure if this configuration is automatic from busybox or from buildroot. I'm running a system that uses an NFS root filesystem from a kernel autoconfig. The kernel autoconfig however does not retrieve options for DNS however, which is why I'm using udhcpc to fetch them. The file in question appears on my buildroot in this location: /usr/share/udhcpc/default.script When udhcpc runs, this script deconfigures the interface before getting a lease. When this happens, the NFS root becomes unreachable (so the system is basically gone), and even when udhcpc gets the lease successfully, all of its support scripts are no longer available and the system becomes unusable. By commenting out the "deconfigure" line, my udhcpc works correctly. It looks like there is a patch for this issue written for another project: http://dev.openaos.org/browser/trunk/openembedded/build/openaos/recipes/busybox/busybox-1.13.2/udhcpc-fix-nfsroot.patch
(In reply to comment #0) > If this belongs in Buildroot instead of Busybox, apologies. I'm not sure if > this configuration is automatic from busybox or from buildroot. > > I'm running a system that uses an NFS root filesystem from a kernel autoconfig. > The kernel autoconfig however does not retrieve options for DNS however, which > is why I'm using udhcpc to fetch them. > > The file in question appears on my buildroot in this location: > /usr/share/udhcpc/default.script > > When udhcpc runs, this script deconfigures the interface before getting a > lease. When this happens, the NFS root becomes unreachable (so the system is > basically gone), and even when udhcpc gets the lease successfully, all of its > support scripts are no longer available and the system becomes unusable. > > By commenting out the "deconfigure" line, my udhcpc works correctly. > > It looks like there is a patch for this issue written for another project: > http://dev.openaos.org/browser/trunk/openembedded/build/openaos/recipes/busybox/busybox-1.13.2/udhcpc-fix-nfsroot.patch What do you propose?
Created attachment 4130 [details] This is a diff between the patched and unpatched versions of the udhcpc.script file
> > What do you propose? > I found out the particular script that performs the mounts is actually in buildroot. I'll move the bug to that project if I can. I attached a diff that I generated. The file in question is package/busybox/udhcpc.script. The script in question is based on the scripts included with busybox, from my observations. We should modify those example scripts to also play nice with NFS so that anyone who copies them verbatim for their projects won't get burned from this. Also, to comment on the route_add_pipe variable in my diff: since we skip deleting the routes (in case NFS server is not on the subnet), it's very likely the lease we get also has the same routes. Adding the routes when they already exist results in an error, so I suppress the error if it's likely to happen. Aaron Opfer
Peter, what should we do about this one?
Peter, all, What to do with this patch? In commit 8432d81a849efca1d95ab0bd1324afd96bbdd804, changing buildroot's udhcp.script file, Peter wrote: http://git.buildroot.org/buildroot/commit/?id=8432d81a849efca1d95ab0bd1324afd96bbdd804 "Systems might have multiple network devices, and perhaps run udhcpc on another interface even when booted over nfs, so don't disable the per-interface deconfig based on the global nfsroot= setting on the kernel command line. If you don't want udhcpc to mess with kernel level IP autoconfiguration (E.G. for nfs boot), you should instead ensure udhcpc/ifup/ifplugd isn't started for that interface." In that commit, an existing check for NFS boot was removed. This bug basically requests such a check to be added again, but as mentioned in the above commit message may not be desirable in all cases. According to me, we should close this bug in 2014.05 (it has been open for more than 2 years). 1. Either we stand with the commit mentioned above, and do not try to be too smart. The user that does use NFS can use a rootfs-overlay or other mechanisms to provide a custom configuration. We may want to describe this situation in the manual to help unaware users. 2. Or we adapt the script based on the request in this bug, and let those NFS users that do not use udhcpc on the NFS interface (but on others) use a rootfs overlay. One could argue that the simplest case (one network interface with NFS + dhcp) is more common than the other ones, so alternative 2 is preferred to help most users. Those developers that have a more complex setup, hopefully understand the behavior of the system better to be able to tweak the script. Another alternative is: 3. We add a config switch in the script that does one thing or the other, the user can set this switch before the script is run, defaulting to one or the other. Input more than welcome, Thanks, Thomas
Fixed by http://git.buildroot.net/buildroot/commit/?h=next&id=71c75a5ea0e62786d279ef1609f23732bde5acc3. Will be part of 2016.02.