Posts made by george1421

@oz-agoston said in Need help with new FOG server installation and setup (PXE, image creation):

Unfortunately our bosses wouldn’t want us to use the windows DHCP server for the FOG server to avoid possible network problems.

We have solutions you can use where you don’t or can’t update your primary dhcp server. You don’t necessarily need to setup an isolated network. Depending on your deployment your target computers may need access to AD during deployment, where an isolated network might cause a problem.

In cases where you can’t/don’t want to update your primary dhcp server you can install dnsmasq onto your fog server to provide pxe boot information only to the target computers. It takes about 10 minutes to install dnsmasq using this configuration: https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server

Now just be aware that dnsmasq (as well as dhcp) only works on local vlan/subnet because dnsmaq as well as dhcp uses broadcast messaging. So right there dnsmasq pxe boot information will be localized to the current subnet where the fog server is installed. If you want to pxe boot on another subnet where the FOG server is not, you will need to update your network’s router and add the FOG server’s IP address to the list of dhcp servers in the dhcp-helper/dhcp-relay service. This will allow dnsmasq to hear pxe booting from other subnets. One of the many advantages of dnsmasq running on the FOG server is that if the fog server is off-line no pxe boot information will be sent to the network.

@renewedharry While I can’t give you a solid answer with your issue, but someone else on the forums had an issue just recently with this software that you might be able to start from: https://forums.fogproject.org/topic/17124/i-can-t-boot-up-parted-magic-2023-08-22/2

For a mixed environment where you have bios and uefi computers, they take different bootloaders to successfully boot. Being on version 0.3 may be hurting your knowledge if FOG since SO MUCH has changed since that version was released. For bios/uefi coexistence you might want to review this wiki page. https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence

@Cire3 said in Not a Fog problem, but solution ?:

Carbon X1 Gen 7 just returns to boot menu after Downloading NBP file

Check secure boot is off and if the proper boot loader is being sent to the target computer.

You might use a witness computer on same subnet as the pxe booting computer. Use a capture mask of port 67 or port 68 or display filter of bootp Start the capture, pxe boot to error and then stop the capture. You will see the DORA process (discover, offer, request, ack/nack). Look at the offer packet this is coming from the dhcp server to the target computer. Look to see if both the ethernet header (bootp part) has next-server of IP address of fog server and boot-file as the proper boot loader name. Now confirm that dhcp options 66 and 67 are set properly. Its up to the pxe boot firmware vendor to decide to use bootp fields or dhcp option fields to locate the boot information. If you grab the pcap I can look at it for you if you get lost or not sure.

@gabrielchun The error messages says (in my words) that the kernel (bzImage) doesn’t understand the virtual hard drive (init.xz)

The image name looks suspicious to me. bzImage4152 looks like one of the custom kernels I built. At least that has the same numbering format that I use. If that is true then that is linux kernel 4.15.2, which is very old. I might understand why it can’t connect to the virtual hard drive. Please upgrade your linux kernel to very 6.0 or later. You can do this from the fog ui under fog configuration->kernel update. Understand this is bzImage kernel not the fog server host OS kernel.

@oz-agoston I agree with Gabriel check your dhcp server(s) (if you have more than one) to ensure dhcp options 66 and 67 are being sent to the target computer. PXE booting will simply not work if these values are not set on your campus dhcp server.

The next questions is if you have a screening router between the subnets (client and fog server) that might be blocking tftp.

If you could supply the actual error message created by the target computer during a pxe boot that would help us identify where to look.

@yonatan FOG doesn’t have the concept of displaying certain ipxe menus based on platform type. You can probably do this with a custom advanced menu but then you have to hand code the menu. iPXE (the bootloader that creates the FOG iPXE menu) can branch in the code based on arch or platform.

While this quote doesn’t speak to your issue, you can see how the iPXE menu item can branch based on the iPXE platform field.
https://forums.fogproject.org/topic/15984/integrate-fog-with-wds-mdt/11?_=1702084351302

