Hi @alzer89 - It is great to see this project coming to life in code! Awesome stuff.
Life has been hitting especially hard in these times but I did read through your latest postings and code.
I personally don’t know Salt or PXE config stuff so I might not be much help. I looked into Salt a few years back but gave up and returned to traditional scripting. I also haven’t done a PXE boot for over a decade so I will have to get up to speed on setting the client side of that up, now that I am on Coreboot ROMs (iPXE and Netboot.xyz seem relevant).
I saw your specific problem about qube cloning not working and thought it was odd that simple task wouldn’t be working but all your other salt code would be…
- Clone it into sys-pxe-template (this is the bit I’m having trouble with)
I would presume that the following is where you try to execute the cloning (and commented it out due to it not working yet)?..
sys-pxe-template.sls
dom0:
cmd.run:
- qvm-clone fedora-36-minimal sys-pxe-template
I experimented with the standard qvm-clone
command, outside of Salt, in my Dom0 terminal and here is what I found:
qvm-clone <existing-qube-name> <new-qube-name>
generates the following output in the terminal as it runs normally:
<new-qube-name>: Cloning private volume
<new-qube-name>: Cloning root volume
But I then checked what type of output this was by routing all STDERR output to /dev/null
.
qvm-clone <existing-qube-name> <new-qube-name> 2>/dev/null
And then there was no output in the terminal as it runs.
This tells me that qvm-clone
is generating STDERR errors to use as normal general user output (maybe as a convenient way to hide this output from other Qubes scripts that make use of the qvm- commands).
However, maybe, just maybe, Salt has a problem with processing this STDERR output of qvm-clone and maybe interprets it as an error/failure in processing the qvm-clone command?
As a potential fix:
The qvm-clone command has an optional “--quiet
” flag that seems to suppress this STDERR output.
The terminal command would be:
qvm-clone --quiet <existing-qube-name> <new-qube-name>
which you probably know how to adapt and try as a salt command.
Really hope that helps, as it otherwise seems strange such a simple command would not be working.
I’ve heard others complain about how Salt can be opaque with indicating the underlying source of errors.
I am really hoping that I can somehow use your Qubes PXE system to be usable with a current RAM-based version of Qubes, as I am successfully using @xuy’s Qubes in tmpfs, but to be able to network boot a RAM-based Qubes would be the ULTIMATE for my desired setup. I have many identical machines that I would love to simultaneously network boot a RAM-based Qubes from for testing and production uses.