Ok the more I think about it the more I think that error message isn’t accurate. Partclone is failing and not returning a valid error code, so the FOG code is “guessing” its a disk space issue.

Schedule another capture session, but before you hit the schedule task button, check the debug check box. Then pxe boot the target computer. After a few screens of text and enter key presses you will be dropped at a linux command prompt on the target computer. Key in fog and single step through the deployment until you get the error then inspect the partclone log on the target computer, also if you watch the partclone screen you might see the error briefly displayed.

FOGCrypto is and old program used to encrypt password so they could be saved in fog. Not really of value for a cyber security student to write a paper on.

On a whole fog is not very secure because it uses many older protocols like NFS v3 and http (vs https). There is still some very old code in FOG that was written when security wasn’t really a topic. In the context of cyber security there are many reasons to not use FOG in vulnerable environments (if you were looking for a different entry point to discuss). Understand I’m not saying anything bad about FOG, but it was originally written in different time and space.

The developers are slowly working on FOG 2.0 code base that was built from the beginning with cyber security in mind. That release is still a while off at the moment from being realized. But the baseline stuff that has been done so far looks really great.

@Gamienator said in How can I troubleshoot the Diskusage Problem on the Webinterface?:

So like I said before, we have different locations. In our headquarter we wanted to create ONE golden Image of Windows 10. After that we wanted to install a storage node on every location, group it correctly and let it replicate. After that we wanted to let everyone boot to our MAIN FogServer via VPN and let it then image from their node. Therefore we would have control of all locations AND an awesome inventory of all machines. My Collegues working on it already for two months now, but don’t have the Linux knowledge, since their only using Windows. Now that I’m there the project made more progress. But for what I understood I thought to enable the location plugin with user controll would achieve our goal. But it seems like I was wrong

This is not wrong. This is by design how FOG works.

I haven’t read each detail line, but I think where things went wrong in your design is on the storage nodes, where you had 2 disks. While I haven’t looked in the code, I’m pretty sure the storage nodes do not support having multiple disk by creating multiple storage node configurations on the master server. If you did, this would create each disk on the storage node containing exactly the same. For the storage nodes, if you want to have multiple disks then you need to create a LVM volume (kind of like a software span raid) where you can add multiple disks. I don’t want to go down that rabbit hole if I misunderstood what you are doing.

But having a master FOG server at HQ and storage nodes at each location then using the location plugin to assign hosts and storage nodes to locations is how FOG is designed.

Not an answer but a workaround: https://forums.fogproject.org/post/120555

In short for these machines use the 4.15.2 kernel with the inits from the 1.5.2 binaries zip file. The developers are not sure if its a regression bug in the linux kernel or something new. We may have to defer to the linux kernel developers to look into the issue.

The details you provided in your OP are great! The more details we know about the quicker the solution will happen. Can you tell me for that system what CPU is installed since the error appears to be a CPU specific issue (possible missing microcode??)

So after reading your post I’m questioning which is not getting an IP address. — well after rereading it a third time, I see its FOS not able to get an IP address. You are able to get into the FOG iPXE menu so the computer is pxe booting capable (which requires dhcp to be working). You are also able to get FOS onto the target computer, it appears just FOS is having an issue with the network adapter.

There is a couple of things I need you to do.

1. From a computer of the same model that has windows loaded on it. Please go into the device manager and get the hardware ID of this network adapter. What I’m looking for is the hardware ID that would look like thisVEN_8086&DEV_1502 (I made that number up).
2. Manually register this HP Elitedesk 800 G4 using the mac address of the ethernet adapter. Then in FOG schedule a deployment but before you hit the schedule button, tick the debug checkbox. Then pxe boot the target computer. After a few enter key presses you will be dropped to a linux command prompt, this is the FOS (Fog Operating System). key in 'ip addr show take a clear picture with a mobile phone of the outputlspci |grep etwor` again take a clear picture and post both here.

@Sebastian-Roth I can’t think of any reason why or even how we could pass iscsi target information to FOS. FOS uses NFS file share. I can’t think of an imaging reason why we would want to use a block level device that can’t be shared with other FOS imaging targets at the same time. (I know its a bit rambley way of saying take it out its not needed and only causes confusion with the imaging techs)

