@hillie Yeah, that’s probably the best information we have. Check it out and let us know if you feel it needs an update. You are more than welcome to give detailed feedback on what to improve on the documentation.

I guess you wanna try out the PrinterManagerHelper as well. Though I have to say that it has not had much attention lately and I remember it giving inadequate information sometimes (in case of WDS port configuration, maybe?).

@phamdien said in Win7 64 bits imager:

I know I have to update the Kernel for 64 bits but I do not want loose 32 bits Image.

Why do you think you loose the 32 bit image when you update FOG to a more recent version? The image data won’t be upgraded to 64 bit or anything no matter what you do.

I suggest you setup a fresh clean new FOG server using the most current version beside your old FOG server. See if you can set things up so you can switch between the both (mostly depends on your DHCP setup) and when you have it running properly you can move your image(s) from the 0.32 server over to the new one and keep your fingers crossed for them to still deploy. They really should and if they don’t we can still try to help and fix things in the most current version.

@MikeT That question is a bit broad. Can you make FOG duplicate the SID, yes don’t sysprep the image before you capture it with FOG. Does FOG specifically duplicate the SID, no. Fog doesn’t care about the target OS. It just copies disk blocks from the source location to the target location. It doesn’t really step into windows.

So to answer your question a bit more directly. No the quality of your golden image determines if the SID is duplicated or not.

@Sebastian-Roth

Yes.

I just want to add real quick, the DC 7800’s can boot to the menu with any kernel and without and kernel parameters. They fail when deploying.

@tigervince30 Good you found the second DHCP server. I had a feeling this would be caused by a stale DHCP server in your network.

Thank you. That was very helpful. I’m still working on it.

Screen shots and configuration settings might help with diagnosing the issue.

Just to round out this thread, this is the final configuration steps to get this service pack up and running. In the end I did need the iso image to try to reverse engineer what it was trying to do. If you want to test this configuration on a VM make sure you use the E1000 type nic or the booting kernel may not see the network adapter.

HPE SPP2019120
1.First we’ll create the required directories:

mkdir -p /images/os/spp mkdir -p /tftpboot/os/spp

2.Now we’ll mount the SPP2019120 installer over the loop directory.

mount -o loop -t iso9660 /{full path where you have the iso stored}/SPP2019120.2019_1219.1.iso /mnt/loop

3.Finally we’ll copy the pxe boot kernel and intfs to the tftpboot directory. Then unmount the iso image and move the iso image into place.

cp /mnt/loop/pxe/spp2019120/vmlinuz /tftpboot/os/spp cp /mnt/loop/pxe/spp2019120/initrd.img /tftpboot/os/spp umount /mnt/loop mv /{full path where you have the iso stored}/SPP2019120.2019_1219.1.iso /images/os/spp/SPP2019120.iso

4.The last bit of magic we need to do is setup a new FOG iPXE boot menu entry for this OS.
5.In the fog WebGUI go to FOG Configuration->iPXE New Menu Entry
Set the following fields
Menu Item: os.HPE.SPP2019120
Description: HPE 2019120
Parameters:
kernel tftp://${fog-ip}/os/spp/vmlinuz
initrd tftp://${fog-ip}/os/spp/initrd.img
imgargs vmlinuz initrd=initrd.img media=net root=/dev/ram0 splash quiet hp_fibre showopts TYPE=MANUAL AUTOPOWEROFFONSUCCESS=no iso1=nfs://${fog-ip}/images/os/spp/SPP2019120.iso iso1mnt=/mnt/bootdevice iso1opts=nolock,ro
boot || goto MENU
Menu Show with: All Hosts
6.That’s it, just pxe boot your target system and pick HPE 2019120 from the FOG iPXE boot menu.

In the syslinux kernel parameters for this iso image there was to groups of kernel parameters. In the syslinux menu there was a manual method and an automatic method. During the development of this process we only tested the manual method. The manual method uses these kernel parameters as show above.
TYPE=MANUAL AUTOPOWEROFFONSUCCESS=no

