-
Notifications
You must be signed in to change notification settings - Fork 80
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make use of params command optional for phone-home #78
Comments
I encountered the same issue when trying to use @geekgonecrazy I know from Slack that you are doing something a bit different here because your cloud provider (ovh) does not give you full control. But technically the phone-home is a feature that Tinkerbell provides. You should set this param in your ipxe script:
And this is a kernel param |
I can see some potential use cases for the phone home in general. I tried using "params" even from the shell and the command is for sure not present in the version compiled and on this server. According to this: https://ipxe.org/cmd/params the ipxe had to be compiled with PARAM_CMD option defined. I had some issues with tftp as well I think that you might be referring to. No clue if related to this or not. But in this case it loaded the ipxe script fine but then errored out when trying to run params command. Soon as I took that section out and changed the code to:
It worked fine |
I think you can avoid Anyway, I think in 2 months we will have a very different I am going in an unexplored land here, but technically you can change osie with something like your own |
I think maybe misunderstood my problem. All of the other ${} substitutions and variables work just like intended. The values come from boots when it loads auto.ipxe from boots like normal. By params command I mean the literal ipxe params command used here on this line: https://github.com/tinkerbell/boots/blob/master/ipxe/script.go#L34 All other ${} substitutions and variables work fine. It’s simply that block: https://github.com/tinkerbell/boots/blob/master/ipxe/script.go#L34-L36 If the version of ipxe running doesn’t have that option compiled in you cannot define a params block and pass them auto-magically using ##params Changing: https://github.com/tinkerbell/boots/blob/master/ipxe/script.go#L34-L38 To:
Was literally the only change I made. The rest of the ipxe script executes and all variables are populated from boots |
This better explains the full setup and patch: https://geekgonecrazy.com/2020/09/07/tinkerbell-or-ipxe-boot-on-ovh/ |
Hey @geekgonecrazy in Packet we always boot our own version of ipxe exactly to avoid this situation (iPXE built without some things we need). I think removing the params would be fine in general, but is just a symptom of a bigger issue. Can you chain your own ipxe binary? That would be the most compatible and future-proof solution. |
@geekgonecrazy you can do this like |
@mmlb ah interesting idea.. Downside is.. would have to some how make it only check net1 and not net0. At least in my case. Since their server always replies on net0 with my script (or theirs if I don't have one set in their api). So would have to some how make the chained ipxe version only check net1.. or.. the script some how be able to detect its in my version of ipxe and chain to boots instead of ipxe. Something like:
|
actually I think this will work.. if only I can ever get ipxe.efi to boot. It just hangs there indefinitely. Just for the heck of it tried the others too. Those error out with "Exec format error" |
@geekgonecrazy glad that works. We do have a patched version number which you can use to branch off of too. Its used to detect iPXEs burned into nics and our own iPXE. Its used in boot's dhcp handling code, but I'm not sure if ipxe sends the version info when fetching ipxe script though. |
well it works as far as the logic works. But the actual booting from the ipxe versions shipped does not. I left for many hours and it just hangs there. So we might need to fork off into another issue for this specifically. But, none of the ipxe methods work from here. Not sure if any way to debug, but stays on: |
Tried out the various ones from https://boot.ipxe.org https://boot.ipxe.org/snponly.efi - this one finally worked. So would need to add that one, and determine what criteria is used to offer that one up to boot from what i'm reading of snponly.efi it only tries to boot the specific nic that is being chained. - https://ipxe.org/appnote/buildtargets Which would also be big win here. according to lshw the nic is: Just not sure if need metadata on hardware json to add this target and have it selected.. or if a way to automatically detect/select it. maybe like a https://theforeman.org/2019/06/install-esxi-through-foreman-using-ipxe-bootstrapping.html alternatively here looks like an example of a typical dhcp config returning if architecture == 00:07 looks like not looking at that in boots at all.. so might be easier to add an option on the hardware json definition. |
I think its time to fork off into a different issue. snponly looks like something we'd want all the time anyway to be honest. |
Also looking at the foreman config those would map to https://github.com/tinkerbell/boots/blob/master/dhcp/pxe.go#L23-L26 iirc. I don't know what the |
DDG points me https://github.com/jljusten/tianocore/wiki/EBC-FAQ and similar, so it must be true. |
This is needed because SNP is the only ipxe build that will run on x64 EFI. Specifically most of the BestValue / Infra-3 etc at OVH only work with SNP. More details can be found in tinkerbell#78 and tinkerbell#79 Signed-off-by: Aaron Ogle <aaron@geekgonecrazy.com>
I believe with |
Working through getting my physical servers working with tinkerbell to start doing some experimentation.. they fail saying the “params” command is not found.
Leased from datacenter so flashing or updating ipxe might not be possible or ideal.
Expected Behaviour
Boots
Current Behaviour
Errors out at params not found
Possible Solution
Maybe hardware option? Or use query string
Steps to Reproduce (for bugs)
Context
My solution was just to remove the params here:
https://github.com/tinkerbell/boots/blob/master/ipxe/script.go#L34
Then just let it phone home even with out params. Seems like using ?body=${body}&type=${body} might could work. I’m also not even sure if needed? Looking at the phone home code seems like it’s mostly ignored?
Your Environment
Operating System and version (e.g. Linux, Windows, MacOS):
How are you running Tinkerbell? Using Vagrant & VirtualBox, Vagrant & Libvirt, on Packet using Terraform, or give details: tinkerbell it’s self kvm on the network
Link to your project or a code example to reproduce issue:
The text was updated successfully, but these errors were encountered: