@kaywokke Great to hear you got this working with the help of @george1421! Well done, as this is definitely not an easy one to setup if you’re still a FOG beginner.

You might want to share your code and steps in this topic to help the community. I am sure someone will find this helpful one day.

@Fog_Newb Yes.

@Junkhacker said in Live Image:

@Technolust no, this is not something fog is capable of or designed for.

Thank you @Junkhacker, I had a feeling this was the case and wanted to verify.

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

@alexthunder I reckon you got the wrong forum here. This is about FOG project (fogproject.org)…

Issue resolved over chat: The root of the issue is that something happened to the dhcp server configuration file and it was damaged. Once dhcp server config file was updated the target computers pxe booted and imaged again.

@AdamsLor said in How do I Upgrade my Fog Server?:

I have the same problem does not go away, no matter what I do

Unless your conditions are exactly like the OPs (upgrading from 1.3.5 to 1.5.7 on ubuntu 16.04, you should open a new thread. Also include screen shots of any errors you see. That will help us set the context around the error message.

I am totally geeking out hearing this! The film technology they used is also quite fascinating.

That did it jest as described. Thank you so much!!!

I found a solution. I am using WinNTsetup4 which I run from winPE and it works. I don’t know what else he does but it works so I won’t look. Thank you for helping me !

@george1421

Thank you for this response. I am looking into getting Volume licenses. If it is viable for the company I will be moving forward with FOG Project.

I see thank you for explaining that.

@Sebastian-Roth

Hell yeah dude, that cleared it right up.

@george1421 That is VERY CLEAR, thank you very much. Will reference the link and see if I can get my head around it. I appreciate your time and knowledge.

Alrighty, so my work-arounds for this issue were to use a virtual drive of 28GB to make the original image, alternatively you can delete the 4th partition to make imaging completely compatible, but you lose the ability to do an OS reset in Windows.

If you move the partition to where it used to be in v1909, Windows can’t find it and that also loses the ability to reset, so if you have to move it, just delete it i guess…

another alternative if using clonezilla you can image and use gparted to first move the 4th partition to the end of the drive, then resize the 3rd partition, this seems to work fine without losing the option to reset, tested on 2 different machines, a Clevo Laptop and an HP All in One.

Otherwise typically just make sure the drive you are imaging to with FOG is generally larger than the source disk you imaged from and everything should be fine… generally speaking…

Well first let me say there is no definitive guide on this. To put it in the simplest terms, FOG doesn’t care about the target OS. FOG only copies disk blocks from here to there and back. Now if you bring the FOG Client into scope the FOG server can reach into the target OS to do things post deployment.

With that said, if you want to get to a single click deployment with FOG (regardless of the tareget OS at the moment) you can get pretty close.

There is a process I call “Load and Go” that allows system manufacturers load a target OS on a system with just a few menu selections. System rebuilders can use this process because once the target computer is imaged the FOG server will never see (typically) this system again. In this “Load and Go” work flow the system rebuilder pxe boots into the fog ipxe menu one time by using the F10/F12 boot menu and selecting pxe boot. That target computer will then pxe boot into the FOG iPXE Menu. From there the system rebuilder will pick “Deploy Image” and then selects the image name from the list of images loaded on the FOG server. From there the process is automated by a FOG Post install scripts that prepare the target system before the first boot of the OS. These post install scripts connect to the target computer’s disk and make any adjustments to the ini or cfg files needed to prep the system for the target OS’s self installers. In this Load and Go case you don’t register the target computer with the FOG server, because the fog server will never see or need to manage the target computer after imaging. The FOG client is not installed on the target system either since there is no need to manage the computer with FOG post deployment.

As I said the FOG Client isn’t installed on the target image nor is the target computer registered in FOG. This load and go process saves on these steps and time. Because the FOG client is not installed on the target computer (it technically could be) but not registered with the FOG server, the target OS will need to have all of its configurations set before the first boot of the target OS.

So lets say in the case of MS Windows, to use this process you will need to use an unattend.xml file. That file will contain everything needed to configure the system post OOBE/WinSetup. So your fog postinstall script will need to update the unattend.xml script to properly name the computer as well as connect the computer to AD. This is one way we deploy on my campus. I can use either the “Load and Go” method or the traditional register, image, deploy, manage route. It depends on the use of the target system on how we deploy the system.

I have some tutorial on post install scripts that go over the basics and the second link is a bit more step by step to set it up.
https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script
https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed

@Sebastian-Roth - Sorry for the delay - some other unrelated issues and then a pandemic to deal with! The fix works perfectly.

@george1421 said in Surface Pro 7:

@FOG-Summacom First lets get the FOS Linux kernel information. Second if needed there is an off-line method to update the kernel.

Hello George,

again, many thanks for your support.
I have entered the proxy data in the section Proxy Settings.
After some chances into our Firwall, know I can see the Kernel Updates. ^^
Before-Kernel-Switch.jpg

On next I klick on “Kernel - 5.6.18” and see following Screen:
After-Kernel-Switch.jpg

I don’t know if I have to install the latest version now.
Is it possible to do an online update via the backend of the software?

The test Surface is at this time no longer in the company.
I will do another test as soon as possible.

Best Regards and an fine Weekend,
Ralf

@a_bains make sure you are using the instructions that say for both bios and uefi systems. https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images/15

You do need to export the ISO to the files. The only way you can get the iso to boot is via memdisk in bios mode. UEFI doesn’t support memdisk booting.

@JJ-Fullmer said in Need Powershell help:

@Jamaal I believe that the wake on lan is enabled by default, so you don’t need to do anything to include it when creating the deploy task via the api.

Ok, gotcha.

Thank you very much for letting me know of this.