@george1421 Thank you for all your help!

I was able to get it to boot consistently by changing some adapters on the VM.

For the capturing image issue i resolved that as well.

An error has been detected!
Init Version: 20200517
e2fsck failed to check /dev/sda1 (shrinkPartition)

The solution was to remove the capture task and replace it with a debug task. Once in debug I ran fsck on the /dev/sda1 partition. Then I changed the image to Multiple Partition Image Single Disk Non resizable in the web GUI on the fog server.

Thanks again for all your help.

That error says that partition 4 is too small. So it seems to think that the image is bigger than the spin 5’s drive.
Looking at your image settings I’d recommend recapturing using partclone zstd at compression level 19. Probably won’t fix this problem, but might speed up your imaging while saving space on the server.

I believe the when fog captures the image it shrinks it down to only what is actually in use, so your scenario should work. Personally, as a fail safe, I use a 80 GB virtual disk size for my images which never had an issue deploying to 120 GB drives. Granted after a while we found that users with 120 GB drives ran out of space just from windows maintenance (updates, caches, etc.), well that and the users never deleting an email in outlook.

So if it’s feasible, maybe try recapturing the image with the virtual drive being smaller than anything in your environment. (80-120 GB perhaps).

So this issue is resolved?

I don’t know if this means anything but if I hover of the first column it shows this.
6a935ce0-623c-4f72-8fad-d30bd7a94be3-image.png

My workaround that has worked so far was to make the source image drive small, 28GB in my case, and it seems to always work now so long as the target drive is bigger, a complication with the last partition not wanting to be any closer to the beginning of the drive as it was on the source disk (i think), but it can be further away with no issues:

https://forums.fogproject.org/topic/14571/imaging-windows-10-v2004-with-uefi-gpt-partitions-onto-31gb-or-smaller-drive-and-failing/3

Correct, it is uploading properly now. Thanks for the assistance!

@JYost are you registering all of the hosts? How are you setting the preferred names? The way I did it was I set names as I registered, and then did an image deploy right there during registration from FOG’s boot menu, typically. I don’t know how much experience you have with FOG but Tom is right, naming and domain joining should work 100% of the time. If it’s not, something isn’t right and we need those logs to help.

its working, thank you!

@george1421 said in Wrong Partition is mounted during deployment. (FOG 1.5.7.56):

@Greg-Plamondon You might want to update your partition detection script to the one used here:

#!/bin/bash . /usr/share/fog/lib/funcs.sh [[ -z $postdownpath ]] && postdownpath="/images/postdownloadscripts/" case $osid in 5|6|7|9) clear [[ ! -d /ntfs ]] && mkdir -p /ntfs getHardDisk if [[ -z $hd ]]; then handleError "Could not find hdd to use" fi getPartitions $hd for part in $parts; do umount /ntfs >/dev/null 2>&1 fsTypeSetting "$part" case $fstype in ntfs) dots "Testing partition $part" ntfs-3g -o force,rw $part /ntfs ntfsstatus="$?" if [[ ! $ntfsstatus -eq 0 ]]; then echo "Skipped" continue fi if [[ ! -d /ntfs/windows && ! -d /ntfs/Windows && ! -d /ntfs/WINDOWS ]]; then echo "Not found" umount /ntfs >/dev/null 2>&1 continue fi echo "Success" break ;; *) echo " * Partition $part not NTFS filesystem" ;; esac done if [[ ! $ntfsstatus -eq 0 ]]; then echo "Failed" debugPause handleError "Failed to mount $part ($0)\n Args: $*" fi echo "Done" debugPause . ${postdownpath}fog.copydrivers # . ${postdownpath}fog.updateunattend umount /ntfs ;; *) echo "Non-Windows Deployment" debugPause return ;; esac

This one uses a bit more intelligence to find which partition actually has windows on it. I think your script is just picking the last partition and calling it good enough.

ref: https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed

Thanks, That fixed it!

@Sebastian-Roth

Now that I have the necessary MAC addresses at least associated with the machine I am good for now. I will wait for a final release before I move. This isn’t a deal breaker kind of issue for me.

@Trev-lchs said in HP 250 G7 fails to upload image:

This is now resolved, on checking it appears that the kernel downloaded was the ARM64 instead of 64.

Interesting the ARM kernel gets as far as that on a HP 250 G7…

@NSD_Network_Admin @neodawg Just in case anyone of you is interested in this. The bug was fixed by this commit: https://github.com/FOGProject/fogproject/commit/66fa6f074c4662098ea38b811077f2ad25c09a46#diff-f21fb2470403477fe0c412911d1227f1

@EZY4 I think we both have different problems.
I would suggest that you open a new thread on this.

As a tip: Install VirtualBox + ExtensionPack and set up the network boot only.
VirtualBox has iPXE, which gives you more information.

Furthermore you can use wireshark to check what exactly your machine receives from the dhcp-server.

@george1421 Good to know. Thanks for the information and help!

I actually brought my laptop in from home, this I know is a uefi BIOS, on testing it, it booted into Fog with no issues ( it has been imaged in the past with FOG. So i then knew that UEFI boot was working. I have to hold my hands up on checking the HP 250 G7 it had not had secure boot switched off in the BIOS, this is a silly error and for this I blame my technician lol, (well i should have checked myself) on checking this morning i saw it was still on, I was lead down the FOG path after the kernel update failed. however i now have a different issue which i shall post.

@george1421 Yep thanks for your help George, we have it pixie booting now, unfortunately, on checking it this morning the Tech had not switched secure boot off in the laptop bios. due to the other issue i had been having i thought it was FOG, FOG is blameless in this instance.

@george1421 I was able to edit the Grub.cfg and add our Fog server IP in and then boot with USB and register and capture and deploy. Thank you again for all the help.

It’s completly dumb i just didn’t created the image entirely so i couldn’t upload anything ^^"
But thanks anyway for your help and your work !

Issue solved, yet we have now version 1.5.9 RC and there is new problem with node offline