Hmm. Even after shutting down that other server I’m not able to PXE boot any machine into Fog.
I rebooted the Fog server a couple of times, but there’s still no change.
What can I do to check that all the services needed for PXE boot are running on the server? I’m using the FOG’s DHCP server BTW.
@Zerpie Ignore that last post. The tablet was connecting to another DHCP server on the network that wasn’t supposed to be running at the time.
@george1421 I’ve been trying to do just that but when I try to PXE boot the tablet now it’s failing to grab an IP address from the Fog server DHCP. This doesn’t seem to have anything to do with adding BzImage32 to the host. It’s doing the same regardless. Is there something I can do in the Fog server to help it assign an IP to this? Maybe it’s not letting go of it’s current lease.
I’m trying to get Fog to work with imaging a bunch of Windows 10 point of sale tablets that my company sets up for our customers. The tablets connect to a base station with usb and an ethernet adapter built into it. They are 32bit machines and UEFI with no ability to switch to Legacy BIOS. When I try to do a full host registration it hangs on bzImage and never continues past that. So tried adding the host via the web interface and start an image capture task. Once again the tablet will get to bzImage and hang.
I followed the BIOS and UEFI Co-Existance wiki entry https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence incase it wasn’t getting the boot image it needed as an UEFI machine, but it’s still hanging on bzImage.
Looks like I needed to be a little more patient or do just a little more research. I read a post that explained that this is a known issue and it will sometimes get stuck on “Saving original partition table…” but will eventually move past it after about 5 minutes or so. Sure enough, my capture process continued after a little while. Good to know.
I’m assuming that since fixparts isn’t spitting out a warning about GPT signatures detected on the disk and offering to fix it, that this isn’t my issue. But then I’m back at square one with the process hanging when on “Saving original partition table” when trying to capture an image. Not sure what else I can try to fix this.
@Wayne-Workman I’m running 1.5.4 and it’s a fresh install as of yesterday.
I ran into the issue of my image capture hanging on “Saving original partition table…” I did the research and found my answer. There is likely remnants of GPT partitions on the disk and I need to boot the host into debug mode and run fixparts.
And that’s where most of the posts I’ve found while researching this issue ends. “Run fixparts…” So I updated the kernel so that I am able to run fixparts. I run it.
fixparts /dev/sda
But then I get
MBR command (? for help):
I hit “?” and I’m presented with a list of choices.
a toggle the active/boot flag
c recompute all CHS values
l set partition as logical
o omit partition
p print the MBR partition table
q quit without saving changes
r set partition as primary
s sort MBR partitions
t change partition type code
w write the MBR partition table to disk and exit
I have no idea what I’m supposed to choose and none of the posts I’ve found have mentioned what choice I need to make. They either just say to run fixparts or run fixparts and follow the prompts. I also don’t want to erase any data on the disk and this is an image that I need to capture.
I decided to go ahead and start all over with CentOS7 instead of Fedora this time. I setup the server as well as Fog the same exact way. This time I didn’t run into any issues with the Fog server’s firewall like I did on the Fedora server. And I was able to successfully capture an image from my test laptop with no errors.
I’m running another test right now with deploying the image to the laptop to make sure there’s no issues there, but it looks like switching to CentOS worked for me.
I know the most recent wiki on installing fog on Fedora is specifically for Fedora 25 so maybe a lot has changed between Fedora 25 and Fedora 28 that the same instructions won’t work, but I’m just guessing.
@george1421 No problem. Thanks for looking.
@george1421 I think I’m going to go ahead and do a fresh install of the OS again tomorrow. Maybe Fedora Server isn’t the way to go. Is there a recommended Linux distro I should use instead?
Everything about my issue is still pointing to credentials not matching, but I’ve gone through the troubleshooting for that over, and over, and over again. Fresh installs and all. What else can I do? I never touched the credentials in the first place!
@george1421 Sorry, George. I had to go ahead and try and run an image capture task again to see specifically what it was doing. I receive the error when it attempts to update the database. It shows
UPDATING DATABASE…FAILED
Error returned: Type: 8, File: /var/www/html/fog/lib/fog/fogcontroller.class.php, Line: 975, Message: Undefined offset: 3, Host: 153.86.19.10, Username: fog
I have a feeling there might be a permissions issue with /bin/fog.upload, but I can’t find fog.upload anywhere in /bin/.
@Zerpie Based on the error message I checked /var/www/html/fog/lib/fog/fogcontroller.class.php line 975 and the line is
if ($fields[3]) {
array_walk($fields[3], $whereInfo);
Anybody have any clue what that means?
@george1421 It was finishing up capturing an image from a host. Other than that error at the end, it looked like it finished capturing the image. Then I got the error and the host machine rebooted. The task still shows that it’s running and is sitting at 97%.
@george1421 I did indeed hit all of those sections. The tftp settings is the only place that had the wrong password.
It doesn’t appear to be multicasting. When I go to Tasks > Active Multicast Tasks it does not show my capture task.
Unfortunately this did not fix it. I ended up with the exact same error.
Update: I just went back through and checked all the places where the fog password is set and somehow the tftp settings in the Web interface was a different password. I set it to the same password that was in /opt/fog/.fogsettings.
Now I’m trying to capture the image again. Hopefully that’s all it was. I’ll give another update if it was successful or not.
I just got my Fog server up and running on Fedora Server 28 and while attempting to capture my first image everything appeared to be going well until the very end when I got the error
“Could not complete tasking (/bin/fog.upload)”
and
“Error returned: Type: 8, File: /var/www/html/fog/lib/fog/fogcontroller.class.php, Line: 975, Message: Undefined offset: 3, Host: 153.86.19.10, Username: fog”
I searched the forums and found a couple of posts with the same error, but it doesn’t looks like my error is caused by the same thing. I know you can receive this error if the password for the fog user gets changed in some places, but I haven’t touched that password. This is from a fresh install and the password matches everywhere.
I also took a look at /var/www/html/fog/lib/fog/fogcontroller.class.php on my server. I don’t see any glaring issues in there, but then again, I don’t know what I’m looking for.
Could there be something else causing this error?