@george1421 There are no error messages in the logs, helpful or otherwise.
I verified permissions on the ipxe directory. They are owned by the fog user, and for good measure I have them group-writable by www-data which is what the web server runs under.
@george1421 Yes, proxy settings are correct. I do get the list of FOG kernels to choose from and can see the proxy traffic. I also see the proxy traffic when downloading a kernel. It just never gets installed.
I did find the list of kernels here:
https://fogproject.org/kernels/
But would still like downloads to work via the UI.
I am trying to do a manual update of the kernel from the FOG Configuration menu, and when I start a download I get a “Download Started!” message, and after a while it ends with “Error: Download Failed: Failed - filesize”
Looking through old forum posts suggests one possible cause is permissions and password synchronization, but I am good on all fronts there. Correct file permissions on the ipxe directory, and the fog username and password are all in alignment.
So I am at a loss. The one thing that may be mucking up the works is that we need a proxy to get to the internet, but it does appear to be using the proxy: it is able to fetch the kernel list, and I see (via tcpdump) the proxy requests to api.github.com and raw.githubusercontent.com, so I presume it is downloading. But, after that, it hangs for a while before erroring out.
Where should I be looking here? Is there a log file that I am not seeing?
Can these kernels be fetched manually?
This is running on Ubuntu 18.04.4 LTS.
I just pushed a fix that should solve this.
@pep OK, that extra bit of information you provided combined with my testing at home confirms what you are seeing, and I understand what is going on.
If the machine is in FOG but has not been inventoried, then the -c option fails (because there is no inventory record to fetch). It should just error out gracefully so I need to catch that exception.
The script should allow you to post inventory for a system, however. So that is a bug. I specifically gave it the logic to create an inventory record if none exists, and that means it shouldn’t bomb out because it couldn’t find one. I will get this fixed.
@sebastian-roth as you suspected, this ISO image did boot both legacy and EFI. Which has been a boon.
I have used this ISO four times this week, and it has been a huge time-saver.
@pep Thank you for this info. The Windows stuff hasn’t really been fully vetted yet, and this helps a lot! I’ll set up a couple of VMs at home this weekend and wire them to FOG and see what needs to be done to get this working.
I am guessing it wasn’t able to figure out your hostname.
What happens if you just run:
python fog-inventory -x
Does that dump inventory info?
@pep Make sure to pull from the master branch, and be sure you are up to date. The Windows porting is not rolled into a tagged version yet.
That error is from the original distribution, and it comes from trying to run a UNIX-specific system call on a Windows system.
I’ve made the first pass at adding Windows support, tackling the easy stuff that can be pulled from the registry. I’ll probably be able to get some of what’s missing currently but IMHO it’s really the BIOS version and date that are most likely to go stale on a system, and that has been implemented and tested.
@sebastian-roth I used the grub-mkrescue method and it worked on the first attempt! This is very encouraging, and I am going to ask our lab tech to try this on the other problem systems.
I cannot thank you enough for your help.
@sebastian-roth Thank you! This looks promising. I will give it a shot on Monday.
I have created a Python script for Linux* called fog-inventory that you can use to update a Linux system’s inventory information in FOG. You can run it on a live system, or upload data from a JSON file. It’s a command-line utility that makes use of the FOG API system.
It’s intended to provide an alternative to booting a system to FOS in order to run the explicit inventory collection. Our local experience has been that no one ever does that, so the FOG inventory data slowly goes stale. This script can be run out of cron, at system startup, or even run in batch to update hosts by hand (if desired).
The release is on GitHub and includes documentation.
*You could also run this on Windows, though I’ve not done any testing there. It won’t be able to collect live inventory, but you should be able to use it to fetch inventory data to a file for editing, and to upload data from a file.
@sebastian-roth I did give this a shot on one of our problem systems. It had a 25% success rate, meaning it took four tries before it worked. The first three tries, it hung at “iPXE Initializing devices” and had to be power-cycled (which, thankfully, I can do remotely). The fourth time it worked, which is the first time this system has ever successfully PXE booted.
So these instructions build iPXE, and I presume the idea is to chain load the FOG image from the server?
I am not sure if that will help me. What I really need is to be able to boot FOS directly from an iso. I am leery of involving PXE in the process at all.
I write technical documentation for a living. I can help out with some of the documentation work and am somewhat motivated to document the API.
@sebastian-roth I will give this a shot. Thank you!
Every now and then, we get a system in our lab that just will not do a PXE boot. Most of these are pre-production hardware with some BIOS or network hardware issue, and sometimes it’s a production system with some unspecified issue, but the result is the same: PXE, though supposedly supported by the hardware, just does not work.
To inventory and image these systems, I need a way for them to boot FOS. And that means feeding it a bootable image via the USB port.
There is a nice tutorial that will help me create a bootable USB device, but my problem is that the hardware is sitting in a server room 8 miles away, so inserting a USB drive is not exactly convenient. What I do have, though, is access to the Raritan KVM-over-IP that will give me a console session to the system, and it also lets me remote-mount an ISO image that the BIOS on the system will recognize via the USB port, and boot in either legacy or UEFI mode.
For that to work, however, I need to have a bootable ISO image.
I’ve tried a number of alternatives, many involving trickery trying to get a bootable USB stick to work as a remote image for the device, but I’ve not been successful. I’ve got to have an actual, bootable ISO. And I am out of my depth. I do not know how to create a bootable ISO image of FOS. I’ve spent some time with mkisofs and the above tutorial trying to turn the image and/or the source files into an ISO that will boot, but I have not had success. So I am stuck and need help.
Has anyone done this? If so, can you please give me some hints?