@mikael1909 While I haven’t tried these specific boot disks. I don’t read russian at all, but it looks like these boot images are windows pe based. You should be able to get them to boot.

What have you tried so far?

What errors do you see? If you post a picture of the error it might help debug the problem.

@hernani First I would recommend that you update your version of FOG. you are on 1.5.9RC2. I would at least go to 1.5.9 or even better once at 1.5.9 switch to the dev-branch and move up to 1.5.9.111.

If you use the git method to install FOG then just switch to the /root/fogproject directory and do a git pull command then switch to the bin directory and rerun the installer ./installfog.sh script again.

After that if you want to upgrade to the dev-branch you can issue these commands.

cd /root/fogproject git checkout dev-branch git pull cd bin ./installfog.sh

That might not take care of this issue, but at lest if you are on the latest release the devs can help you.

Typically when we see this problem at the end of capture with an ftp error message its because someone changed the fogproject linux user account or password. The memory exhaustion issue might be addressed in the update. I know I’ve seen this error before quite a while ago.

@george1421 thanks for the quick answer.

I’m aware that the power of FOG is in the multicast deploy. But I have to say that I tested it with 25-30 capture tasks in parallel, and if you have the hardware+infrastucture, it works like a charm
I already have the registrations, image definitions, groups etc., but I won’t do it on scheduled basis, only on manual basis.
My only problem is the lot of clicks which I have to do, if I want to do it manually:) That’s why I asked this question here.

I will have a look at the Powershell API, it will probably/hopefully solve my problem

Thanks!

Yepp, I have the same problem, I see the status only after a few minutes, when the text gets “streched”. If there is a solution, it would be nice to know:)

We have an “easy” solution for this. We are using a NAS (a Syno in our case) to store the images, and we enabled the recycle bin. When the image is overwritten by FOG, the old one goes in to the recycle bin of the Syno (#recycle). Depending on the filestore size(we have around 32TB), number of hosts, size of the images and the size of the recycle bin, you can have the “history” for a few days.
The images are renamed in the #recycle of the Syno(e.g. d1p4_1.img or d1p4_5.img) and if you need an older image, you just copy it back, and rename it.(e.g. d1p4.img )
We can go back in this way, for 5-6 copies, in your case it would be 5-6 days.
I hope it helps.

@george1421 said in Mixed driver environment:

Talk about worked like a champ!
Wasn’t sure if recompiling would cause more headaches, or not.

We have been trying to find a way to get UEFI to play nice, we didn’t find your post from Nov 2…

@george1421, THANK YOU!!!
!SOLVED!

@brakcounty Well done!!

Where I also see value in this is if someone wanted to hard drive boot into iPXE then from iPXE into the hard drive or FOG without using PXE booting. Instead of a usb drive, everything could happen off the efi partition on the local hard drive. It would not solve the secure boot part of it, but its an option.

Also lets say someone wanted to setup a preboot menu (such as for dual booting) using refind. Your idea could be tweaked slightly to boot into refind menu manager and then pick to boot windows, linux or something else from the refind menu. There are a number of options this method opens up. Again, well done!

@sebastian-roth Thank you for the response! I’m assuming I should keep EXT4. I haven’t updated this thing in a while. I was planning to take a snapshot first but wanted to have a little better clarity. I’m running 1.58 so I will also update to 1.5.9 as well.

Resolved by running the command udp-sender start then i restarted the Fog machine as ubuntu

@pcrispim So if on the fog server you navigate to /var/www/html/fog/service/ipxe/ and key in file bzImageB851 what does it report?

@90amper Nice fix. Well done!

@tesparza Its good we can point our finger at low memory as the problem. The small cache space on 4GB is only left 800MB of room so mysql had to commit everything to disk instead of caching it for later. (speculation) I did find it surprising that in the previous top screen shot, you had 4GB of swap space but none was used even when the system was low on ram. It wouldn’t have really helped in your case, but I find it strange that no swap space was used.

Now that you found an acceptable level you can start decreasing your fog client check in time till you find a happy balance between speed and frequency. The only issue I can think of by keeping the check in time to 5 minutes would be during post imaging if the fog client was used to rename the system, connect to AD, or do a scheduled reboot. Its possible the client computer wouldn’t react to the command for about 5 minutes.

@Fogger2021 Sure this is an issue caused by FOG? Please take a picture of the error on screen and post that here in case the answer to my question is a yes.

@electronico_nc Well lets start off by saying this. FOG Images have 2 parts. There are the raw files that are stored in the /images directory and the meta data that is stored in the database. You have the raw files so rebuilding the data will take some work, good guessing, and a bit of luck.

Just recreate your image definitions by hand as you did in the beginning. Be sure to name them exactly what they were before. In the example above the image name and directory name is almost always the same. So name this image win7_64 (watch your case). Fill out the rest of the settings as you would normally do. One could guess that this image is a windows 7 so you will need to select that in the OS field. If you did not name all of them as clearly, be a good guesser to see what OS it is. The compression values are only used on image capture so you should just guess what you might have used. Just do this for each directory in the /images folder.

The only (not a gotcha, but something to be aware of) is that on the image list view the image size will be zero. This is because the image size is set at capture time only. Since you are side loading these images that field will be zero until you recapture the image.

@madeyem Thanks heaps for testing again and letting me know! As well thanks for your patience.

@btoffolon The fog-client (FOGService) is run as local SYSTEM account.

Sorry guys, the issue was that this particular unit had 2 hard drives, so selecting single disk was the issue.

All good now.

Wiki is also edited.

@wt_101 If I can suggest you look at this post: https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed

it gives you an idea how to do this with windows. You can use the same concept, except for maybe look for the partition that has an /etc directory.

Here is a bit older script that shows a few different techniques. https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script