Alright, progress. I got it to go to shell and give me the following error when trying to access the kernel:
[url]http://ipxe.org/err/410c61[/url]
Which means its a 403, or forbidden. Apparently I didn’t get the permissions correct. I will have to give it another run. What permissions would you suggest for this?
FOG 1.1.0 SVN 1800
Debian 7.5
And as per the prompt, I can believe I did something wrong, but what is the correct placement?
menu
item --gap – ---------------- iPXE boot menu ----------------
item SEATOOLS Seatools for DOS
item TRK Trinity Rescue Kit
item hostinfo Computer Details
item shell ipxe shell
item return return to previous menu
choose --default return --timeout 5000 target && goto ${target}
:SEATOOLS
initrd ${boot-url}/service/ipxe/seatoolsdos223all.iso
chain ${boot-url}/service/ipxe/memdisk iso raw ||
goto MENU
:TRK
kernel ${boot-url}/service/ipxe/trk/kernel.trk ramdisk_size=99700 root=/dev/ram0 vga=788 trknfs=192.168.10.86:/trk ip=::::::dhcp splash=verbose pci=conf1 trkmenu
initrd ${boot-url}/service/ipxe/trk/initrd.trk
boot ||
goto MENU
:hostinfo
echo This computer : ||
echo MAC address…${net0/mac} ||
echo IP address…${ip} ||
echo Netmask…${netmask} ||
echo Serial…${serial} ||
echo Asset number…${asset} ||
echo Manufacturer…${manufacturer} ||
echo Product…${product} ||
echo BIOS platform…${platform} ||
echo ||
echo press any key to return to Menu ||
prompt
goto MENU
:shell
shell ||
goto MENU
:return
chain http://${fog-ip}/${fog-webroot}/service/ipxe/boot.php?mac=${net0/mac} ||
prompt
goto MENU
autoboot[/CODE]
Sadly still the same result. I have tried putting some options in for it to fail out to a shell, but iPXE never goes to the shell. If for some reason iPXE could not see the kernel or initrd, would it just crash out to the previous menu?
Sadly no change. Let’s widen the scope then. I created the folder ‘trk’ and stuck the entire contents of the disk in there, just like I had done before. I then made sure the owner and permissions matched the rest of the folders and files that were already present in ‘ipxe’. I also then started an NFS mount for ‘/trk’. Did I miss anything there?
I have been working on adding back in some tools I had available in Fog 0.32, and have been slowed down by the iPXE menu structure. I have figured a couple of images out, but those were plain ISOs I was loading, so it wasn’t that hard.
But now I have been trying to load the Trinity Rescue Kit (TRK). Sure, I could dump the whole ISO in the RAM, but that is far from ideal due to its size, and requires some fussing with just to get that to work due to how it loads. Before, I had it loading by pointing the PXE menu to its initrd and kernel, and passing some arguments. I have done my best to convert the entry to iPXE, but apparently I am doing it quite wrong since it dumps me back to the default Fog menu the moment I try to boot TRK.
Here is my current entry for TRK:
[CODE]:TRK
kernel ${boot-url}/service/ipxe/trk/kernel.trk
initrd ${boot-url}/service/ipxe/trk/initrd.trk
imgargs ramdisk_size=99700 root=/dev/ram0 vga=788 trknfs=192.168.10.86:/trk ip=::::::dhcp splash=verbose pci=conf1 trkmenu ||
goto MENU[/CODE]
Excellent. I was on a stable rev previously, but so far this one has been performing even more smoothly and responding quicker. Great work.
Out of curiosity which svn rev number is considered Release?
This is great. Thanks for reporting your results.
I’ve fought and fought with UEFI, and until there is full support for it, I’m just going back to Legacy, and I would suggest you do as well. It is much easier to adapt the OS to use legacy boot than it is to support UEFI on a network boot, let alone if you have a mixed environment.
That’s cleaner than what I had done, so I will take a gander at that later this week. Thanks for the info.
Or you could try Debian if you feel attached to a Ubuntu like ecosystem. Ubuntu’s core is Debian, and the freshest latest release of Debian works flawlessly with Fog.
…oh. Well then. I guess I’ll have to manually register each host unless that feature can be put back in. Oh well, this will still be useful for machines that will be using their own OS install until we finalize our Unified System Image.
What? I could have sworn a host that I manually installed the service on registered its self. I mean, its a Windows 8.1 machine with SecureBoot UEFI, so idk how else it would have registered…
I would suggest you cleanly scrub out your current FOG install and all packages that are then no longer needed, then start again.
And honestly I would suggest using about any other Linux distro other than Ubuntu 14.04.
Alright, I think I’ve made headway on this. I have the service installing and the .ini file being replaced as needed. The service doesn’t appear to be registering unknown hosts though. As soon as I see things work I’ll document my process.
What BIOS rev are your optiplexs on and what kernel do you happen to be using? And I assume you have the secure boot and all forms of UEFI disabled?
I agree with Junkhacker. I am nearing a massive registration project, and group specification would be… nice.
That’s a nope. Nope nope nope. The install failed to process properly on the workstation and I had to clean up after the failed install. The .ini file copy worked fine, but running the MSI via GPO did not go well. Turns out it wasn’t my MST that fried the previous install.