PXELINUX implementation doesn't respect dhcp ConfigFile or PathPrefix values

Added Jason Hobbs from Calxeda

While I agree this would be a useful feature, I don't believe it's required to achieve what you want to achieve. U-Boot's pxe already supports a way to point different client classes at different areas of the tftp server.

U-boot doesn't need to download 'pxelinux.0' from the tftp server like normal PXE implementations do, but it still respects the bootfile option in dhcp responses. When you run 'dhcp' in U-boot it will attempt to download whatever was supplied as the bootfile in the dhcp response, and will set the 'bootfile' env variable accordingly.

Following the same convention as pxelinux, U-Boot's 'pxe get' will look for config/image files at paths relative to the directory the 'bootfile' location was given as.

So, given this dhcp config, highbank clients will be pointed at /arm/highbank, and x86 PXE clients will be pointed at /x86/

class "pxe" {
    match if substring (option vendor-class-identifier, 0, 9) = "PXEClient";
}

class "uboot-highbank" {
    match if substring (option vendor-class-identifier, 0, 21) = "U-boot.armv7.highbank";
}

subnet 192.168.100.0 netmask 255.255.255.0 {
        server-name "192.168.100.1";
        option tftp-server-name "192.168.100.1";
        option subnet-mask 255.255.255.0;
        option broadcast-address 192.168.100.255;
        option domain-name-servers 8.8.4.4;
        option routers 192.168.100.254;

        pool {
                range 192.168.100.100 192.168.100.149;
                allow members of "uboot-highbank";
                filename "/arm/highbank/empty";
        }

        pool {
                range 192.168.100.150 192.168.100.199;
                allow members of "pxe";
                filename "/x86/pxelinux.0";
        }
}

The 'empty' file can be empty; as long as it exists, U-Boot will be happy with the tftp request.

Here's some example output from highbank doing PXE:
Highbank #dhcp
BOOTP broadcast 1
*** Unhandled DHCP Option in OFFER/ACK: 28
*** Unhandled DHCP Option in OFFER/ACK: 28
DHCP client bound to address 192.168.100.100
Using xgmac0 device
TFTP from server 192.168.100.1; our IP address is 192.168.100.100
Filename '/arm/highbank/empty'.
Load address: 0x700000
Loading: #
done
Highbank #pxe get
missing environment variable: pxeuuid
Retrieving file: /arm/highbank/pxelinux.cfg/01-52-54-00-12-34-56
Using xgmac0 device
TFTP from server 192.168.100.1; our IP address is 192.168.100.100
Filename '/arm/highbank/pxelinux.cfg/01-52-54-00-12-34-56'.
Load address: 0x700000
Loading: *
TFTP error: 'File not found' (1)
Not retrying...
Retrieving file: /arm/highbank/pxelinux.cfg/C0A86464

Jason, good input and I'd like to get the Dave Walker's consideration of it into this bug. Dave?

I've got code well under way and my cursory testing shows I can handle 208,9,10 fine. Working on 211 (RebootTime)

I have some changes I've made to implement RFC 5071 against u-boot-linaro that I will attach shortly. I want to get Linaro guys to take a look at this and maybe have a quick chat about it today.

Here's a patch for RFC 5071 support. I'd like to talk to Linaro guys about this.

The attachment "proposed RFC 5071 implementation" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

Out of curiosity, is there any standard or convention for the vendor-class-identifier which would let this approach work well out of the box? Sure, it seems one can make it work manually if one happens to have a useful vendor class identifies to work with, but there's nothing there that could be standardised and Just Work, especially with transitions like v8, HF etc.

Ideally, we'd want to be able to have PXE just work in our provisioning service, and hard-coding, or hand-coding, or hand-hard-coding specific mappins as per the example isn't a solution.

John, would you mind checking and reviewing the attached patch from Justin? Also check with Daviey if that's still an issue on their side. Thanks!