You could use that concept to create an advanced ipxe menu. One other tip I can give you is that you can view how the FOG iPXE menu is constructed by pointing your web browser at the following url http:<fog_server_ip>/fog/service/ipxe/boot.php?mac=00:00:00:00:00:00

@Cire3 In general what you ask is possible. It will take a little setup to complete, but possible.

What you need to know

1. FOG has the ability to create custom FOG iPXE menu items. You will want to create a fog ipxe menu to chain to your netboot.xyz server. So you will want to build this menu first and manually select the netboot server to confirm it works (more on that in a bit)
2. If you want to manually select this menu item then you are done. If you want to default to this menu item instead of booting the local hard drive then go to the next step.
3. You can change in the fog ipxe menu builder what menu item you want to execute if you don’t select a menu item. Just change the default menu item to your netboot.xyz iPXE menu.

I have a tutorial on how to netboot installer disks so the concept of creating IPXE menu items. If you read over it you will see how to netboot alternate operating systems. https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images

Look at this post: https://forums.fogproject.org/topic/15984/integrate-fog-with-wds-mdt/11?_=1702084351302 if you need to chain to another boot loader than this will help. Specifically this section of the code.

set next-server 0.0.0.0 # Replace with WDS server IP address
...
set net0.dhcp/filename ${wds-bootfile}
set proxydhcp/filename ${wds-bootfile}
chain ${wds-bootfile} || goto Menu

You see how to populate the dhcp next server and bootfile so that the chained bootloader will think it was pxe booted natively. The other thing this ipxe menu shows you how to dynamically change the bootloader based on bios or uefi.

@Tauric said in Can't deploy/register/debug with parallels:

Also for the initrd=init.xz

That is precisely why you should not trust my memory. For a little clarity this is what boot.php file creates for the auto reg function.

kernel bzImage loglevel=7 initrd=init.xz root=/dev/ram0 rw ramdisk_size=275000 web=http://192.168.50.23/fog/ consoleblank=0 rootfstype=ext4 storage=192.168.50.23:/images/ storageip=192.168.50.23 nvme_core.default_ps_max_latency_us=0 loglevel=7 mode=autoreg
imgfetch init.xz

So the command at the IPXE> prompt would be
initrd init.xz or imgfetch init.xz There is no equals = sign in the command.

And just to tag along with what Tom said, when I first read your post I was confused if your target computers are ARM or Intel? You menitoned Intel iMac, and then a little later ARM. But I took the ARM reference as it should work because its not ARM based.

OK by setting the logging to 7 and you don’t see a bunch of text on the screen then the kernel (bzImage) is not starting up. So at the IPXE prompt I would try kernel bzImage to see if it is really transferring it. The boot command at the IPXE> should try to run the kernel.

@Tauric I have doubts that bzImage is getting transferred to this computer. I can tell you that bzImage will boot even if init.xz is not sent to the target computer. You will get a vfs not syncing error. In the fog configuration->fog settings page. Press the expand all button then search for “log” change the default log level from 1 to 7. Save the setting then try to pxe boot the target computer again. Logging level of 7 will cause the linux kernel “bzImage” to print out a lot of debugging information. That will tell us if the kernel is booting.

At the ipxe prompt you can download the init.xz file (as a test) by keying in initrd=init.xz and press enter. Lets see if we get any useful error messages.

@diegogyn said in Two VLANs (Two IP ranges):

Is it possible to configure the ipxe boot loader to try to download files from 2 different IP ranges?

Fog is not designed to have/support multiple imaging network interfaces. If this is what you are trying to do, then that is your problem. You might need to setup an additional FOG server on the vlan 3600 subnet if there are filtering rules blocking access to the 192.168.10.1 IP address.

@diegogyn You need to have full routing working between the subnets. More precisely for this error you need to be able to reach the fog server’s web ui from the 3600 vlan. It looks like you have tftp setup because fog’s ipxe boot loader is running.

@mark29 said in PXE-E32: TFTP open timeout:

it screens PXE-E32: TFTP open timeout.

This can be (most commonly) caused by either

