While the NBDROOT environment variable would allow for some flexibility, it still wouldn't allow LTSP to use the nbd-client.initrd script, as some LTSP users need to use the nbd-proxy hack.
Also, LTSP would need to initialize networking before nbd-client.initrd, to get the necessary info from DHCP, so I think that providing a way to launch an NBDCLIENT wrapper would be more flexible than the NBDROOT env var.
Furthermore, I believe it's best to have a common syntax for NBD, and the host:port/path syntax that NFS uses (http://www.rfc-editor.org/rfc/rfc2224.txt) is a good candidate.
I'm attaching a proposed nbd-client.initrd script that should handled all the use cases I've heard, while still being rather simple and while maintaining the commas-based syntax. I also did some minor optimizations, like replacing sed with case etc.
Wouter, could you please consider it for inclusion? Thanks!
While the NBDROOT environment variable would allow for some flexibility, it still wouldn't allow LTSP to use the nbd-client.initrd script, as some LTSP users need to use the nbd-proxy hack. www.rfc- editor. org/rfc/ rfc2224. txt) is a good candidate.
Also, LTSP would need to initialize networking before nbd-client.initrd, to get the necessary info from DHCP, so I think that providing a way to launch an NBDCLIENT wrapper would be more flexible than the NBDROOT env var.
Furthermore, I believe it's best to have a common syntax for NBD, and the host:port/path syntax that NFS uses (http://
I'm attaching a proposed nbd-client.initrd script that should handled all the use cases I've heard, while still being rather simple and while maintaining the commas-based syntax. I also did some minor optimizations, like replacing sed with case etc.
Wouter, could you please consider it for inclusion? Thanks!