I did a quick review, I don't think adding this patch would break anything. The files need a proper u-boot style file header but that is easily fixed. Some of the ifdef's are a bit confusing to me but a better way to do it does not jump out at me. I can apply this to u-boot-linaro.

In the longer term it would be great if the Calxeda folks (Jason and Rob) could sign off on this and if Rob could send a patch upstream since he is the defacto u-boot pxe maintainer having sent the most recent fixed upstream.

Of course this is all based on if Justin and Dave still want this functionality in or are happy with the alternative method that Jason outlines in comment #2 above.

Ideally, the original author should submit things upstream as they are the one which can argue why they did what they did. To start, checkpatch.pl needs to be run.

I don't think the reboot time support would work as intended by the RFC. It is the "pxe boot" command that the timeout should apply to (i.e. running the pxelinux loader). There is already a tftptimeout env var that could get used here. What happens on timeout probably needs some work. A reboot time of 0 also needs to be handled.

The other 2 options look useful to me if these are normally set.

Rob

Rob is correct, the original author should do the upstream pushing. I am going to add it to u-boot-linaro and ping Justin about upstreaming.

Hope Robbie does not mind my inserting this from an email of his:

....

Summary

pxelinux emulation on ARM does not match the behaviour of pxelinux.0 on
Intel, even in areas that are not architecture-dependent. This means
that developers working and testing on Intel push stuff that they expect
to work, and it doesn't. This costs us considerable time dealing with
the impedence mismatches.

Things to Fix

Ideally, everything. Someone could do an audit of U-Boot's pxelinux
emulation as it appears in upstream trunk, compare it to pxelinux
documentation and construct a complete list of missing features and
behaviour.

Specific Things That We've Noticed

This is based on the U-Boot supplied to us by vendors, rather than
upstream trunk.

 * U-Boot does not understand "localboot", which is important for MAAS'
   current mode of operation.

 * U-Boot ignores DHCP options 208 through 211. LP: #927781, RFC5071.

 * U-Boot cannot parse a configuration in the following form that is
   valid in pxelinux, due to limited menu support:

 DEFAULT menu
 PROMPT 0
 MENU TITLE foo
 TIMEOUT 1
 ONTIMEOUT ubuntu-enlist

 LABEL ubuntu-enlist
  kernel bar
  MENU LABEL ubuntu-enlist
  append baz
  ipappend 2
 MENU end

Robie

On 08/03/2012 10:28 AM, John Rigby wrote:
> Hope Robbie does not mind my inserting this from an email of his:
>
>
> ....
>
> Summary
>
> pxelinux emulation on ARM does not match the behaviour of pxelinux.0 on
> Intel, even in areas that are not architecture-dependent. This means
> that developers working and testing on Intel push stuff that they expect
> to work, and it doesn't. This costs us considerable time dealing with
> the impedence mismatches.
>
> Things to Fix
>
> Ideally, everything. Someone could do an audit of U-Boot's pxelinux
> emulation as it appears in upstream trunk, compare it to pxelinux
> documentation and construct a complete list of missing features and
> behaviour.
>
> Specific Things That We've Noticed
>
> This is based on the U-Boot supplied to us by vendors, rather than
> upstream trunk.
>
> * U-Boot does not understand "localboot", which is important for MAAS'
> current mode of operation.

It does. localcmd has to be set in the environment.

>
> * U-Boot ignores DHCP options 208 through 211. LP: #927781, RFC5071.
>
> * U-Boot cannot parse a configuration in the following form that is
> valid in pxelinux, due to limited menu support:
>
> DEFAULT menu
> PROMPT 0
> MENU TITLE foo
> TIMEOUT 1
> ONTIMEOUT ubuntu-enlist
>
> LABEL ubuntu-enlist
> kernel bar
> MENU LABEL ubuntu-enlist
> append baz
> ipappend 2
> MENU end

What specifically is the failing part?

Rob

>
> Robie
>

Cleaned up version of patch in #6 above has been included in version 2012.05.6-ubuntu1