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.

@Sebastian-Roth

Thanks. I was looking in app data and the registry. LOL.

I just wanted to change the IP address that points the FOG client to the FOG server.

Hello,

Where are the settings for the FOG client stored in Windows 10?

Thanks

@Mr_Jay84

Hello,

Yes, I use Windows for DHCP but you can do it with Linux DHCP too. I made ipxe.efi the default boot file. Then added a scope policy for vendor class PXEClient:Arch:00000 to use undionly.kkpxe Yes 2 k’s

I used this as a guide

https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence

I am trying to figure out how to do this on my ubiquity exr so I can stop using Windows.

@Sebastian-Roth

Hell yeah dude, that cleared it right up.

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

@george1421

I can try that later this week. If manually setting acpi=off in the host configuration kernel parameters field works then wouldn’t that mean the kernel parameter field for groups does not work?

I wish this place would get rid of those awful DC 7800’s

I mistakenly reported I was able to successfully image a DC7800 by adding the host to a group that had a kernel parameter “acpi=off”. It turns out I was mistaken. It was a DC7900.

The DC7800 can make it to the fog menu and successfully register. However, when trying to deploy or capture I get this

NO GROUP

IN GROUP with “acpi=off”

Is there another kernel parameter I need to use?

In the mean time, I had to install an older kernel in order to image it.
Tom Elliot 64
bzImage Version: 4.15.2

Thank you

It is not happening anymore. The VM is only 18GB. It takes less than 10 minutes to capture and less than 10 minutes to update FOG. Or visa versa.

The only weird thing I have since noticed is during the install process, when are asked to go to fog/management and hit update database, that page no longer shows up. It just displays the fog login screen. So I just go back to the installer and hit ENTER. It seems to work fine.

@Sebastian-Roth

Ok, I deleted my fogproject folder to make sure I got the newest stuff

git clone https://github.com/FOGProject/fogproject.git /opt/fogproject
cd /opt/fogproject
git checkout dev-branch

Ran the installer/upgrader and captured an image from the VM.
All good!

Thank you

d1.partitions.txt d1.fixed_size_partitions.txt d1.minimum.partitions.txt @Sebastian-Roth

Hello,

It is possible it could be the same thing that is happening there. There weren’t any errors during the capture process.

It seems that capturing the image damages the working Windows VM. However, the image that is captured from it is fine and can be restored no problem.

I tried 3 times in a row. Setting up a rather standard Win10x64 VM . Each time I captured and image from the VM, it would not longer boot into Windows properly.
I will upload those files that were requested in the other thread.

[2_1588487227132_d1.partitions](Uploading 100%) [1_1588487227132_d1.fixed_size_partitions](Uploading 100%) [0_1588487227130_d1.minimum.partitions](Uploading 100%)

Thank you guys. I have now got the latest RC 1.3 and found a problem. I made another thread about it.

Hello,

I have noticed a problem after updating to 1.5.9-RC1.3.

After capturing an image from a Windows 10x64 VMWare Workstation 15.5, it borks the VM. It can no longer finish loading the desktop for the default user. Restarting the VM usually ends up in the Windows frowny face or a Windows repair in which it can not be repaired.

However the image it captures is good. If I deploy the newly captured image to a new VM or onto the same one everything works fine.

I was able to duplicate this 3 times in a row.
Is there more information I could provide to help determine what the cause is?

Thank you

The web interface tells me the latest dev-branch version is 1.5.8.34