@rotoi Are you still running fog 1.3.3? More specifically you updated the kernel to something more modern, but have you touched the init.xz file? FOG 1.3.3 doesn’t (shouldn’t fully) support NVMe drives. The NVMe protocol wasn’t created until much later than FOG 1.3.3. Its akin to trying to install Windows 95 on an 11th gen laptop. It would kind of work, but not really well.

@cf20corvuss Well lets think about this for a minute.

The screen shot you provided looks like the fog ipxe boot loader. If it is we can then make a few assumptions. My hesitation ATM is that some hypervisor’s use iPXE as their pxe boot rom (Virtual box being one). If we work under the assumption that the screen shot shows the FOG iPXE boot loader we know this.

The target computer can speak to the FOG server. We know then because the iPXE boot loader was sent by the FOG server and received by the PXE booting computer. The target computer is getting a dhcp address from some place AND that dhcp information told the client where to get the iPXE boot loader from. So we know that dhcp is working. We know that iPXE has the proper driver for the network card in the pxe booting computer because iPXE sees the mac address of the network adapter.

Where we typically see this is with the network configuration where Spanning Tree is enabled but one of the fast spanning tree protocols are not used. Standard spanning tree will listen for a loop back interface for the first 27 seconds a link is active then start forwarding data. With imaging when the PXE ROM hands off control to iPXE, iPXE will reset the network interface causing the link to drop briefly as iPXE boots. Well this link briefly dropping causes the spanning tree counter to reset. So when the target computer is trying to get an IP address again, spanning tree is still listening for a loop back. By the time standard spanning tree starts forwarding data again, iPXE and FOG have already given up.

You can test this in a physical world by putting a dumb unmanaged switch between the building network and the pxe booting computer. This unmanaged switch will keep the building switch from seeing the brief link drop. Most cheap switches do not support spanning tree. So its all good there.

Now NAT and imaging do not go together with FOG. Everything needs to be bridged with real addresses for FOG imaging to work.

@george1421 said in Issue with EFI through PFSense Firewall:

@jonhwood360 said in Issue with EFI through PFSense Firewall:

so one thing I keep seeing in the packet capture which is weird, is that the router option (3) is set to 10.255.252.1 which is the gateway that the fog server uses, but is not the gateway for the external network. .

Well lets think about this for a minute. When I looked at the packet capture I did notice the lease times were different too.

Looking at the config file you provided both the lease times and route address are set correctly. Why are we seeing a difference in the packet captures from the configuration. Its almost like we have a different dhcp server for bios than uefi. Or two instances running with different config files on the FOG server.

Yep. The only thing I can figure is that somehow either the DHCP Relay or Arp Proxy in Pfsense is doing something weird, or the DHCP server is not processing my second range definition in its entirety (which is weird because booting into an OS proper, the exchange happens normally and gets the right settings).

Although in the mean time I have had to move along in my research so I moved the DHCP/ Bind DNS to PFsense and have configured it to have the correct options. EFI boot from fog server is working in this new configuration. I am leaving the existing configuration in place on the fog server though to return to this issue (which I think has value to try and solve).

@sebastian-roth
I was able to figure it out - when I made the vm that I took my image from my fog-server address was different as I installed it many times trying to get it to work.
The machine I captured the image from had the fog-client pointed to the old server, once I removed the fog-client and reinstalled with the FQDN it did the trick.
Thank you

@sebastian-roth The kernel update works now and image capture is successful.

I’ll start a new topic on the networking issue.

Thanks Sebastian!

@sebastian-roth or the web items are being compressed, but not decompressing for display.

@jonathanho92 said in Help in deleting image in fog server:

When i try to click delete they prompt me for credential i am not sure which credentials to key in to delete the image

That’s the same credentials you use to login to the FOG web UI. It’s just a safety thing to prevent people from deleting image files in a rush.

@jbandy Edit C:\Program Files (x86)\FOG\settings.json on the client machine. Then restart the service called “FOGService” or the computer.

@tom-elliott
@Sebastian-Roth

Thank you all. It is solved now in 1.5.9.78 with HTTPS on.

/var/log/apache2/other_vhosts_access.log

80 "POST /fog/management/index.php?node=client&sub=wakeEmUp HTTP/1.1" 302 599 443 "GET //fog/management/index.php?node=client&sub=wakeEmUp HTTP/1.1" 200 9111 443 "POST /fog/management/index.php?node=client&sub=wakeEmUp HTTP/1.1" 200 9111

/opt/fog/log/fogscheduler.log for Power Management Task

