@Chris-Whiteley I finally had some time to work on the module and created a Start-FogSnapin function that can deploy a single snapin task.

See also https://fogapi.readthedocs.io/en/latest/commands/Start-FogSnapin/

@adriand said in Anything get stuck on bzimage with random %:

I was already using the snponly.efi files and switched to ipxe.efi and it’s now working.

FWIW, with modern UEFI computers snp or snponly should work because these boot loaders use the snp network driver built into the uefi firmware. On older model uefi computer the snp driver was a bit flaky so the preference would be to use ipxe.efi on those models because ipxe.efi has all of the common network drivers. Sometimes is a balancing act to find the best middle ground for the boot loaders. I’m glad you have it worked out.

@francis-r The ipxe.efi/undionly.kpxe manages the FOG boot menu. Once you make a selection then bzImage and init.xz are loaded then its “the kernel” that is in charge. So if you have issues selecting things or entering passwords into the boot menu then its iPXE that needs to be refactored. I know I’ve recompiled ipxe in the past with an alternate keyboard. So its possible. FOG has the programs already installed to recompile ipxe all you need to do is just update the keyboard config file to use something other than US english.

Here are the instructions for recompiling iPXE using FOG: https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe you will just need to find and update the config file

@ash said in Cannot find disk on system.:

hard disk can not support pxe boot?

The technical answer is they are not connected. PXE booting uses network adapter. If I understand you correctly the old hard drive is not seen by fos linux but new hard drive is? Is it using same technology? old hard drive == sata and new hard drive == sata? Or nvme and nvme? its very strange taht swapping hard drive with same type and now its found.

@wiraport said in boot windows ISO directly:

Ive already used the method in the past to boot this files.

I think its impossible to do. Maybe an older microsoft OS but 2019 is to big.

But my goal is to help you, help yourself.

sanboot http://${fog-ip}/${fog-webroot}/fog/ISO/17763.737.190906-2324.rs5_release_svc_refresh_SERVER_EVAL_x64FRE_de-de_1.iso

I have not used SANBOOT before but I would think the URL you have defined should be an iqn path, not URL. I don’t know what the right answer is but I’m pretty sure that is not it. But I will also say I have not used sanboot for this purpose before.

Secondly this just looks wrong:

http://${fog-ip}/${fog-webroot}

I think ${fog-webroot} already includes ${fog-ip}

A quick check on this would be to call your fog server with this URL http://<fog_server_ip>/fog/service/ipxe/boot.php?mac=00:00:00:00:00:00

That will give you the text behind the FOG iPXE menu. At the very top of that script within the first few lines ${fog-webroot} is defined. By looking at the code you should be able to tell how its assigned. Also the /fog in the path is redundant because that should be already included in the ${fog-webroot} path.

Also for the url as you have it created, you need to make sure your iso file is located in /var/www/html/fog/ISO directory.

The other limitations I said before still apply. I’m only helping you fix what is wrong with your parameter block.

And finally in this tutorial you will see how to properly setup the memdisk parameter block. https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images/6

initrd nfs://${fog-ip}:/images/os/mswindows/7Pro-x64/WinPE_amd64.iso chain memdisk iso raw boot || goto MENU

Again this might not be the only way to use memdisk, but I know this method works for bios based computers. I have not tried to use sanboot for this method of booting.

@leviathan Well the easy part, is FOG doesn’t support 22.04 yet. I would stick with ubuntu 20.04 for now. Being on the branch version is the right place to be

You also need to make sure you setup things in the right order.
FOG 1.5.9.115, then update the FOS Linux kernel to 5.15.x series, then recompile ipxe.

Your problem here is when iPXE fails to transfer all of the FOS Linux image (bzImage and init.xz) the problem is either you have an old version of iPXE or you nave network communication issues.

I will try and do it today. I’m getting ready to leave for vacation over the weekend in a couple hours, so it may be on Monday.

@sebastian-roth Thanks!!!

@abulhol Thanks for looking into the error and fixing the issue via the github PR. Merge is done.

@george1421 Thanks for the info.

@sebastian-roth This fixed my issue as well…set permissions to 777 🙂 I’ll tighten here in a minute.

@rrtern Just wondering, did you create a route between the two subnets? The firewall(s) may also need rules to allow pxe, http, and tftp traffic between those subnets. I didn’t see anything mentioned about routes so that’s why I asked. For instance in pfsense, by default different VLANs can communicate with each other. But at my job’s network environment they have to create routes so that vlans and subnets can communicate.

@rlair23 I’ll raise your tutorial with one of my own: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

The next step is indeed to get a pcap of the pxe booting process. You can either use wireshark on a witness computer or for a bit more information since the pxe booting computer and fog server is on the same subnet use tcpdump on the fog server. This will collect both the broadcast and unicast messages between the fog server and target computer.

You can either look at the pcap or post it to a file share site and DM me the link in the fog project chat. If you want to look at it I can give you where to look, though it would be quicker if I looked at it because there are a few exceptions.

@rogalskij FOG uses the distribution’s tftp server. This is to ensure the services used by FOG is supported by your linux distribution vendor.

Hi there
I created a fresh VM with Ubuntu 20.04 and was able to get FOG up and running. Thanks for all your help! 🙂

@geekyjm If your old fog server was on a version pre-ssl then it may have been pretty dated. There was an older update_unattend script where you would have to put the domain join password in plain-text. Now you can use the $adpass variable that pulls from the foghost’s settings. Then the domain password isn’t passed in plaintext in any script files. So you may need to update how that password is stored on your hosts under ad settings (I believe there’s a global method in the fog settings GUI) and then try again.

I just started using the update_unattend postdownload script myself and was successful without having to have the password in plain text anywhere and the machines joined the domain.

As @george1421 mentioned there may be more going on here, as there may be some new steps needed for your fog install, but we can get this working the way you’re expecting again none the less.