Works like a charm! Thanks george1421!

@AlexPDX said in Storage Group and Storage Node explained for dummies:

1.5.8 keep remembering the Windows Keys in the Host

Yes that info is stored in the database. With that said, the upgrade should not erase keys. If it does then there is a bug in the upgrade script. AFAIK nothing is ever deleted from the database during an upgrade. A schema change will add or remove fields but not data.

@Hubi i’m pretty sure there’s references on how to do it on the forums, but here’s how i’ve done it in the advanced menu. it will take just a little modification to put this into the ipxe menu entries instead, but it should give you a pretty good idea of where to start

:Win7SP1x64 kernel bzImage root=/dev/ram0 rw ramdisk_size=127000 ip=dhcp web=${fog-ip}/fog/ consoleblank=0 loglevel=4 type=down img=Win7SP1x64 ftp=${fog-ip} imgType=n imgPartitionType=all osid=5 storage=${fog-ip}:/images/ capone=1 imgfetch init.xz boot || goto MENU

@Tom-Elliott Thank you for your input. I realize that i have made a mistake in the code. I am new to bash and fog in general.

The idea is to have a while loop running until an image has been assigned. Or a sort of pause before it continues. The reason being that this is being done remotely and I would be assigning the correct image to the host. I am not psychically in front of the computer. The hosts users would only select that they want an image to be deployed and not select an image to deploy.

Hope that makes sense.

So what I guess I was looking for and I do realize that this is n the wrong thread is a way inside a while loop to see if an image has been assigned before continuing on with the deployment. BTW I have modified the fog.man.reg to go straight to the fog.download and the end of the registration.

True that, George. I was just surprised, as I had a few different USB-to-Ethernet adapters provided to me at work and none of those would work, and many Google searches solidified the suggestion that there were only a few USB Ethernet chipsets (chip manufacturers, chip-somethings, whatever) which were supported by PXE.

The search was made more difficult in that even in the last few years (2016-present) people seem to continue to prefer Legacy booting over UEFI. If I ever decide to get the other device, I’ll let you know how it works so it can also be added to the list, if that’s something you guys are keeping up.

IMHO spinning up a fog server from scratch takes out a lot of variables that may cause issues. The install script for FOG is quite streamlined these days. Though I am a vmware user, I find that templates and pre-builts save you literally just a few minutes at the cost of many potential issues, especially since network environments vary so much.

i was able to locate instruction. https://wiki.fogproject.org/wiki/index.php?title=Migrate_images_manually#Image_Definitions

please mark this question as answered.appreciate your quick response.

Hi Guys

Two quick updates on this:

This ipxe7156.ipxe also seems to be working for some Dell machines we have.

To make Hyper-V Generation 2 VM’s to PXE boot UEFI correctly; I had to add a new PXEclient mapping of PXEClient:Arch:00007:UNDI:003000 for the ipxe7156.ipxe boot file. (Secure boot should also be disabled!)

(Tested with FOG 1.5.2)

Revised Powershell Code:

import-module dhcpserver $DHCPserv = "DHCP-SERVER-HOSTNAME" Add-DhcpServerv4Class -Name "PXEClient (UEFI x64) 2" -Type Vendor -data 0x505845436c69656e743a417263683a3030303032 -Description "UEFI Architecture Type 2" -ComputerName $DHCPserv Add-DhcpServerv4Class -Name "PXEClient (UEFI x64) 6" -Type Vendor -data 0x505845436c69656e743a417263683a3030303036 -Description "UEFI Architecture Type 6" -ComputerName $DHCPserv Add-DhcpServerv4Class -Name "PXEClient (UEFI x64) 9" -Type Vendor -data 0x505845436c69656e743a417263683a3030303039 -Description "UEFI Architecture Type 9" -ComputerName $DHCPserv Add-DhcpServerv4Class -Name "PXEClient (UEFI x64) 7" -Type Vendor -data 0x505845436c69656e743a417263683a3030303037 -Description "UEFI Architecture Type 7" -ComputerName $DHCPserv Add-DhcpServerv4Class -Name "PXEClient (UEFI x64) 7 UNDI 3016" -Type Vendor -data 0x505845436c69656e743a417263683a30303030373a554e44493a303033303136 -Description "UEFI Architecture Type 7 UNDI 3016 (Surface Pro 4)" -ComputerName $DHCPserv Add-DhcpServerv4Class -Name "PXEClient (UEFI x64) 7 UNDI 3000" -Type Vendor -data 0x505845436c69656e743a417263683a30303030373a554e44493a303033303000 -Description "UEFI Architecture Type 7 UNDI 3000 (Hyper-V)" -ComputerName $DHCPserv Add-DhcpServerv4Policy -Name "UEFI-IPXE" -Description "UEFI IPXE" -ScopeId 0.0.0.0 -Condition OR -VendorClass EQ, "PXEClient (UEFI x64) 7*","PXEClient (UEFI x64) 9*" -ComputerName $DHCPserv Add-DhcpServerv4Policy -Name "UEFI-IPXE32" -Description "UEFI IPXE32" -ScopeId 0.0.0.0 -Condition OR -VendorClass EQ, "PXEClient (UEFI x64) 2*","PXEClient (UEFI x64) 6*" -ComputerName $DHCPserv Add-DhcpServerv4Policy -Name "UEFI-IPXE7156" -Description "UEFI IPXE7156" -ScopeId 0.0.0.0 -Condition OR -VendorClass EQ, "PXEClient (UEFI x64) 7 UNDI 3016*","PXEClient (UEFI x64) 7 UNDI 3000*" -ComputerName $DHCPserv Set-DhcpServerv4OptionValue -PolicyName "UEFI-IPXE" -OptionId 67 -Value "ipxe.efi" -ComputerName $DHCPserv Set-DhcpServerv4OptionValue -PolicyName "UEFI-IPXE32" -OptionId 67 -Value "i386-efi/ipxe.efi" -ComputerName $DHCPserv Set-DhcpServerv4OptionValue -PolicyName "UEFI-IPXE7156" -OptionId 67 -Value "ipxe7156.efi" -ComputerName $DHCPserv Set-DhcpServerv4OptionValue -OptionId 67 -Value "undionly.kpxe" -ComputerName $DHCPserv Set-DhcpServerv4OptionValue -OptionId 66 -Value "10.20.30.40" -ComputerName $DHCPserv

