@berndttoast23 said in New fog installation, stopping web service failed.:
Thanks for your reply, I took your advice but unfortunately it produced the same result. Any other ideas?
Did you really pull the very latest version via git?? As mentioned by George this changed was pushed only a few days ago and it’s not part of the last RC version but only the very latest from dev-branch.
@JJ-Fullmer Would you mind updating to the very latest RC version. While I am not sure I do remember having looked into a similar sounding issue and fixed that only a few weeks ago.
@jasonm Please try this:
sudo -i
touch /opt/fog/snapins/ssl/CA/.fogCA.pem
cd /path/to/fogproject/bin
./installfog.sh
Please let us know if the issue can be solved this way. I will need to fix that in the installer.
@Chris-Shipley Thanks for bringing this topic back up again as I had lost track of this.
Just pushed a commit to take care of this.
@rogalskij From the log we see that the client keeps receiving Middleware::Response Invalid host. This means the MAC is somehow already known to FOG so it doesn’t wanna register this “new” machine through the client.
Probably best to take a look at the database directly. Take a look at the SQL queries in this topic: https://forums.fogproject.org/topic/12078/i-don-t-see-some-hosts
@IndustrialTech87 said in Error trying to restore GPT partition tables. Exit returned code 4 (On new PC's):
DE94BBA4-06D1-4D40-A16A-BFD50179D6AC
You have a Windows Recovery Partition at the end of your disk (fourth partition)! That prevents FOG from shrinking down to a size smaller than ( 1952490496 (start of 4th partition) + 1034240 (size of 4th partition) ) * 512 (byte sector size) = 931.51 GB …
Do you actually need a recovery partition of you do imaging with FOG?? If you can, delete the 4th partition and resize will work as expected.
@rvelasco Could be disk IO just as well. Why do you think it’s network??
@JJ-Fullmer Thanks heaps for the details and all your work concerning this issue. I will have a bit of time in the next days to look into this and get back to you.
@JRA Interesting. So I am wondering, did WOL work with the old FOG server?
@3mu said in FOGSnapinReplicator.service failing on fresh install:
php[9501]: Could not open input file: env
I totally missed this part in the log when looking through this some time ago. Have been way too busy with other things at that time and obviously missed this. This issue has been fixed a while ago and I cannot imagine this to be the case in the release candidate versions or dev-branch anymore. I just did a test install using dev-branch on Ubuntu 18.04 and I don’t see the messages as stated above.
From my point of view this has nothing to do with specifying a router or not!
@simpsonetti Check out the wiki article on DHCP configuration including the examples.
Most important part in your case is probably next-server x.x.x.x; and those class "UEFI-32-1" sections with various names.
@simpsonetti It’s hard to give an answer on why this doesn’t work the way you want it if we don’t know how the full setup looks like. You are using shared-network which I have never used before. I have no idea what consequences this might have. Are those two networks (172.16.0.0/16 and 172.18.0.0/16) on the same physical ethernet? Using VLANs as well? You might want to post the full output of ip a s and your complete dhcpd.conf plus information on VLANs so we get the full picture.
@RipAU Yes seems like a rough entry. Instead of select * from ... you can use delete from ... (same where clause) to get rid of those or you can use the following commands to do a full cleanup: https://wiki.fogproject.org/wiki/index.php/Troubleshoot_MySQL#Database_Maintenance_Commands
@Pyrol You also might want to share the PC/notebook type and model you have that has issues with getting an IP. Sometimes it’s model specific and updating the kernel to 5.6.18 might help. But it could also be related to spanning tree not setup correctly. To find out if this is the case you connect a really dumb (old) network switch between your PC/notebook and the other network switch and try PXE booting into a task again. Does it get an IP this time?
@Junkhacker @Quazz Looks like the --ignore_crc parameter (discussed here as well) really makes the difference. Will do a test with the latest FOS build later today but a first run - exact same FOS one with parameter and one without - show the time difference.
@Chris-Whiteley @george1421 @JJ-Fullmer @Quazz Would you please all test this new init build: https://fogproject.org/inits/init-1.5.9-ignore_crc-fix.xz (very close to what we released with 1.5.9 but added --ignore_crc option and patches mentioned below)
@Chris-Whiteley Ok, I was misled by the Could not start download: Operation not supported (http://ipxe.org/3c092003) error you posted earlier. I suppose this only happens when it did not even pull the boot.php file in the first place. If you run imgfetch bzImage then it doesn’t know where to get this from I guess.
Now, good you are posting more pictures of this. We see that it sometimes is able load boot.php (earlier picture) and sometimes not! More and more I think this is a network issue.
Is that machine that is not able to PXE boot from your FOG server in the same subnet than the FOG server? Connected to the same switch? Would you be able to hook up a PC to that very same switch the FOG server is on and try again?
@dijsil That’s interesting. We knoe that when updating Ubuntu the PHP versions change but our install scripts should take care of this change. Seems like they didn’t in your case. Run systemctl stop php7.2-fpm and then re-run the FOG 1.5.9 installer scripts.
Edit: Looking through the scripts I think we missed something. Will look into finxing that.
@moderators @testers I am still waiting for more people to test this and give feedback. Adding a manual fix to partclone’s inner core is only wise if we really know this really works!
@michaeloberg Let’s switch to chat -> speech bubble in the top right corner of the forum.