Page MenuHomeFreeBSD

Make pxeboot use rootpath option in tftp mode
ClosedPublic

Authored by bapt on Dec 15 2015, 11:42 PM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Nov 20, 5:31 PM
Unknown Object (File)
Wed, Nov 13, 5:00 AM
Unknown Object (File)
Wed, Nov 13, 2:14 AM
Unknown Object (File)
Wed, Oct 30, 7:17 PM
Unknown Object (File)
Oct 5 2024, 9:12 PM
Unknown Object (File)
Sep 24 2024, 8:53 AM
Unknown Object (File)
Sep 24 2024, 4:35 AM
Unknown Object (File)
Sep 18 2024, 6:11 AM

Details

Summary

Instead on enforcing a hierarchy on the tftp server, use rootpath
to prefix all tftp open commands so the default /boot can be put at any level of
the hierarchy or the tftp server.

While here drop the specific pxeboot.4th default rc file requirements as the
vanilla content of /boot can now be used

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 1686
Build 1692: arc lint + arc unit

Event Timeline

bapt retitled this revision from to Make pxeboot use rootpath option in tftp mode.
bapt updated this object.
bapt edited the test plan for this revision. (Show Details)

pxe http is not for this review yet :)

Can you explain a bit more of the before and after effect? In particular, I'm not sure what the old pxe_default_rc() was doing. (This is probably ps@ code)

In D4590#96780, @jhb wrote:

Can you explain a bit more of the before and after effect? In particular, I'm not sure what the old pxe_default_rc() was doing. (This is probably ps@ code)

Before that change:
when booting pxeboot was looking for a pxeboot.4th (pxe_default_rc) file at the same location as the pxeboot itself on the tftp server (file which is not provided in our sources). if that file was containing any "include /boot/something" then it was looked up at the root of the tftpboot server, meaning we could not use the regular files we do have in /boot.

Now when pxeboot start it is looking for the regular /boot/boot.4th and /or loader.rc, it respects the root-path provided via the dhcp server, meaning that tftp loader works exactly the same as nfs loader so one can just drop the content of the /boot anywhere on the tftp server everything will just work.

if root-path is provided it is prepended (like for nfs loader) to any open fonction meaning "include /boot/something" will actually make a get /rootpath/boot/something on the tftp server.

If no root-path is provided then it will look for /boot/something at the root of the tftp server like before. The only behaviour change is instead of looking for a pxeboot.4th like it did before it will now look for the same files as the other loaders.

I hope this clarifies a bit more what this patch does

rpokala added inline comments.
lib/libstand/tftp.c
429

If rootpath ends with a '/', tftpfile->path will have a "//" in it; is that okay?

sys/boot/i386/loader/main.c
204

It would be nice if you could continue to use pxeboot.4th, for those who have it.

lib/libstand/tftp.c
115

MAXPATHLEN is a posix concept. And it's a constant for the 'host' we're building on, not the remote TFTP server. The RFC doesn't seem to list a maximum length...

lib/libstand/tftp.c
429

yes it is ok

sys/boot/i386/loader/main.c
204

Well I can add a pxeboot.4th concept, which if it fails, falls back on a normal boot process, but the behaviour would be a bit different than before because pxeboot.4th would be looked up in root-path instead of "path" of the pxeboot file.

ngie added inline comments.
lib/libstand/tftp.c
48–51

Please replace sys/types.h with sys/param.h per style(9)

lib/libstand/tftp.c
115

Ok dropped

432

Now it is a bit cleaner as I only add a / if rootpath does not end with a / or path does not start with a /

sys/boot/i386/loader/main.c
204

adding pxeboot.4th compat is more complicated that it looks like, as for now pxeboot.4th completly bypass all other includes done in the loader. (aka prevents others to load)

lib/libstand/tftp.c
48–51

I have removed the need of sys/param.h

rpokala added a reviewer: rpokala.

Looks okay to me.

This revision is now accepted and ready to land.Dec 16 2015, 4:01 PM
This revision was automatically updated to reflect the committed changes.