@agray there are muc more uptodate versions of this done by @george1421 collaberating his version and mine which i’d suggest looking over but for just osid replace if statement with this:

case $osid in 5) osn="Win7" ;; 6) osn="Win8" ;; 7) osn="Win8.1" ;; 9) osn="Win10" ;; esac

Tutorial By George

@x23piracy
The following thing I’m taking a shot at (shoot for the moon, right?) is to utilize FOG to have Snapins and make them available outside of the LAN, that’ll at that point pull down some powershell to get records by means of HTTPS from our web group to do remote establishments if necessary. I have a proof of idea working, yet I’m a 1 man shop and haven’t had sufficient energy to do considerably more on it. In any case, in the event that it works, I’ll viably have the capacity to push introduces both on and offsite, without utilizing DirectAccess as the tie back. The powershell has a few if’s in there to check whether they’re on the LAN, which will then instruct it to snatch PDQ’s bundles, however on the off chance that they’re off, it’ll get them from the HTTPS store and shoot msiexec on them physically.
Dafont 123Movies FileHippo

@Sebastian-Roth Thanks for seeing this. I have been meaning to update this post. I noticed the change when I upgrade from Proxmox 5.1 to 5.2. I have added a new post that hopefully will help.

@sudburr To do some of this you will need to become versed in grub menu design. Some can be done in grub. The deploy image function in grub is not so easy, that requires the integration of iPXE menus (which we avoided by creating a usb based tool). You can get pretty close but with static grub menus (as apposed to dynamic iPXE menus when you pxe boot).

Thanks Sebastian. I was able to get my local debian mirror setup and working. I had to pass a bunch of kernel options over to get things started. Here is my boot option.

:Debian95Full kernel http://${fog-ip}/bootimgs/debian/oldIso/install.amd/linux preseed/url=http://10.0.0.3/preseed.cfg ksdevice=bootif netcfg/link_wait_timeout=10 netcfg/dhcp_timeout=60 netcfg/choose_interface=auto auto-install/enable=true priority=critical hostname=unassigned-hostname domain=unassigned-domain console-setup/layoutcode=us console-setup/ask_detect=false locale=en_US ipv6.disable=1 initrd http://${fog-ip}/bootimgs/debian/oldIso/install.amd/initrd.gz boot || goto MENU

Also here is a good tutorial for having your own Debian repository mirror if anyone else stumbles upon this topic
https://www.tobanet.de/dokuwiki/debian:debmirror

We recently had an issue where the time zone wasn’t being set correctly/updating on imaged machines. We edited the registry with a script on those machines to set the correct time zone.

@nextechinc said in Booting System Rescue CD 5.2.2:

cpuid --ext 29 && set arch 64 || set arch 32
set path /netboot/systemrescuecd
set nfs_path /var/www/netboot/systemrescuecd
kernel http://${fog-ip}${path}/isolinux/rescue${arch} docache setkmap=us
initrd http://${fog-ip}${path}/isolinux/initram.igz
imgargs rescue${arch} initrd=initram.igz netboot=http://${fog-ip}${path}/sysrcd.dat setkmap=us dostartx
boot

Thank you so so much. I was struggling to get the SystemRescueCD to work at all, now it works 🙂

I think I used some tutorial on here or wiki somewhere and my paths were different, I had to use

path /srcd

And had to change the paths in kernel and initrd to

kernel http://${fog-ip}${path}/rescue${arch} docache setkmap=de

and

initrd http://${fog-ip}${path}/initram.igz

As well as imgargs to:

imgargs rescue${arch} initrd=initram.igz netboot=http://${fog-ip}${path}/sysrcd.dat setkmap=de dostartx

This may be my specific setup being somehow messed up, but in case somebody else has the same setup as I do …

I put in a shebang. It should work now, please re-download the install file.

@andrewg78 What I want you to do is start a new thread.

I want you to pxe boot the target computer using FOG 1.5.4 and the post a clear screen shot of the exact error. Lets work through why its not working on your hardware there.

@mpatel If you look towards the bottom of the thread the drivers on the fog server go into /images/drivers (you will need to create the drivers directory because its not fog standard.) Below is the basic structure of the directories needed.

/images ├─/drivers ├─Optiplex7040 ├─win7 └─x86 └─x64 ├─win10 └─x64 ├─Optiplex7050 ...