[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#41820] [PATCH] file-systems: Add record type <nfs-share> for a file
[bug#41820] [PATCH] file-systems: Add record type <nfs-share> for a file system device.
Tue, 21 Jul 2020 16:33:02 +0200
just a heads-up, I've forwarded this to Brice Waegeneire, who I think is best
qualified to review and merge your work. He is working on PXE booting,
starting with regular x86_64 machines. So NFS root is totally something he
both needs and can help with.
Myself, I'm quite satisfied with your version, I'd just like there to be some
minimal tests of the functionality and that's pretty much it.
About the <nfs-share> record, if you think it's better without the record, we
can also do without--but I'd like to know Brice's opinion on it.
The idea was to have the record be something like
if we could have used it. We can't use "nfsroot=" directly because we don't
have network drivers built into the kernel and instead use modules for those.
That also means that the initrd modules have to be automatically extended
by network card drivers, I guess.
So the initrd would basically emulate the fields of "nfsroot=" from the link
So it would be <nfs-root> and would have fields like
nfs-options (a list)
You're right that having a <nfs-share> with just the host and directory does
not make much sense as a record. But we actually need to configure the
machine as a client in the network to be able to reach the nfs server,
I guess we could ignore the problem and have the DHCP server do
it, and I'm all for it--but some use cases might need manual configuration,
too. Even then, is it possible to know which NFS protocol version to use
for the NFS root automatically? Even in your case, you don't actually
get the nfs IP from the DHCP server either, but you make the user pass it
by splicing it to some string, right?
So some kind of <nfs-root-client> or whatever record is necessary, I'd say.
Description: OpenPGP digital signature