@wanderson Sorry for the long deply!! Re-reading your postings I am wondering why you use FOG 1.4.0. This is years old and there have been many changes since.

We do not have many people working on FOG at the moment and therefore can’t support older versions. If you upgrade to 1.5.4 and still see the same issue we might be able to help you out.

Don’t get me wrong. If I could see why this is not working I would surely tell you. It’s just too little information and the version gap that I tell you we won’t be able to help just like this.

@Fithian Sorry if I wasn’t clear enough. Those are two different things. Database is holding all the host, image definitions and FOG settings. If this is lost you will have to create those things manually again. Either register clients through the FOG menu or manually add clients in the web UI.

The other thing is the fog client being installed on the client computers. They won’t connect to your new FOG server unless you are able to recover the SSL certs/keys from your old server and put in place on the new one. Read the article I posted.

As you have not told us much about what is lost and what is still left I am just doing guess work here. If your old server is totally gone and you can’t get hold of the SSL files you will probably need to re-deploy the fog-client to your hosts. Any deployment tool will do that job I reckon.

@george1421 @pbriec Not sure where we are headed with this. Directly booting the kernel as UEFI binary like I suggested seemed to cause the kernel to hang just the same. So I am very confused on what exactly is being done. It doesn’t add up for me because the FOS USB boot suggested by George is very similar to what I asked you to test…

@Fithian Using the exact same server IP and hostname for your new one is the first important step. Did you take a full backup of the old database to import into the new server?

About the clients, read this: https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG#If_old_server_was_FOG_1.3.0.2B

@pbriec Will have to check my code when I get home. Don’t have that here at the moment. But I am wondering about the third line done. Not sure where this is coming from but I can’t remember having that in my debugging output. Possibly I am wrong, will see later.

I worked with JJ on a similar issue where it seems to hang on exit_boot. But this is a HP Stream 11 x360 device. I really wonder if we see buggy UEFI firmware in both cases?!?

Can you please try booting Live Linux Distros, like Ubuntu Live, System Rescue Disk or so. Will be interesting to see if those boot properly.

The other thing you can try is booting that downloaded kernel image directly from a UEFI USB boot stick. To create one format as FAT32 and create directory X:\EFI\boot\, put the kernel binary into that and name it bootx64.efi. Now boot off this USB stick and see how far you get. If it proceeds beyond the exit_boot stage it will crash in a kernel panic later because there is no root filesystem to mount and boot off. That’s ok. We just want to see if it can get past exit_boot when started in a different way from a USB stick instead of PXE boot.

@mronh You are on Ubuntu on your master node, right? We are tracking down a replication issue but we see this on CentOS and possibly RedHa so far.

Please run ps ax | grep defunct on your master node and let us know the result of it.

@John-L-Clark This is out of FOGs scope as we find WIFI not to be a reliable connection for deploying or capturing an image to/from a PC. So years back it was decided to ignore WIFI adapters altogether. We don’t have drivers for WIFI enabled in the iPXE boot nor have we included drivers in the Linux kernel that we use in our FOS imaging environment booted on the client machines.

Would be a huge task to add this and make it work reliably in most cases (thinking about different WIFI standards, driver issues and encryption stuff).

Why do you want WIFI to be the default/primary MAC?

@mronh Ok nothing serious in the apache and php-fpm logs. Revisiting the other logs you posted I just noticed this:

2018-10-05 13:43:26 /images/Sala209RebootRX/d1p1.img -> ftp://fog@YYY.YY.210.208/%2Fimages/Sala209RebootRX/d1p1.img 0-8733059 1.77 MiB/s
...
2018-10-05 13:53:51 /images/Sala209RebootRX/d1p2.img.084 -> ftp://fog@YYY.YY.210.208/%2Fimages/Sala209RebootRX/d1p2.img.084 0-91065975 1.99 MiB/s
....
2018-10-05 17:39:43 /images/Sala209RebootRX/d1p2.img.084 -> ftp://fog@YYY.YY.210.208/%2Fimages/Sala209RebootRX/d1p2.img.084 0-64085945 101.21 MiB/s
2018-10-05 17:39:43 /images/Sala209RebootRX/d1p1.img -> ftp://fog@YYY.YY.210.208/%2Fimages/Sala209RebootRX/d1p1.img 0-8290491 82.63 MiB/s

To me it looks like file sizes differ and as well transfer speeds are way different too. Doesn’t add up for me yet.

@pbriec Please follow George’s advice to make sure your setup is right. On the mentioned machine you should definitely see bzImage and init.xz boot up as this is a 64 bit CPU. Try to see why it does bit bzImage32 first.

From what I read between the lines this seems to be specific to the Optiplex 5260 machines, right? So other clients PXE boot fine and can register as well as capture and deploy images?!

If you have it boot bzImage properly and you still see the it looping then you might want to try some more advanced debug steps. From what I know about this it will be fairly hard to diagnose this but lets give it a try. Download this kernel image and save in /var/www/fog/service/ipxe on your FOG server. Now register that client with its MAC address in the web interface by hand and set option Host Kernel in the host settings to Kernel.SR.SKIP_PCI.4.8.11.64 and Host Init to init.xz. As well set Host Kernel Arguments to earlyprintk=efi.

Now get your camera/smartphone ready to take a video. Rest it on a pile of books so we get a steady picture. Best if you can capture a 60 fpm video that we can step through later on. We want to see what’s happening between loading init.xz and jumping back to the FOG menu.

@george1421 You are great! I did not pay as much attention to see this… ;-)