distinguish NFS versus TFTP boot by rootpath

[kczekirda]

Summary

Don't use DHCP 150 option to decide which protocol use to netboot. When root-path includes ip address - go thru NFS, if ip address not exists in root-path - go thru TFTP from server which ip address is in next-server.
But there is one limitation - only one tftp server in network to provide loader and everything else.
Does enybody use more than only one?

Sponsored by: Oktawave
Relnote: Yes

[rgrimes]

I am happy with this, it moves us forward, and removes the option 150 hack. I am pretty sure that you can actually dole out more than 1 tftp server by careful use of dhcp server configurations, ie the dhcp server has full control over what next-server you are told to load from if your environment is large enough that you need more than one.

[bapt]

Yes simple and efficient I like this I wonder why I took a very complicated path in the first place.

Give me some time to test it on our production server. I don't think we need to keep compatibility with option 150 given as far as I know only I and @sbruno used it and both of us can move along :)

I'll commit it after have tested it.

[bapt]

Committed as rS317886

[bapt]

We need to find a better mechanism, as this break usage where rootpath /something was before this patch expecting NFS to be located on the same serveur as the tftp server. This is now broken (it is used quite a lot apparently)

[tsoome]

In D10603#223301, @bapt wrote:

We need to find a better mechanism, as this break usage where rootpath /something was before this patch expecting NFS to be located on the same serveur as the tftp server. This is now broken (it is used quite a lot apparently)

Which means we are back at the beginning; we can not use the initial pxe ack, we need to build the request asking for both tftp and nfs, and select the method based on response.

[kczekirda]

In D10603#223305, @tsoome wrote:

In D10603#223301, @bapt wrote:

We need to find a better mechanism, as this break usage where rootpath /something was before this patch expecting NFS to be located on the same serveur as the tftp server. This is now broken (it is used quite a lot apparently)

Which means we are back at the beginning; we can not use the initial pxe ack, we need to build the request asking for both tftp and nfs, and select the method based on response.

It's sad that we have to implement PXE client properly, because vendors can't.

[bapt]

so ipxe will catch and use: iscsi:/ tftp:/ nfs:/ http:/ https:/ etc, maybe we should use tftpfs:/

In this case pxe will give a message saying (ignore unsupported root path) and continue what do you think?

[tsoome]

In D10603#223317, @bapt wrote:

so ipxe will catch and use: iscsi:/ tftp:/ nfs:/ http:/ https:/ etc, maybe we should use tftpfs:/

In this case pxe will give a message saying (ignore unsupported root path) and continue what do you think?

you mean in root_path? as of, if the path is starting with /, default to nfs? thats one possible way indeed. I quite like the prefix notation listed above - I do not think we would need to use tftpfs: there, just tftp: is enough.

[bapt]

What I mean is we cannot use the one I listed above because they are interpreted by ipxe. For example if one netboots from qemu it will use ipxe under the hood first, then if you pass rootpath tftp:/ ipxe will say

Next server: 192.168.42.1
Filename: /pxeboot
Root path: tftp:/
Could not open SAN device: Invalid argument (http://ipxe.org/1c126002)
No more network devices

and the boot process fails.

Which is why what I propose is tftpfs:/ because it is not used by ipxe
and by default we remain on over nfs so we don't break existing usage

[tsoome]

In D10603#223350, @bapt wrote:

What I mean is we cannot use the one I listed above because they are interpreted by ipxe. For example if one netboots from qemu it will use ipxe under the hood first, then if you pass rootpath tftp:/ ipxe will say

Next server: 192.168.42.1
Filename: /pxeboot
Root path: tftp:/
Could not open SAN device: Invalid argument (http://ipxe.org/1c126002)
No more network devices

and the boot process fails.

Which is why what I propose is tftpfs:/ because it is not used by ipxe
and by default we remain on over nfs so we don't break existing usage

So that sucks even more actually... it means I can not implement http: in loader with ipxe... I do not know. it really feels like just drop the whole idea about avoiding that extra request, build properly specified request, issue it and interpret the data received. just as it is supposed to be done.

[kczekirda]

tftpfs it's not bad, but you don't know what ipxe will do in the next commit. The problem is that we want to think about all.

[bapt]

The other option would be to use nfs:/ http:/ etc and tell the user they should configure their dhcp server to only send the rootpath if the loader is not ipxe, that may work, but not allow ipxe server would allow to do that (checking userclass iPXE)

[avg]

My opinion is that pxeboot is in the same league as ipxe. Of course, pxeboot is more specialized, but it is still a chain-loaded PXE boot client.
I see two possibilities of providing FreeBSD specific boot information.
Either we provide it via FreeBSD vendor extensions, so that we do not interfere with any earlier PXE boot programs (like ipxe or any other pxe loader in a NIC).
Or a DHCP / PXE server should be configured to distinguish pxeboot by its telltale signs and give out a different set of PXE options.
In my environment I implement the second approach.

[bapt]

https://lists.freebsd.org/pipermail/freebsd-hackers/2017-May/051053.html

[kczekirda]

https://reviews.freebsd.org/D10854