The automatic method uses these kernel parameters.
TYPE=AUTOMATIC AUTOPOWEROFFONSUCCESS=no AUTOREBOOTONSUCCESS=yes
If you want to use the automatic method (I have no clue what that means) replace the manual kernel parameters in the iPXE menu with the automatic parameters. Be careful to not replace too many bits because the HPE SPP seems to be a bit fussy with what it expects in the linux kernel parameters.

With this setup in place you can use the same tftp boot infrastructure to boot into any of the HPE SPP iso, now by just adding the iso image to the directory and copying the iPXE menu configuration to a new entry while updating the iso name in the iPXE menu.

@danieln The DNS IP the FOG installer asks about is only ever used when you let FOG setup the DHCP stuff for you. It is used to hand the DNS server IP to all the clients when booting. It’s just what pretty much any DHCP server does, tell clients where the default gateway and DNS server is.

@nockdown snapins are programs (think ms office) that you will install post imaging. By putting those on a different partition than the root, you reduce the risk of filling up the root file system and bringing down the fog server.

@FuriousGamer065 Now if you were going to do 50 or more per year I would recommend a bit different approach in that you will create a fat image and include all of the applications you need right in the golden image. You would only install applications post imaging that require a system unique ID like enterprise virus protection. You would also use the unattend.xml file to answer all of the preinstall OOBE questions so the deployment is completely lite touch. https://forums.fogproject.org/topic/11920/windows-10-1803-sysprep-problem?_=1584219461172 You would also create a post install script to install the system specific drivers etc.

@nockdown Haven’t tried it myself but I would think yes, shouldn’t cause an issue. Give it a try and let us know.

So the answer depends. How many end user computers will have the fog client installed on? How big (computer wise) is your campus? For a small site FOG will run on a Raspberry Pi3, but that doesn’t scale well.

Most systems we would start out with 2 vCPU and 4GB of RAM. For the host OS disk 50GB and then I would recommend creating a second disk just for the images and a 3rd if you plan on having a lot of applications deployed by the fog server. The reason for independent disks for images and snapins is that you can expand a dedicated disk easier than the disk your root filesystem is on that is used by your linux OS. That is a bit deeper of a subject than what does fog run on.

@clarkjohnken The FOG web UI should not be pinned to a specific interface or IP (unless you have HTTPS enabled). So you should be able to configure an IP to eth1 and simply open the web UI with that new IP.

Though this is just from the top of my head. I have not tested this myself yet.

sorted it out, i had to enable port fast on the cisco switch for the port(s)

the reason it took ages to get a dhcp address is because when port fast is disbaled it takes 30 seconds for it to give it a lease address

@Gabor said in Distributed computing:

just installed FOG for imaging computers

Ok I was under the impression that you installed FOG for netbooting. So then if you have FOG installed for imaging then you can continue to use it for both imaging and netbooting since everything you need is included with FOG for imaging as well as netbooting.

If you want to run off the shelf OS by netbooting I have a tutorial on that and how to integrate with FOG here: https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images

The buildroot approach is a bit more complicated but you an end up with a really fast and tight system. To build a custom linux OS using buildroot you will need to use a linux computer and to download the buildroot dev environment from here: https://buildroot.org/ I suggest that you watch a few youtube videos on buildroot to see if its right for you.

If you want to start by building FOS Linux init.xz image you can start with the data on the github site: https://github.com/FOGProject/fos/tree/master/Buildroot The github repo won’t mean anything to you unless you understand a little bit about buildroot. But with the board/FOG/FOS file path, those files will be copied to the target disk image without changes. The files in that path are placed in the init.xz initfs. Really the files in this path make the image FOS. The packages directory is for custom applications you want complied and installed in the target init.xz file. Again watch a few youtube videos to understand what buildroot is and what it does to decide if you want to go down this path.

@Sebastian-Roth Here’s the output…I will try re-imaging with non-resizable

2431b554-1bb4-45a3-99ca-733ce5639589-image.png

@Sebastian-Roth this is my lab. I have this server as a Samba DC as well

I think they just return the exitcode of whatever it is you’re trying to snapin.