PXE booting is reliant on your dhcp server. When FOG was your dhcp server it was providing the required settings needed to PXE boot. Now that you are using your business dhcp server you will need to update that service with the settings needed to pxe boot. You will need to set dhcp options 66 {next-server} to the IP address of your fog server and dhcp option 67 {boot-file} to undionly.kpxe for bios based computers or ipxe.efi for uefi based computers.

If you need to support both types of computers in your environment and you have a linux or windows 2012 dhcp server or newer there is a wiki page that shows how to setup dynamic dhcp settings:

https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence#Using_Windows_Server_2012_.28R1_and_later.29_DHCP_Policy

@kafluke said in FOG slow to image when on VM:

I can copy an image from the old physical server over to the VM at the OS level (centos) using SSH with no bottleneck whatsoever (Full 1Gbs)

How about in the other direction new fog server to old fog server? That is actually the direction the image will be traveling during deployment.

Also the other thought is that the old fog server to new fog server is probably happening on the same network switch, whereas going to a target computer would probably be switch to switch communication.

@IT-Knight said in FOG issues on Ubuntu 16.04 LTS:

First, I had set up the fog server and captured an image. I then tried to multicast that image to 2 computers as a test. The capture seemed to work, but after multicasting, I ran into an error when booting the clients. I kept getting an error that said “Invalid Partition Table!” While troubleshooting this, I attempted to reboot the server computer and my network changed my IP Address, causing the server to get all messed up.

First let me say that you should/must set the fog server to a static IP address before installing FOG. FOG does not support dhcp supplied IP addresses. If the fog server changes IP addresses after FOG is installed you will have a very unhappy FOG server. There is a process to resync the fog configuration, but I would get your fog server configured for a static IP address before going through the process.

The clients were now unable to communicate with the server when PXE Booting so I was unable to connect the clients, capture images, and multicast.

The pxe boot settings in your DHCP server need to be updated to the actual (new/current) IP address of your fog server.

Also, I seem to be having some strange networking issue in Ubuntu. When I connect the ethernet cable to the network port, it gives me the up and down arrows to show that it is connected. But when I then connect the ethernet cable to the switch to do the PXE Booting, the up and down arrows do not appear and the computer seems to constantly be searching for a connection.

I would say lets get your IP address issue resolved with the fog server first. Then we’ll need you to clarify “when I then connect the ethernet cable to the switch to do the PXE Booting, the up and down arrows do not appear and the computer seems to constantly be searching for a connection.” Is the fog server doing this or the target computer?

@DarKFeeliN said in Not able to PXE boot from FOGServer on Proxmox LXC with proxyDHCP:

I am concerned the switch settings might not allow me to send those requests to anywhere else than the DHCP-Server

If the dhcp server, dnsmasq service and pxe booting client are all on the same subnet then it should just work with my configuration. If the dhcp server / dnsmasq and pxe booting clients are on a different subnet then you will need to modify your dhcp-helper service on your subnet router. You need to add the dnsmasq (fog) server as the last dhcp server in the dhcp-helper/dhcp-relay service list.

So lets start out with is everyone on the same subnet?

@KennethJ That I’m afraid is too big of a gap in versions.

Replication may work somewhat. The files should be replicated to the remote nodes, but replication will happen over and over since the remote node doesn’t have the ability to answer the current file size. That was added/changed in version 1.5.5.

As a test (if we think its ftp), from your master fog server can you (from the linux command prompt) ftp to the remote fog server, with the user fog and the password taken from the remote fog servers configuration file /opt/fog/.fogsettings. In that file there is a field password= you need that password to remote in via ftp. Once logged in change to the /images directory and create a test directory. That should test the connection. Just a note, you will need to use this password (from the remote fog server’s .fogsettings file) when you setup the slave node settings on the master FOG servers’s storage group. If you can’t login via ftp command line then this is where you need to check.

It was my understanding that this feature was to be removed from FOG. Looking at the github site for FOS it appears that IS still in the package.