[04-29-21 6:16:25 am] * 1 task found. [04-29-21 6:16:25 am] * 0 scheduled task(s) to run. [04-29-21 6:16:25 am] * 1 power management task(s) to run. [04-29-21 6:16:25 am] * Power Management Task run time: Thu, 29 Apr 2021 06:16:00 +0000 [04-29-21 6:16:25 am] * This is a cron style task that should run at: 1619676960. [04-29-21 6:16:25 am] * Found a wake on lan task that should run. [04-29-21 6:16:25 am] | Task sent to fcaa-https

/opt/fog/log/fogscheduler.log for Scheduled Task:

[04-29-21 6:22:26 am] * 1 task found. [04-29-21 6:22:26 am] * 1 scheduled task(s) to run. [04-29-21 6:22:26 am] * 0 power management task(s) to run. [04-29-21 6:22:26 am] * Scheduled Task run time: Thu, 29 Apr 2021 06:22:00 +0000 [04-29-21 6:22:26 am] * This is a cron style task that should run at: 1619677320 [04-29-21 6:22:26 am] * Found a scheduled task that should run. [04-29-21 6:22:26 am] - Is a host based task. [04-29-21 6:22:26 am] - Unicaset task found! [04-29-21 6:22:26 am] - Host fcaa-https [04-29-21 6:22:26 am] - Task started for host fcaa-https!

Thank you again! Now our school can wake-up on Schedule 😉

Peter

@tom-elliott So to clarify that last point Tom, the SQL should reflect under ngName both the Storage group name AND the Storage node name? DCSTORAGE in this case is the name of the Storage node master server for the Storage Group 3 storage group.

I’ve compared to the other image(s) which are only hosted on (and are being replicated from) the Master node and they only reflect the main storage group under ngName.

I’ve made note of the replicator service restart command, cheers. I went a bit neanderthal and just rebooted all my servers just now to see if that kicked things into life.

Checking the Image Replicator logs under FOG Configuration > Log Viewer it only references DCMASTER and the 2 nodes in its storage group. Does replication from the Storage master of the other storage group show in these logs? Or do we need to check local log files on the server itself?

cheers Tom

@sebastian-roth In the back of my mind I was knowing that its something at a lower layer … I am the only admin on this network so I dont know how it self destructed from 1 day to the next, might consider a windows update, but moving dhcp off windows would rule that out. Will try a pcap.

@stephane The directory listing and settings look fine. No idea why it shows “No such file or directory”. What kind of DHCP server do you use? Settings?

Can you please capture a packet dump and upload a PCAP to a fileshare and post link here? https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

@sebastian-roth

It was just a hiccup. Running the installer again without git pull there weren’t any errors.

foginstall.log

Update!

So I upgraded to Ubuntu 18.04 which did not resolve the issue. I then updated FOG to 1.5.9.71 which must have been release today 🙂 . After completing the FOG update, the services are running and I was able to successfully deploy 2 machines using multicast. I rebooted the server and verified that the services started after a reboot. Thanks for your help and working on this awesome software!

@robertkwild “better” is a relative term. I suggest following the command because we know it will do what it needs to do properly.

@d2freak82 said in Error on first PXE boot:

later popped an error that the drive was unclean on 2 different laptops

This is expected if you did not shutdown the computer properly before image capture. The shutdown command from the start menu is not sufficient.

You have the following options to properly power off the computer for image capture.

Run the following command from a command prompt shutdown -s -t 0 Use sysprep to power off the computer using the proper command line switch. Turn off fast startup in windows.

The kernel version I’m referencing is for FOS Linux (what get downloaded to the target computer), not the host OS kernel version. You can see the kernel version using the web ui FOG Configuration->Kernel update.

i have resolved this issue. I am not sure but when i was looking into ubuntu it did not update the images correctly. I moved them again and this time it was working correctly

i used FTP software , filezilla , to see the files where not on the ubuntu server but the gui was saying it was there .

@mmoore5553 Good to hear you were able to make it work. Just a few comments on what you said:

I ran the setup again in the vm and finally go the error setting up and starting dhcp server - no router address found - no dns address found.

The router and DNS addresses are only used by the FOG installer to set those in the DHCP configuration to be sent to clients requesting IP (and router/DNS information) from the DHCP server.

if i want a VM to connect I have to change my VM to Nat and not bridged.

Hmm, I would think you can set all VMs to bridged and should be able to PXE boot VMs and physical machines then.

@mmoore5553 said in drive not expanding fog 1.5.9:

@scott-b yes it is . Windows 20h2 . I finally got it resolved by the moderator. I had to go into my image and delete the recovery drive. Then it acted correctly.

Just wanted to put that out there if someone else had the same issue

Thank you for letting me know. I’m having the same issue so I’ll give that a shot.

@jonathanho92 Upgrade your FOS kernel version to 5.6.X or later. I would go to 5.10.12 or later to get the latest hardware support.