SOLVED

I was on 18.04 and ran “sudo do-release-upgrade -d”, It finished, I rebooted and was able to access the FOG web interface and deploy an image. I am running the latest stable version: 1.5.8

UPDATE: I had some issues when I upgraded to 20.04 on a different FOG box. It has been resolved.

Thanks

@Sebastian-Roth

Not sure if this has been resolved or if this helps -

I’ve created a Win 10 UEFI VM using the 2004 ISO. VMware Workstation 15 Pro 15.5.6 build-16341506. All the settings were default except I went up tp 8GB of RAM. I installed it, ran all the updates, activated it while waiting for updates, rebooted twice then captured the image with FOG dev-branch version: 1.5.9-RC2.11 running on Ubuntu 20.04 LTS

It deployed fine to a similar VM.

@Sebastian-Roth

Yes.

I just want to add real quick, the DC 7800’s can boot to the menu with any kernel and without and kernel parameters. They fail when deploying.

@Sebastian-Roth

Hell yeah dude, that cleared it right up.

@Sebastian-Roth

Cool an even newer version is out now. Gonna try 2.19

@Sebastian-Roth

I don’t know. The Win 10 UEFI image on the FOG server at work and a completely different Win 10 UEFI image on my home FOG server both deployed and worked fine the day before. Nobody else has access to either FOG server and the only change made was the update from RC2.15 to 1.5.9-RC2.17

@Sebastian-Roth

Sorry I am not explaining this well.

I was able to resolve the situation by creating a new UEFI image from a legacy image and capturing it. The original UEFI based image that got corrupted is not working.

@Sebastian-Roth

The Windows 10 EFI image is just the legacy image converted to EFI

Since the Legacy image was still working fine I deployed the legacy image, converted it to EFI then re-captured it replacing the broken Win 10 EFI image

@Sebastian-Roth

Yes that update was installed on both images.

The odd thing is it only affected the EFI image(s) not Legacy one and the same behavior on 2 different fog servers and 2 different images that deployed fine prior to the FOG upgrade.

But yeah who knows. It was easy to sort it just seemed related to the upgrade at the time.

I updated my home server and a server at work. Today at work, I noticed a once working Win10 UEFI image would not longer boot to the desktop properly… even deploying it to the same workstation it was captured from.

The image was captured a couple of days prior on 1.5.9-RC2.15 and had been deployed a few times without any problems. The problem only happened after going to 1.5.9-RC2.17.

This was easy to resolve since we have the same exact image in legacy, I deployed the legacy image then converted it to UEFI and re-captured it as the broken UEFI image. … tested working.

I just figured oh… the image got corrupted due to… something else. I was too burnt to look into it any further.

I got home and tried to deploy a completely different Win10 UEFI image that also was captured and deployed on 1.5.9-RC2.15 and since updating to 1.5.9-RC2.17 the same exact weird behavior. The desktop never completely loads. Task manager never opens… etc etc.

The image is close to stock so it is easy to recreate. I’m wondering if anyone else experienced this.

@gadams

From the latest pics in the post… The Fog server…
Seems hard drive related for sure. Problems mounting the file system and other issues related to the file system.

@george1421

I can confirm those mixed kernel versions work fine. We also have dc7800’s they can make it to the FOG menu but they can’t register, deploy or capture with the newer kernels.

When I first encountered DC7800 problems I rolled the kernel way back to one even older than 4.15.2 and I would get an error message saying kernel was too old at some point during the DC7800 registration process.
4.15.2 was the first kernel I came to where it didn’t throw the kernel was too old error.

With 4.15.2 I have been able to image, capture, etc etc all different kinds of laptops and workstations via legacy and UEFI PXE boot without any problems.

Once the DC7800’s are gone I will go to the latest kernel. I hate those things.

I am thinking there is some corruption with the captured image maybe even a bad sector on the FOG servers hard drive?. Just a guess but definitely not the kernel.

what is up (PTM) @gadams

Has the default setting for snmysqluser been changed to ‘fogmaster’?

@Sebastian-Roth

Thanks.

I see. I decided to just uninstall the fog client and reinstall the latest and point it to the current fog server.