@zaccx32 said in All hosts deleted/not showing in host list/groups:

After cleaning that up, a few hosts showed up but most are still missing and our images are not showing up in the GUI either.

While disk space is an important thing and 99% seems a lot in first sight, I don’t think this was causing the issue here. Why? Because we see you have a large disk with still 31 GB shown as free. I find it very strange that you see some hosts now. From the SHOW DATABASES; output you posted I would have guessed the fog DB is fully corrupted now and needs recovery (keeping my fingers crossed it’s still possible).

Also, when trying to access the fog DB today, is cannot be found any more, almost like it is gone.

Now we really need to figure out what’s going wrong with the DB. First of all let us take a look a the DB files on disk, the real basis: ls -al /var/lib/mysql (post a picture here)

As well stop the DB and take a file backup. Then start it up again and check the log:

service mysqld stop cd /root mkdir backup rsync -av /var/lib/mysql backup service mysqld start tail -n 30 /var/log/my*

Post a picture of the output from the last command as well. I really hope I got all the commands right for your pretty dated CentOS 6.9 install.

@rodluz said in HostnameChanger Issue:

Would anything break if I run UPDATE hosts SET hostEnforce=‘1’; to update all hosts in one blow?

No, that shouldn’t break anything. I reckon it’s save to do - if you really want this.

@aloniada Playing with this today I figured out what changed in (U/Ku/Lu)buntu and Mint from 20.04 (or maybe earlier) that causes the mentioned error Unable to find a live file system on the network even if you add the ip= parameter (which you definitely have to!)…

You need to copy the hidden folder .disk from the ISO as well which is missed when using the copy command. See more details here: https://forums.fogproject.org/topic/14590/20-04-autoinstall

But be aware that in your case you need to get the ip= parameter right first so the NFS over TCP not available ... error goes away!

this is a VM from the server itself so no way it’s network issue

I also ran into an issue where ip=dhcp did not work in a VM setup. I actually had to set a static IP - which really is a shame!!! So instead of ip=dhcp this worked for me:

... ip=192.168.3.123::192.168.3.1:255.255.255.0:hostname:enp0s3:none:192.168.3.1 ...

@sebastian-roth this has worked for me with a brand new HP 440 G8

@lcsmd Thank you for reporting back on how to get it working. When adding it to the wiki I figured out it uses the “ASIX AX88179” chip and we had some of the Startech devices listed in the “Notes” column already. So I added your USB31000SPTB to that list as well to be found by others - including the hint to use a different iPXE binary.

I have to say the list is not really up to date. Mainly the notes are not because it’s a lot of work to keep it up with information from forum posts only. Nor do we have time and resources to test all the hardware ourselves.

@george1421 : Right !

I removed all offending spaces and voilà !

Thank you very much .

PS : By the way i noticed the error also occurs when i select multiple entries as : default item.

@ice4192 Like this?
https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence

@SomeWeirdRandomDude Please post the full fog.log from that client here.

By the way, which version of FOG and the fog-client do you use?

@john3892 As you see your version of FOG is way newer than the one of the original post here, so please open a new topic and post all your details there.

@sebastian-roth Ahh, I didn’t see that either. Okay, so in DHCP I changed the router to 192.168.22.1 and range starting IP to .20

In fogsettings, I changed both routeraddress and plain router from 192.168.22.11 to 22.1

The test client gets online just fine now.

Thank you again, Sebastian!

@mesaman0182 Thanks to @Tom-Elliott this is fixed in dev-branch. So if you want to install FOG on Ubuntu 21.04 you just need to use the latest dev-branch version from github.

@george1421 That makes sense, thanks!

@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.