Hi Ritesh and Benjamin,
I have read the context in [1]. It seems your tool has already used new
mount api to mount the hostfs. It now rejects unknown mount options as
many other filesystems do regardless of its earlier behavior (which
treats any option as the root directory in hostfs).
This should be clarified for unknown option. For older hostfs (before
new mount api), it treats the whole string behind -o as the root
directory. This will allow any mount options, but also limit its
extension. It is not the same as other mainline filesystems which will
split the option string with ','. So for these filesystems, they can
consider whether reject unknown mount options or not.
I'm not sure it is reasonable in this way. If we accept unknown option
in the hostfs, it will be treated as root directory. But which one
should be used (like mount -t hostfs -o unknown,/root/directory none
/mnt). So in the conversion, we introduce the `hostfs` key to mark the
root directory. May be we need more discussion about use case.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1086194
Thanks,
Hongbo
On 2024/11/7 3:25, Benjamin Berg wrote:
Hi,
I am probably not the right person to talk to. Maybe Hongbo Li can say
more?
That said, it looks like the filesystem now has the "hostfs" option. So
you can probably just use
mount -t hostfs -o hostfs=/path none /mount/point
which is nicer anyway. Just a bit annoying as you probably need to pass
it differently for older kernels.
Benjamin
On Wed, 2024-11-06 at 17:22 +0530, Ritesh Raj Sarraf wrote:
Hello Benjamin,
On Thu, 2024-10-31 at 11:07 +0100, Benjamin Berg wrote:
Hi,
Newer kernels have become more picky about that with the new mount
API.
This is relevant, see the discussion about "Unknown options":
https://lwn.net/Articles/979166/
We only use hostfs for the root file system and in that case it
works
well if you pass the path using "hostfs=/path" on the kernel
command
line. Doing that avoids issues when remounting the file system
later
on.
As upstream developers for UML, what would you conclude it as ?
We've recommended using hostfs for the UML kernel modules as well.
What
would be the alternate approach to ensuring a proper boot for a
modular
UML kernel ?
I suppose that currently it does not work to mount hostfs later on.
No
idea what the right fix is. Maybe the host directory should be an
explicit option like "hostpath=..." or so to make it compatible
with
the new mount APIs.
The ability to mount any hostfs mount point was/is a feature provided
by UML. We've used it and integrated with many tools like debos,
fakemachine etc; the Debian bug report has the details.
There'll be more reports following once UML 6.11 hits Debian Testing.
I hadn't expected a working feature to break with a newer Linux
release. :-(
Thanks,
Ritesh
