Jacob Weinstock

Hi @glycerin-ce, any chance you would be able to post some logs or error messages you're seeing? Sorry, we definitely didn't architect this sandbox with proxies in mind.

Hey @umashankar1988, sorry for the delayed response. I've experienced this before and was able to resolve it by deleting the `ca.pem` file (this is in the `deploy/compose/state/webroot/workflow/` dir) and then...

Thank you for bringing this up. For me, the challenge with this would be that we'd need to do something similar for vagrant and the bare docker-compose paths as well...

Thinking about this some more. There is currently functionality that allows a user to provide a custom ipxe script. In this custom ipxe case, tink worker is never launched. So...

sorry for the dumb questions, i don't think i fully understand the value here. Is this just a different format to provide the ipxe script? what data would be encoded...

@displague thank you for the great explanations. I do believe I understand now. With https://github.com/tinkerbell/boots/pull/192, being merged, there is now a new field `metadata.instance.operatiing_system.InstallerData.Script` that can be used for `custom_ipxe`...

Hey @chechuironman, very sorry for the delayed response here. Which docker-compose are you running? The one in this repo uses the "standalone" backend/data model. Maybe you're using the [sandbox](https://github.com/tinkerbell/sandbox) repo?

> Sorry for the late response. But I think @nshalman and @mmlb need to look at this as well. > > The logic for some of the removed arguments won't...

> > Sorry for the late response. But I think @nshalman and @mmlb need to look at this as well. > > The logic for some of the removed arguments...

Hey @nicop311, thanks for reporting this. We've actually moved ipxe building to another repo. https://github.com/tinkerbell/ipxedust We need to clean up this bad link. The doc lives here: https://github.com/tinkerbell/ipxedust/blob/main/docs/IPXE.md