1. DHCP options for that subnet have dhcp options 66 set incorrectly.
2. You have two or more dhcp servers on that subnet and both don’t have all of the setting needed to pxe boot.
3. The tftp service is not running on your fog server.

I would setup a witness computer on the same subnet as the pxe booting computer that witness computer will run wireshark, with a capture filter of port 67 or port 68 or use a display filter of BOOTP. Start wireshark and then pxe boot the target computer until you get the error, then stop the wireshark capture.

Now review in wireshark the OFFER packet. This comes from the dhcp server to the client.

1. Look to see if you only have one OFFER packet. You should because the pxe error is “Open timeout”.
2. Look at the OFFER packet in the ethernet header verify that both the {next-server} field has the IP address of the FOG server, and the {boot-file} has the proper FOG boot loader.
3. Now look at the DHCP options under option 66 and 67 they should match whats in the ethernet header.

FWIW: I’ve seen soho routers that eventhough you properly configure them, they set themselves (the routers) as the pxe boot server and not what you put in dhcp option 66.

@miyaqub said in Boot UEFI mode slow:

Has anyone come to a solution for this problem.

I’m pretty sure that neither the developers or myself have one of these Dell 3000 systems handy to test. So they will rely on the user community to help debug this issue.

The issue/problem with the partclone speed, is that its a composite speed of timing or the fog server to read the file off from disk, send that file to the target computer, then the target computer to receive that file, expand it in memory and then write it to the disk. Any one of the steps in the sequence can cause a performance issue.

As you have seen, a 1GbE network link has a theoretical max bandwidth if about 7.5GB/min (assuming ideal and non realistic conditions). In practice if you are getting 6.1GB/min the entire process is working as intended and very efficiently.

So if you look at the problem logically. If you setup a test, from the same network cable. Test a 7010 (or older kit) and a Dell 3000. If the 3000 is slower you can probably rule out the fog server and network infrastructure as the problem. So that leaves something inside the 3000 as cause of the slowness. So if you look at the data flow now all you have left is the target computer intake of the image, expanding it in memory and writing it to disk as the potential problems.

To try to understand where out of the 3 is the problem, schedule a task for the target computer (capture or deploy doesn’t matter) but before you hit the schedule task button tick the debug checkbox. Now pxe boot the target computer. After several screens of text is displayed where you need to press enter to clear it, you will be dropped at the FOS linux command prompt. Of the three remaining steps, you can probably rule out the expanding the image in memory as the problem. So that leaves you will network intake of the image and writing to disk. I won’t go into the steps you need but you can look at this article about benchmarking FOG. https://forums.fogproject.org/topic/10459/can-you-make-fog-imaging-go-fast

So basically you use iperf3 to test network bandwidth between the target computer and the FOG server. Then test using dd to write a 1GB file to the hard drive (note you may need to create a partition and format it for a linux file system). But those benchmark hopefully tell us where to look.

@Kram-Man Is your main ipxe server running ipxe as the bootloader or syslinux? If its truely iPXE then on the FOG server, in the tftpboot directory there is a file called default.ipxe At the bottom of that is a chain load command or chain load the default.ipxe You can look at this line on github. https://github.com/FOGProject/fogproject/blob/a4bb1bf39ac53c3cbe623576915fbc3b5c80a00f/src/ipxe/src/ipxescript#L32 Just replace ${next-server} with the IP address of your fog server.

@sgilbe I’m not seeing anything that jumps out at me as being wrong. It surely seems to fail at starting the kernel.

Are you sure you don’t have secure boot enabled on this system?

@Dietrich07 The link you posted is from an old install so there may be changes to the application in the last 7 years.

Looking at your ipxe menu parameters and comparing it against the wiki I see some differences.

kernel http://${fog-ip}/pmagic/bzImage64
initrd http://${fog-ip}/pmagic/initrd.img
initrd http://${fog-ip}/pmagic/files.cgz
initrd http://${fog-ip}/pmagic/fu.img
initrd http://${fog-ip}/pmagic/m64.img
imgargs bzImage64 boot=live ip=dhcp edd=on noapic load_ramdisk=1 prompt_ramdisk=0 rw vga=normal sleep=0 loglevel=0 keymap=us splash quiet - || read void
boot 

