Preventing the init to mess with my NFS root and network

Hello,
I'm currently netbooting Openwrt by passing some options on the kernel command line, without any initramfs (I recompiled openwrt to include the network devices drivers).

I launch a few scripts, then, I launch the init from openwrt. At this point, it seems the init mount some root partition on top of my nfs rootfs, and "do something" with the network that basically disconnect the box from the nfs server.

Where should I start, in order to avoid the init system to kill my nfs rootfs ? In particular, I suspect that mount_root: mounting /dev/root is a problem (a few seconds later, I get nfs: server 192.168.183.1 not responding, still trying).

The problem is similar to https://openwrt-devel.openwrt.narkive.com/t0lzr17H/nfs-root-during-development, but this is 8 years old so I expect some changes have been made.

Thanks,
Rémy

some info in this thread;
https://forum.openwrt.org/t/build-18-06-4-etc-config-network-missing-banana-pi-r2/45600/19
https://forum.openwrt.org/t/openwrt-boot-from-emmc-or-nfs/45194/

2 Likes

The kernel for your target is likely configured to ignore or “munge” boot-loader args.

Often editing the DTS to your needs and building a custom kernel and image is a robust approach.

Well the rootfs is correctly mounted by my kernel, but then when I launch the openwrt init, everything breaks, a few seconds later.

I'm already building my custom kernel and image, so, no problem from there. What would be the options to search for?

I'll look at these threads, and if I find something that works for me, i'll keep you updated.

Thanks !

what target+board is it? ( what do you select in make menuconfig? )

x86, generic. But, again, I have no problem with the netboot, or the rootfs, it's just when I launch the init script from my pre-init custom script, it starts mounting stuff on top of my rootfs, which I don't want.

The kernel image I build already has ip dhcp autoconfiguration, and I kind of want to avoid the init system to try to deal with the network while it's perfectly working before launching it (the same with the root fs).

I'd look into the various pre-init and init steps. In general, they are all shell scripts. They do call mount_root which, as I recall, is a C executable.

See https://openwrt.org/docs/techref/preinit_mount for some more details that might be helpful.

1 Like

Managed it, finally. For the records, this is what i've done:

  1. Prevent the "80_mount_root" hook to be called (I just preventend the boot_hook_add to be executed, in the /lib/preinit/80_mount_root file)

  2. Prevent the "preinit_ip()" function from being called, by just placing a return at the top of the function, in the /lib/preinit/10_indicate_preinit file.

  3. Provide a default /etc/config/network, otherwise a bridge is created on the first boot, on the interface I used to connect my NFS Server and client.

With these two steps, the NFS root fs is not lost, and I'm happy :slight_smile:

I wish I had access to "high-level" configuration options that would allow me to avoid editing the preinit files by hand (what happens if the package is updated?), but, well, it works.

1 Like

No, it wouldn't surprise me if NFS is still broken since it is not considered a supported configuration, so nobody is testing it. I vaguely recall two distinct problems preventing NFS root setup:

  1. netifd, upon starting, will reconfigure all network interfaces, briefly downing lan in the process and shifting the ip address 192.168.1.1 from the underlying ethX to br-lan or - in case no bridge is set up - clear all IP config anyway and apply it from scratch. This will break the established NFS connection

  2. mount_root might attempt to overmount / with something else which might or might not be a problem.

My personal guess would be netifd severing your NFS connection due to the interface reconfiguration.

1 Like

a pr that cases cmdine for nfs and handles the other breakpoints would be relatively simple... if I ever find my last docs / need this again... ( or someone starts a pr ) i'll post a patch here...

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.