svc: /mnt/fw/ether0 needs an mntgen of its own

The service file said -m /mnt/fw/ether0 and nothing made that name.
mntgen invents names one level deep, so the one over /mnt gives /mnt/fw
and stops there:

	one mntgen over /mnt makes /mnt/fw                        yes
	but not /mnt/fw/ether0, which is where fw is told to mount no
	a second one over /mnt/fw does                            yes

So a second mntgen over /mnt/fw, as its own service, and every fw needs
it.  It is a file server like the rest -- posts its name, lets the
process that started it exit -- so ready=srv:mntfw, the same shape fw
uses.

fwstart already does this imperatively, which is why the boot path
worked and the supervised path would not have.  Four checks now pin the
premise both rest on, ending with fw actually mounting its control
files under the second mntgen.

The finding and the service file are Calvin's; the checks are mine.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

1 files changed, 19 insertions, 0 deletions

diff --git a/fw/lib/svc/mntfw b/fw/lib/svc/mntfw
new file mode 100644
index 0000000..62eb2e5
--- /dev/null
+++ b/fw/lib/svc/mntfw
@@ -0,0 +1,19 @@
+#
+# The control directories fw mounts on.
+#
+# mount(2) needs its mount point to exist, and the mntgen serving /mnt
+# only makes names one level deep -- /mnt/fw appears by itself, but
+# /mnt/fw/ether0 does not, and that is what fw is told to mount on.  So
+# a second mntgen, over /mnt/fw, and every fw needs it.
+#
+# It is a file server: it posts its name and the process that started it
+# exits, so what is watched is the /srv name.
+#
+svc=mntfw
+	exec=/bin/mntgen
+	args=-s
+	args=mntfw
+	args=/mnt/fw
+	ready=srv:mntfw
+	restart=always
+	enable=yes