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

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…

@george1421 You have a great point. I discussed it with the boss, and we went the path of no client on the laptops. It is a relatively small number right now that need a somewhat quick turnaround. I figure we can bang out renaming and joining manually for these. Perhaps I will investigate other methods if there is a future order or it is the direction we end up going. Thanks!

Just to be clear (I can read your request 2 different ways), fog doesn’t care about the source image or how its setup. FOG only moves disk blocks from the source computer to storage on the FOG server and then from storage on the FOG server to the target computer. How you prepair the reference image before cloning and what happens to the target computer after FOG is done is up to the IT technician. But in general terms, for MS Windows you will want to setup the computer in audit mode to perfect how you want the target computers to appear, then sysprep the reference image and power it off (using a sysprep command line option). Then you pxe boot the reference image with FOG and capture the image. On the target computer side, you register the target computer with FOG. Then you assign an image to the target computer and create a deploy task. When the target computer is pxe booting FOG will image the computer then reboot it. On the first reboot the target computer will startup OOBE/Winsetup to complete the installation on the target computer, at this point of the first boot of the target computer FOG is no longer involved with the imaging process (said knowing that if the target computer is configured appropriately the FOG client will carry out an required post install commands). There is a wiki page that describes capturing your first image that you might want to look over: https://wiki.fogproject.org/wiki/index.php?title=Booting_into_FOG_and_Capturing_your_first_Image

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

Yes SVN method has been removed, only the git and tarball method is actively supported now. https://wiki.fogproject.org/wiki/index.php?title=Getting_FOG This process is recommended for new installs as well as upgrades to existing installs.

Please also include the hardware (mfg and model) of the source image where it was take from and the hardware of where you send it to. Without a picture of the actual error we can only guess the problem is with the send to computer hardware and the FOS linux kernel.

@scosta Sorry but I don’t get what you mean by that quoting the term ClusterSSH as well. Please rephrase your question.

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.

Thanks for your time and response. Yes, any of those 3 commands didn’t work. Based on information from that topic in REAR GitHub - the user after using PXE mode, they had pxelinux config and probably as you mentioned kernel (kernel file) and maybe file system (initrg.cgz) for BIOS, not UEFI. I guess i have the same and trying to boot on UEFI system. How to determine which file is for UEFI? I guess it should be part of ISO which works fine on BIOS and UEFI system. I have this content of ISO: Then I have this content in ISO: EFI G:\EFI boot G:\boot isolinux G:\isolinux BOOT G:\EFI\BOOT fonts G:\EFI\BOOT\fonts locale G:\EFI\BOOT\locale BOOTX64.efi G:\EFI\BOOT\BOOTX64.efi embedded_grub.cfg G:\EFI\BOOT\embedded_grub.cfg grub.cfg G:\EFI\BOOT\grub.cfg grubx64.efi G:\EFI\BOOT\grubx64.efi grub G:\boot\grub efiboot.img G:\boot\efiboot.img grub.cfg G:\boot\grub\grub.cfg boot.cat G:\isolinux\boot.cat chain.c32 G:\isolinux\chain.c32 hdt.c32 G:\isolinux\hdt.c32 initrd.cgz G:\isolinux\initrd.cgz isolinux.bin G:\isolinux\isolinux.bin isolinux.cfg G:\isolinux\isolinux.cfg kernel G:\isolinux\kernel ldlinux.c32 G:\isolinux\ldlinux.c32 libcom32.c32 G:\isolinux\libcom32.c32 libgpl.c32 G:\isolinux\libgpl.c32 libmenu.c32 G:\isolinux\libmenu.c32 libutil.c32 G:\isolinux\libutil.c32 menu.c32 G:\isolinux\menu.c32 message G:\isolinux\message pci.ids G:\isolinux\pci.ids rear.help G:\isolinux\rear.help reboot.c32 G:\isolinux\reboot.c32 vesamenu.c32 G:\isolinux\vesamenu.c32

@Chad said in Not able to capture Image: My biggest pain point was letting my Check Point firewall handle DHCP. All options were set properly, however the TFTP file name was never passed to the host, so it got an IP, but didn’t know what to do next. This is what I’m thinking about the sonicwall, or its not configured correctly for dhcp options 66 and 67. Also what we find in most firewalls is that they only support static dhcp options. So with static dhcp options you have to pick either bios or uefi support. I solved this by creating a separate subnet and then letting FOG handle DHCP on that network. This is not necessary if you install dnsmasq on your FOG server. DNSMASQ only supplies pxe boot info overriding anything the dhcp server tells the client. We find most soho routers will always send the lan interface as the boot server instead of the FOG server. DNSMASQ will fix this broken behavior. If the OP has the sonicwall configured correctly and the target computer still isn’t pxe booting we have a tutorial on configuring the FOG server to capture the pxe booting process so we can see what is going wrong. Sonicwall help shows how to configure the sonicwall for pxe booting: http://help.sonicwall.com/help/sw/eng/published/1334883822_5.8.1/PANEL_dhcpStatProps.html Relevant steps are 18 == ipxe.efi and 19 == fog server IP (I know it says dns name, use the ip address here). Note you may also need to configure the generic options in step 20 for dhcp options 66 and 67. Some dhcp implementation steps 18 and 19 are configuration for bootp and step 20 is for dhcp booting. They are two different protocols.

I’m still on 1.5.6 and this doesn’t work for me. Honestly it has not worked in many iterations of FOG prior either. I usually just go into the VM and manually remove them after I delete the definitions in the GUI. Thought it was just a bug on my end.

UPDATE: Checked permissions fogproject:apache user has full rights to all snapins, why it is the apache group I don’t really know. also changed the www.conf file. No change unfortunately.

@rubencarmo Are both systems (target you pull the image from and destination PC) set to UEFI?

@Single said in Kernel Panic: A nickle (may be helpful) I don’t think that one fits here since we are not doing nfs at this time. What we really need to see is the actual error that happened just before the stack dump that we see on the screen. Possibly if you can get a slow mode video of the kernel booting process we can see what the actual error message is. I’m not sure what we can do about it because its in the linux kernel but it might give us an idea where to look.