I understand why the mount is failing because /opt/fog/clamav is not in the FOG server’s export list. Can you confirm that there is a directory on the fog server /opt/fog/clamav and its populated? We can adjust the /etc/exports to share that directory but AFAIK that feature is not supported by FOG anymore.

@yas1 said in FOG generates lots of DNS queries:

FOG asks pihole for the ip addresses of the devices that are in the FOG database.

The only thing I can think of is that the FOG server will reach out to the target computers to check to see if they are online or not. The results will be shown in the hosts management page list where there would be a red or green icon indicating up or down state. The fog php code mainly uses IP addresses to do its business, not DNS. But the up/down check would only know about system names that it would try to resolve by a DNS query.

@rogalskij Ah ok you are using a linux dhcp server? If that is the case it appears you are not using the one supplied by The FOG Project. No worries, I can give you an example of how to dynamically manage sending the right boot file based on the type of target computer that is booting. This configuration supports both bios and uefi systems without you needing to interface .

Dang Quazz you are too fast.

We had a similar message in a different thread. The OP at that time had a 486 industrial machine that was stalling issues even after I rebuilt a 486 kernel. Anyway, to the point we had to add acpi=off as a kernel parameter for that 486 to boot correctly. Once that was done it imaged correctly.

So lets try a host specific kernel parameter of acpi=off for this host.

moderator note: I forked your topic because your conditions may be different than the previous thread. For reference the original thread is here: https://forums.fogproject.org/topic/8743/can-not-deploy-using-multicast-read-image_hdr-block_size-error

So since you are using ubuntu, have you disabled the ubuntu firewall as the recommendation in the previous thread?

Since you have 2 network adapters in this computer, do you have the correct one referenced for multicast imaging?

If I understood multicast correctly, this way the whole class should be restored around the same time as one computer. Is this correct?

Imaging the group will move as fast as the slowest computer in the group. So if you have a group of 10 computers with 8 core cpus and nvme disks, and one 486 computer with a slow hard drive all 11 computers will image as fast as the 486 computer in the group.

Successful Multicasting is more dependent on your network configuration than FOG imaging. Is the fog server and the target computers on the same IP Subnet/VLAN?

@Peter365 ok here is how we will proceed.

1. Move everything from /images to /Images
   mv /image/* /Images
2. Do an ls -la /images and ensure the directory is blank.
3. Unmount /Images
   umount /Images
4. Now edit your fstab and change the line where the mountpoint is /Images (the line with centos-Images in it) to the /images (note the lower case i) What we are doing is mounting the 931GiB partition onto /images instead of /Images. I know it sounds a bit confusing, but we are putting the disks into the configuration standard for FOG. This will save you headache in the future. Now save the fstab file.
5. From the linux command prompt key in mount -a
6. Now see what is in /images ls -la /images It now should contain everything it had originally before we moved it.
7. If you issue the lsblk command again you will now see that centos-Images is mounted to /images.
8. Done and done

@george1421 With XTS kernel module too: https://drive.google.com/open?id=1N6q6Oqmi7W7WkdtNPK1H0O8B1f-a4RFU

Edit: We may not be done yet depending on the password hash you used ref: https://lists.gt.net/gentoo/user/300718

@DeRo93 I’m glad you have it worked out. As you see in the pcap you are getting two offers from two different dhcp servers (13.252 and 13.253). Each one is giving a different boot file name. So based on random selection some systems should pxe boot correctly and others not. I’ve seen this in the past and know where to look. But its great you found it to add the knowledge to your tool box. Using wireshark/tcpdump is the only way to find this kind of problem, well done!

@egorhan said in Problem with login via LDAP:

cn=administrator,dc=parimatch,dc=local

Just a comment for the bind DN it needs to be the fully qualified path to the account.

For example my bind dn (anonymized) is like
cn=fogbinduser,ou=nyc,ou=domain serviceacc,dc=domain,dc=com

Disclosure, I’m using windows AD for authentication.
From your bind dn, I would assume the administrator account is not in any container but hanging right off the root of domain.com, which is suspicious. Also I would strongly urge you to NOT use the administrator account for this bind. Create a generic, low level user that isn’t even a member of domain users account. All the bind account needs is read access to your ldap server.