Being a member of FOG Hangouts will allow you to stay updated about the latest FOG Hangout; the when, the where, and the details. Membership in this group is automatic membership in a mailing list.
@geardog said in connection timed out chainloading failed:
No mention of next server.
So I would expect tcpdump to just not print it on the direct verbose text output. We did see it in the PCAP file. Or you have played with things so much that clearOS doesn’t send it anymore. But then I would expect the PXE boot to work just fine (with dnsmasq on the FOG server).
@boombasstic Please do us a favour and deploy this image with 1.5.9 again but do it in debug mode this time. When you boot the host up you get to a command shell. Enter fog there to Start the deployment and step through it. If you notice a message between the normal output take a picture.
Then at the end you get back to the command shell. Enter sfdisk -d /dev/nvme0n1 and take a picture of the full output on screen. Post picture (s) here.
@mickg Normally we find that Dell disk not recognized issues is due to Dell BIOS setting SATA/NVMe Operation mode to “Raid On”
Change the operation mode to “AHCI” and you will likely be able to register and image the machines.
That said, there are some steps involved in changing from Raid On to AHCI.
@geardog Interesting that Nick doesn’t see the next server filed being populated. I am wondering if it’s just something tcpdump doesn’t print on the console? So can you please run tcpdump -i enp5s0 port 67 or port 68 -e -n -vv (maybe need a different network interface name) on your clearOS while PXE booting a machine? Post output here so we can all compare to what Nick posted in the other forum.
@Florent For me it seems to work with power management. Scheduled a task and checked with tcpdump it actually sends the magic packets (WOL).
Can you please check /var/log/fog/fogscheduler.log to see what it says. In my test case I see this:
[03-03-21 4:35:27 pm] * Sending 1 wake on lan request.
[03-03-21 4:35:27 pm] * 1 total mac attempting to wake up.
[03-03-21 4:35:27 pm] * 1 task found.
[03-03-21 4:35:27 pm] * Task run time: Wed, 03 Mar 2021 16:35:00 +0000
[03-03-21 4:35:27 pm] * Found a wake on lan task that should run.
[03-03-21 4:35:27 pm] | Task sent to testhost
@boombasstic Hmmm, ok. Seems like I was on the wrong track with the partclone issue. Now that I think about that issue again it might have been the deployed Windows did not even boot.
Good you mention the d1.fixed_size_partitions file. Can you please post the contents of d1.partitions and d1.minimum.partitions here as well so we know what your partition layout looks like.
@lambo I am not exactly sure what size and file types are allowed in the forums. You can give it a try or upload to a file share/cloud of your choice and post a link here.
That looks to be the case. Just a fluke. Today, it installed fine.
@boombasstic I think you run into an issue we fixed after the release of 1.5.9, see https://github.com/FOGProject/fos/commit/8d310f51d7d945c5dc1685eb6698d1aed8634dc7
I suggest you just grab the latest inits from our server and use those until we officially release the next version of FOG.
https://fogproject.org/inits/init.xz
https://fogproject.org/inits/init_32.xz
Put those into /var/www/html/fog/service/ipxe/ on your FOG server, renaming the original files.
@george1421 I will certainly never try to upgrade CentOS forklift style again. You were correct I upgraded Centos from version 7 to 8. After the mess it created I took your advice and ran the FOG installer using “GIT” and it cleaned up a bunch of the issues. A BOAT LOAD of things were missing after the upgrade but now they are functional. Thank you for all the assistance, FOG’s community and dev team is top notch.
