Fresh Install of 1.5.9 with CentOS 7 issues

[Chris Whiteley]

I am having an issue where during a fresh install of 1.5.9 (stable) on CentOS 7 following this install guide: https://wiki.fogproject.org/wiki/index.php?title=CentOS_7. I restore the database and that all goes well, it is just when I try to upload a new image I created I get the following:

bzImage…Connection timed out
Could not boot: Connection timed out (http://ipxe.org/4c0a6035)

What am I missing? The IP addresses are correct going through to this point.

[george1421]

Is it trying to load bzImage from the IP address of your new fog server?

After you uploaded the database onto the new fog server did you go into the fog settings->fog configuration->expand all and confirm that you updated the IP addresses to point to the new fog server?

Also don’t forget to check the storage node configuration too. There is a hard coded IP address in there too.

[Sebastian Roth]

@Chris-Whiteley Either the IP is wrong as George said or you enabled HTTPS and it’s somehow still pointing to http:// URL.

[Chris Whiteley]

@george1421 The IP address didn’t change between old and new so that is not it and I didn’t choose https

[george1421]

@Chris-Whiteley Well then 2 things.

1. If possible post a clear picture of the error so we can see the context of the error.
2. Confirm that bzImage is in /var/www/html/fog/service/ipxe directory.

[Chris Whiteley]

@george1421

Here is the message:

[george1421]

@Chris-Whiteley First this should be working.

So it looks like you are in an imaging phase of pxe booting.

From a browser window key in the following url. http://192.168.20.9/fog/service/ipxe/boot.php?mac=18:66:da:4a:79:d9

That will give us the text behind the boot.php file. Post the results here. There is something going on here that is not obvious.

[Chris Whiteley]

@george1421

#!ipxe
set fog-ip 192.168.20.9
set fog-webroot fog
set boot-url http://${fog-ip}/${fog-webroot}
kernel bzImage32 loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=275000 web=http://192.168.20.9/fog/ consoleblank=0 rootfstype=ext4 nvme_core.default_ps_max_latency_us=0 mac=18:66:da:4a:79:d9 ftp=192.168.20.9 storage=192.168.20.9:/images/dev/ storageip=192.168.20.9 osid=9 irqpoll hostname=207521-test chkdsk=0 img=Windows10EDU-2004-Template imgType=n imgPartitionType=all imgid=16 imgFormat=5 PIGZ_COMP=-6 adon=1 addomain="******" adou="" aduser="*****" adpass="*****" hostearly=1 pct=5 ignorepg=1 type=up
imgfetch init_32.xz
boot

[george1421]

@Chris-Whiteley Just to confirm this is the fog server’s IP address" 192.168.20.9 (I’m sure I know the answer but just double checking).

So does this download the bzImage file?
http://192.168.20.9/fog/service/ipxe/bzImage

[Chris Whiteley]

@george1421 The bzImage file downloaded when I clicked that link. Yes, the IP is 192.168.20.9.

[george1421]

@Chris-Whiteley Well this is a good one. It should be working especially if you can download the file via a browser. All of the parts are in place and work individually.

[george1421]

@Chris-Whiteley if you were to pxe boot to the error and hit s to get to ipxe console.

Then in the ipxe console what happens when you key in imgfetch bzImage ? It should say that it trasferred it. You can’t do anything with it, but this will test the http download to memory of the kernel.

Does only this specific computer do this or does all computers even of different models error out? There is something here we are missing.

[Chris Whiteley]

@george1421 I just tried that command and got:

Could not start download: Operation not supported (http://ipxe.org/3c092003)

[Sebastian Roth]

@Chris-Whiteley That sounds really strange. Do you have SELinux enabled or disabled? Though you wouldn’t be able to download the file through the browser it SELinux would be in the way.

So let’s try to rule out some things:

• Use a different machine (best different vendor and all) and try to upload an image from that.
• Re-download iPXE binaries and put in /tftpboot just to make sure there is no issue with those: https://github.com/FOGProject/fogproject/tree/master/packages/tftp

[Chris Whiteley]

@Sebastian-Roth I just make SELINUX disabled. It was set to permissive. That didn’t make a difference.

• I tried using a different machine, but all we have are Dells, but I tried 3 different models and encountered an issue where it would sometimes download the bzImage, but then get to init.xz and do the [connecting]… that goes across the screen and then fail.

• I downloaded the iPXE binaries and that didn’t help either.

Is there a log I can look at specifically for this issue?

Thanks for the help!

[Tom Elliott]

@Chris-Whiteley I don’t have access to a server right now but if I remember correctly, there is a fog setting (fog configuration->fog settings) that stores the fog service directory.

If that field is fog/service then I’m not sure what’s wrong, but if it’s fogservice as we’ve seen in the past, I imagine this could be causing the problem.

Based on what I can see, this is currently just set to fog, if that’s the case can you change it to be fog/service

The part that’s making me think this is the output of

set boot-url http://${fog-ip}/${fog-webroot}

This should be
set boot-url http://${fog-ip}/${fog-webroot}/service/ipxe

[Sebastian Roth]

@Tom-Elliott said in Fresh Install of 1.5.9 with CentOS 7 issues:

This should be
set boot-url http://${fog-ip}/${fog-webroot}/service/ipxe

No I don’t think so. iPXE pulls files that do not a full URL from the same location it got the last file from. So it pulls http://${fog-ip}/${fog-webroot}/service/ipxe/boot.php and would download kernel and init from that same location as well.

[Chris Whiteley]

This post is deleted!

[Sebastian Roth]

@Chris-Whiteley Unfortunately there is no log file for this except the Apache logs.

Please run tail -f /var/log/httpd/access_log while doing the PXE boot and see if you get the requests logged in there.

[Chris Whiteley]

@Sebastian-Roth This is what I saw:

192.168.20.41 - - [06/Oct/2020:08:37:18 -0700] "POST /fog/service/ipxe/boot.php HTTP/1.1" 200 652 "-" "iPXE/1.20.1+ (g4bd0)"

192.168.20.41 is the client