@jenesis

I have resolved the issue , on my Nic configuration i had more than one IP Adress set , and that confused the ssl key creation process.
Once i went back to one ip adress , the keys were created and the setup complete.

I had to install fog through Squid proxy that i have setup , just for that. Because of the way my network is built.

Hope this helps some one.
Chears

@Mr_Jay84 Just be aware that if you want to pxe boot across subnets, then you will need to add the fog server as the last server in your vlan router’s dhcp-helper/dhcp-relay service. Once you do that then you can pxe boot across subnets if you need it.

@Sebastian-Roth said in New fog installation, stopping web service failed.:

@berndttoast23 said in New fog installation, stopping web service failed.:

Thanks for your reply, I took your advice but unfortunately it produced the same result. Any other ideas?

Did you really pull the very latest version via git?? As mentioned by George this changed was pushed only a few days ago and it’s not part of the last RC version but only the very latest from dev-branch.

Thank you @Sebastian-Roth! That worked!!

It’s working ! 🙂
Thanks.

@Sunks The screen shot you provided is the end results of what happened. It doesn’t really tell us the error itself.

So here is what I want you to do.

Schedule another capture/deploy (what ever you were doing) but before you hit the schedule task button, tick the debug checkbox on that same screen. Then pxe boot the target computer. You will be presented with several screens of text that you need to clear with the enter key. Eventually you will be dropped to a linux command prompt. This is debug mode.

Now we are going to single step through the capture deployment process. The process will pause a breakpoints in the code. You will need to press the enter key to move to the next breakpoint. You want to view the partclone screen(s). The error message will be scattered about the partclone screen, typically with white text with a black background. We will need to see this error. Grab a screen shot of this partclone error and post it here.

To start the process key in fog at the linux command prompt.

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