FWIW you are missing the imgargs and the kernel name is different. You DO need the imagargs line but I would also change the imgargs line to include the initrd file (what the kernel appears to be complaining about)

Lets see how well this parameter block works.

kernel http://${fog-ip}/pmagic/pmagic/bzImage
initrd http://${fog-ip}/pmagic/pmagic/initrd.img
imgfetch http://${fog-ip}/pmagic/pmagic/fu.img
imgfetch http://${fog-ip}/pmagic/pmagic/m.img
imgfetch http://${fog-ip}/pmagic/pmagic/files.cgz
imgargs bzImage64 initrd=initrd.img boot=live ip=dhcp edd=on noapic load_ramdisk=1 prompt_ramdisk=0 rw vga=normal sleep=0 loglevel=0 keymap=us splash quiet
boot

NOTE: imgfetch and initrd perform the same function, using it as I’ve done above makes the intent a bit easier to understand. The function is exactly the same though.

@r00s7a This is most likely an issue with your network infrastructure and not fog. The DHCP offers come from your primary dhcp server. If that DHCP server is not FOG Server then its not something you can solve on the fog server.

Where we have seen sometimes they pxe boot and sometimes not is if you have two dhcp servers on your network. Possibly in a primary / secondary configuration. Confirm that all dhcp servers have dhcp options 66 and 67 set because these settings are not replicated between windows dhcp servers.

@El-Fogito said in PXE Boot issue on second FOG-Server:

VLAN 10.20.88.0 and 10.20.82.0 (on which I configured port 66/67 from DHCP to server 10.20.10.38) finds NOTHING.

The first question is that is 10.20.88.0 fully routable to 10.20.10.38? i.e. can you ping 10.20.10.38 from the 10.20.88.0 subnet?

Do have any firewalls or screening routers that might stop udp port 67 and 68 from reaching 10.20.10.38? You can test this by using a computer on the remote subnet and trying to tftp one of the boot files from the fog server.

You are saying that you can change dhcp option 66 from 10.10.10.38 to 10.20.10.38 and the remote system can’t pxe boot. This eliminates dhcp server and possibly any router dhcp helper/relay settings from the problem.

If you have a witness computer (third computer on the remote subnet running wireshark) on the 10.20.88.0 you might setup a pcap to see what the remote pxe booting computers are being told what to load. This would ensure that the remote pxe booting computer was being told the proper values. If true then you can eliminate dhcp infrastructure issues and then deal with IP routing as the problem.

Is there any WAN links between 10.20.10.38 and 10.20.88.0/24 subnets? I have see WAN links that have a smaller MTU than the tftp block size cause a problem. I think the default block size for tftp is 1468 so if the link MTU is below that value it will case the tftp packet to fragment and then fail to download. From your error message it doesn’t sound like this is the issue, but its always good to ask.

@jleonv There are a couple of things here.

1. I would build a golden image outside of AD. You should be able to install almost all of the software as a standalone machine. As soon as you attach the golden image to AD, it will become tattooed with AD stuff. Its best to do that post deployment either by using fog or a unatted.xml script.
2. Build your golden image on a VM and use snapshots to back out changes if they mess up the golden image. You will thank me later.
3. Use the windows lite touch method of windows deployment and use an unattend.xml file to answer all of the common OOBE questions.
4. Use Microsoft MDT to build your golden image.

FOG is a block level imaging tool. It moves disk blocks from here to there very quickly. The down side is that FOG is not very dynamic when it comes to install time decisions.

MDT is a file level imaging tool. The advantage is install time changes can be made on the target computer, the down side is that it is slower to image than FOG.

@divyesh-hash Well that is strange there is no disk controller listed. Its not disabled in the bios?

I surely think we need to review that log file its either /var/log/syslog or /var/log/messages I can’t remember which. There has to be something in there that says an error about loading the disk subsystem.