Steps to switch to working branch.
cd <directory where git-repo is stored>
sudo git checkout working
sudo git pull
cd bin
sudo ./installfog.sh
Steps to switch to working branch.
cd <directory where git-repo is stored>
sudo git checkout working
sudo git pull
cd bin
sudo ./installfog.sh
@robtitian16 Tutorial most appropriately names: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue
Post the pcap to a google drive/dropbox/etc and then share the link, either in a forum or IM me the link and that will tell us what is going on. It really helps to have the fog server, dhcp server, and pxe booting client on the same vlan to see the entire conversation. If that’s not possible, you can use wireshark on a notebook on the same vlan as the pxe target computer to capture at least the dhcp process. That is where the process is failing.
Just looking at the picture very closely I see you are using multipart all disks (mpa). I see in the picture you have both a NVMe disk and a standard hard drive mcblk0 and sda. The problem with the mcblk0 it has two boot blocks that aren’t really usable. Are you trying to clone both the nvme and sda disks? Or since you are using mpa are the source and target disk sizes the same? Since you are using non-resizable?
This article may help you to update: https://forums.fogproject.org/topic/10006/ubuntu-is-fog-s-enemy
Also there is a error log file in a directory next to the installfog.sh script. Look in that sub directory to see what is behind the error “Backing up database…”
If you can explain things better in your language please do so, we can translate with google too. I will only answer in us english because that is what I think in.
@deimos First the shaming… Its not helpful to mask the IP address of the device unless you have a public IP address range. There is no way for me to hack you if you are on 192.168.0.0 range externally.
Is your FOG server and this target server on the same subnet?
Usually I like to collect more information, but I think we should jump right into a packet capture of the pxe booting process to tell us what is going on: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue
If your fog server is on the same subnet as the target computer, use the fog server to collect this information so we can see the entire pxe booting process. If its on a different subnet then use wireshark with the same capture filter to capture the dhcp process. The wireshark computer needs to be on the same subnet as the target pxe booting computer.
You can either review with wireshark on ubuntu, or upload it to a google drive and share the link either here or send me an IM with the link and I will review it.
@hanz If you wouldn’t mind, please expand on what you had to set in the GPO to correct this. Your solution will probably help the next FOG Admin who’s pulling his hair out trying to understand what happened…
@entr0py said in Error Restoring Images - Clients having identity crisis:
MSI
Can I ask you to post to this thread: https://forums.fogproject.org/topic/10987/what-can-we-do-when-we-don-t-trust-uuid With the inventory data from one of those MSI boards? We only need one entry unless you have different computer models than mainstream Dell,HP,Lenovo. We are looking for a good example of different mobo manufacturers and how they populate smbios (what FOG queries to identify the target machines).
well that really didn’t help readability at all.
But it looks like its a database issue. You might want to review this thread and see if it addresses the issue. https://forums.fogproject.org/topic/10006/ubuntu-is-fog-s-enemy
Especially if FOG was working one day and its broken the next day without any intentional changes.
On each fog server (normal or storage node) there is a linux account called fog
. This is not the default web gui admin called fog
but a linux account by the same name. Your storage node configuration needs to match the user ID and password correctly for the linux account. If these were complete fog installs the linux user fog
’s password will be in a hidden file in /opt/fog directory called .fogsettings. Review this file on each fog server and be sure the storage node configuration is consistent with these files.
@sudburr Since this is a new fog server install, did you remember to disable selinux as well as stop the firewall?
The permission denied is a new one for me. I have to look that one up. It might be the file permissions in /tftpboot, but I need to research that a bit.
First I would say, make sure you upgrade to the latest RC10.
I don’t think that is your problem, but the devs will request you do that anyway so they can help.
What I find strange is why all of your target computers have the same mac address? How is this possible?
There is something going on here beyond what you posted.
Since FOG seems to be using SANBOOT for exiting is your HP Server in BIOS (legacy) mode or UEFI. The answer is different based on the mode the server firmware is in.
For this server, go into the host definition. Lets assume this sever is in bios mode, change the BIOS exit type to GRUB First Hard Drive. Hint: You may need to experiment with the ext types to find the right one that works with your hardware. The rEFInd exit type is for UEFI hardware.
The other thing I can say (at least for my company) we don’t have servers pxe boot through FOG. When we go to image a physical machine we press the F10 or F12 to bring up the boot manager during the system POST. Then from the boot manager we select PXE boot into FOG. This way we are sure there is no way to accidentally reimage a server. We have a rule that a technician must be in front of the server before it is allowed to be reimaged. If you use this method the hard drive is always defined first in the boot order.
@kevin-talbot What would be interesting to see is this…
Use a disk bench marking tool like CrystalDiskMark and compare the write performance between the two disks. The tool used doesn’t matter you just need to use the same tool on both systems to get a relative index between the two drives. The most important number for FOG imaging is sequential writes.
@sjensen Yes a snapshot would let you roll the changes back to a known good condition. Just don’t forget to integrate your snapshot into the VM once you have proven that the update is successful.
@sjensen The first link that Wayne posted speaks directly to your need. Just don’t execute any git checkout xxxxx
commands unless you want to upgrade to a development release. I can say that 1.5.0 RC10 (git checkout dev-branch
) is pretty stable and does fix a few issues that exist in 1.4.4. stable.
@greg-plamondon Well there is a couple of things I see in this setup that made me squint a bit. (not in any particular order)
I would focus on dropping the vCPU count and extending the check in periods first. Then assess the next steps.
So why is fog slow on the initial login? Its probably related to FOG creating and caching your session from the sql database that is being beat up.
@tmerrick Then take that same the same filter (without the -w wol.pcap
flag) and use wireshark on a laptop. Connect it to that subnet. WOL packets are broadcast packets so if its being generated on that subnet you should trap it.
I can’t speak about the root user, but if you happened to create a system user called fog
for normal system maintenance, the fog installer creates or captures that user account for its internal service account. Understand this is the linux user fog
and not the webgui default administrator of the same name fog