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

Xen defaults to BIOS though in 8+ you can switch to EFI and I’m pretty sure new versions of ESXi default to EFI. Can you confirm which you have on each?

@robertkwild said in creating an image container for windows server 2012 r2:

so for normal cloning i can use “single disk resizable”?

Please read this: https://wiki.fogproject.org/wiki/index.php?title=Managing_FOG#Images

If you don’t need to deploy to a smaller size disk you might consider using this image type as it’s less likely to cause an issue and image size on the server is still as small as with resizable image type.

@lacazet2k said in Laptops for home , advice ??:

will they still be able to pull an image while out of the local network

The short answer is NO. They must be connected to a network where pxe booting is enabled as well as be in full communication with the FOG server. FOG doesn’t support one-off imaging off site.