@spchristy said in HP 705 G4 - rEFInd Initializing....:

My understanding is that v1.5.10 uses refind 0.11.0 ? I

Well it would be interesting to hear what version the developers released with FOG 1.5.10, I was thinking 0.11.4 was the released version. If you look at the sourceforge site they are already on version 0.14.0.2. I don’t know if that version fixed anything in relation to the HPs or not. I can say that version 0.11.4 was released in 2018 so it might not be aware of more modern hardware.

As for how you use fog, well done!!

@dvorak If this route doesn’t work I still have a trick up my sleeves.

Create a custom winpe image and boot that using iPXE. This/then would support both bios and uefi booting. The trick with a custom winpe image is that the executable need to be on/in the winpe image when it boots. I have instructions on this too, but lets see if we can get the dell delivered format to work.

@dvorak OK that iso image seems to be only a legacy/bios boot media. I would be interesting if you burned that to a CD, if it actually would boot. I also saw that cd.txt message and thought it was strange.

So when you run the dell downloaded tool It gives you the option to create an iso and .img file. You can look at the .img file using 7-zip. I would look to see in that .img file if there is a /EFI directory, if no then its bios only. You might be able to use memdisk to run the .img file too.

Were did you find the memdisk program, in /tftpboot? I don’t have a fog server in front of me at the moment so I can’t answer my own question.

@spchristy The refind code comes from another opensource project. You might want to try to see if a different refind kernel works differently.

https://sourceforge.net/projects/refind/files/

The last version of refind I knew was shipping with fog is 0.11.5, @developers please correct me if I’m wrong. You should try the latest and 0.11.0 was also known to be a solid version. With the issue with m.2 drives I might think the latest version would have better luck since it should be familiar with nvme drives.

The refind files are in /var/www/html/fog/service/ipxe directory on the FOG server.

---

On a slightly different topic of quick restore. There is an option in FOG configurations (I’ll have to look it up), to where it will only allow the defined image to be deployed to the target computer. With that set, you can use the deploy image menu from the FOG iPXE boot menu to quickly deploy the image to the target computer without having to schedule a job. You can do the redploy directly from the console of the target computer. If that helps streamline the restore process.

@dvorak OK I looked into this quickly. With the download from Dell you can create an iso image and a usb drive image (.img) file. You can probably use memdisk to boot this 32 bit image. Its small and DOS based (appears)

Something like

kernel memdisk
initrd diags.iso

Those files should go into /var/www/html/fog/service/ipxe directory. memdisk should already be on the fog server. Its either in the path above or in /tftpboot the iso needs to go in the same location as memdisk.

I have a tutorial on using FOG to pxe boot different operating systems: https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images

You can get an idea how to use memdisk in step 18 here: https://forums.fogproject.org/post/142041

@kjmchale I would add a step 5 of rerunning the fog 1.5.10.x installer once again after you upgrade ubuntu. The installer will fix any changes it detects between the two versions of ubuntu.

If it still fails we can debug more. Also remember that FOG web ui doesn’t like it when you change fog server’s IP address after FOG is installed. You can make adjustments to compensate but its just another step you need. to .

@Numa09 said in Stuck on "running post init scripts:

’ve check every thing and every where and can’t find config difereces between locations that work and the ones that doesn’t

If you want we can try to debug this.

1. Manually register this computer with FOG server if it is not already.
2. Schedule a capture/deploy doesn’t matter, but before you press the schedule task button tick the debug checkbox.
3. Now pxe boot the target computer from the failing location.
4. After several screens of text that you must clear with the enter key you will be dropped to the FOS Linux command prompt on the target computer.
5. Now we are going to see if you can first ping the fog server’s IP address. (This should succeed because you were able to pxe boot into FOS Linux.
6. Next lets create a directory so we can see if we can mount the fog server via NFS.
   mkdir /test
7. Now lets see if we can connect to the fog server via NFS (this command might/should show you the true error here.
   mount -o nolock,proto=tcp,intr,noatime "<fog_server_ip>:/images" /test Replace “<fog_server_ip>” with the IP address of the fog server. Don’t leave the greater than and less than symbols behind.

Lets see if you can mount that directory.
Also post the output of these commands after you try the mount.

uname -a
ip a s
df -h

On the fog server make sure you are not running any kind of firewall to block nfs traffic.

@Enigma said in Isolated Network Setup (Stuck in Start PXE over IPv4):

Hello I’ve DM the traffic cap

Ok that is looking much better I now see the DORA process (Discover, Offer, Request, Ack). BUT there is something missing. When I look at the ethernet header I see the next server being 192.168.107.2 (hopefully is your fog server). The boot file is undionly.kpxe (this is good), but what is missing is the dhcp options 66 and 67. So that is telling me you are missing something in the config file. You are so close to having this work.

Could you post your complete dhcpd.conf config file?

@Trep76470 A windows dhcp server should work just fine. Is it OK to guess that your fog server is at ip address 192.168.21.220?

The error message you first posted usually indicate a bios computer booting, but I don’t know leovo computers pxe boot process. Typically uefi computers would mention NBF.

Are the pxe booting computers, dhcp server, and FOG server on the same IP subnet? If yes then we can use tcpdump running on the FOG server to capture what is actually flowing down the wire.

Some things to check on your dhcp server.

1. Make sure it is responding to both dhcp and bootp requests. Both bits of information need to be in the dhcp OFFER packet.
2. If you have redundant dhcp servers, make sure you configure dhcp options 66 and 67 on both servers. Microsoft’s HA for dhcp does not copy over these settings.

If you can not find the solution then I have a tutorial here: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

Look at the results with wireshark, specifically the OFFER packet. Look to see what dhcp servers are responding to the offer packet. Then in the offer packet look at the ethernet header. You are interested in the next-server and boot-file fields. They need to be populated and match the dhcp options 66 and 67 under the dhcp options section. If you can not understand what you see in the pcap file, then upload it to a file share site and then either post the link here or DM me using fog chat the url and I will look at it.

@Trep76470

What device is your dhcp server? Is it your fog server or something else? Please tell me what is your dhcp server.

What values did you key into your dhcp server for dhcp options 66 and 67? DHCP option 66 must be the IP address of your FOG server, with dhcp option 67 unidonly.kpxe (since the error messages indicate you have a bios based computer). If you were trying to pxe boot a uefi based computer dhcp option 67 should be ipxe.efi.

Your error indicates you have a problem with your infrastructure not FOG (only based on the error message).

Final comment, the fog agent is not used for pxe booting, its only used for post image deployment actions.

@alexamore90

Our work consists in installing as many PCs as possible with Win 10 in the fastest possible way, in order to be able to fulfill as many orders as possible.

What does this mean? How many computers do you need to image per hour to make your rate. Fast as possible is not really a measurement in time.

If I had to isolate your clarification I would say you have a unit of measure conflict. So lets start with some theoretical maximums.

1GbE == 1Gb/s == 125MB/s == 7,5GB/min The number that is displayed during the partclone part of imaging is typically in GB per minute (on a well designed 1GbE network)
Note that 1Gb/s does not equal 1GB/s, its a little confusing but Gigabit is not the same as a GigaByte.

On a well designed network with a single unicast image, using a current (<5 year old) target computer I would expect you to see in the 6-6,5GB/min throughput. At this rate a 25GB target computer image should take about 4 minutes to deploy to a target computer (single unicast image).

At 6GB/min (or 100MB/s) you are almost at the theoretical maximum for a 1GbE link of 125MB/s). Meaning: you will saturate a 1GbE link if you try to image with more than 2 unicast images at the same time. Hint that 1GbE link to your fog server will get saturated first having the greatest impact on imaging speed.

the maximum speed is 16/17gbs (so he indicated to me while he was deploying)

I can understand this speed if this is 16GB/min. I’ve seen these speeds on a large VM Host server that has one or more 10GbE links to your core network using current target computers. If you want to go faster, use 10GbE networking.

You need to understand that the number displayed on the partclone screen is a composite number made of individual measurements. The number displayed in partclone includes the speed the FOG server can get the disk image from disk to the fog server’s network adapter, network transmission time, the amount of time it takes the target computer to receive the image and load it into memory, the target computer to expand the image in memory and then to write it to disk. Your target computer performance will have the largest impact on imaging time. If you have 2 computers that are exactly the same except one has a nvme drive for storage and one has a rotating disk drive for storage you will get two vastly different imaging rates because of the speed differences between the two storage medias.

If you want to image fast, have a fog server that has ssd or nvme storage, use a 10GbE core network with enterprise class switches, use multiple network links from your fog server to your network core in a lacp/lag configuration if you want to deploy multiple unicast images at one time, use current target computer hardware, consider looking into multicast imaging.

@tahitiju said in Multicast is very slow:

I try to deploy an image to some PCs but performance is very low (2MB/min) using multicast.
For the purpose of the test, FOG server (1Gb NIC), clients (1Gb NIC) and dhcp are connected together using a Linksys Switch ( 16 x 1Gb ports / unmanaged) .
Using unicast, performance seems normal (~1,5GB/min deploying 14 PCs).

A few things jump out at me with this. Multicasting can be very taxing on inexpensive network hardware. When you are getting 2MB/min how many systems are you multicasting to? Do you get the same performance when multcasting to 1 or 2 machines?

Multicast imaging moves at the speed of the slowest computer in the mcast group.

1,5GB/min is on the slow end of the scale. On a well managed 1GbE network, imaging to current hardware, I would expect about 6GB/min. If put your fog server on 10GbE network I would expect about 13GB/min. I’m only pointing it out that there might be something in your network infrastructure that is slowing things down.

A 1GbE network link will saturate with 3 simultaneous unicast deployments.

The FOG performance numbers displayed on the target computer are a composite number of how fast the fog server can pull the image off the disk, send it over the next, the client receiving the image, expanding it in memory and then writing it to disk. Any one component that is slow will impact the overall performance score.

@pastorn Are the vms on the same ip subnet as the FOG server? Multicasting packets won’t normally cross a router with a special configuration.

@Enigma yes same method as before.

@Enigma I would start with example #1 from that url. You will need to update the subnet, netmask range values so its appropriate for your isolated network. Anywhere you see the default 192.168.1.x you need to update so its appropriate for your imaging network.

@koenr said in Dell Latitude 3500:

class “LATITIDE-3340” {
match if substring(option vendor-class-identifier, 0, 32) = “PXEClient:Arch:00007:UNDI:003016”;
filename “realtek.efi”;
}

This will cause other systems to fail. There is nothing unique about “PXEClient:Arch:00007:UNDI:003016” multiple hardware will match.

Also order that the item appears in the list is important. The first match wins rule. For Dells the UUID field of the ethernet header should be unique within a model. If you use wireshark you can pick up the uuid of the pxe booting computer in dhcp option 97. You can tell if you have the right value because the first 4 characters spell DELL in reverse in ascii.

The other option if you only have a few of these devices is to use mac address matching to target specific computers with specific boot loaders.

@Enigma ok so how did you add dhcp services to your fog server (a blank dhcp config file would do exactly what you are seeing. ISCDHCP listening but not responding to any requests)? Did you add dhcp services when you installed FOG? Did you add the isc-dhcp server after fog was installed from your repo?

So you’ll probably ask what goes in that file? Look at this example: https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence#Example_1 The dhcp pool will probably need to be updated to match the subnet of your dedicated imaging network.

@Kusa555 To add on to what Tom said just remember this,

ipxe.{efi or kpxe} contains all of the common network drivers much like linux or windows OS’ contains all of the common network drivers already built in.

The undionly.kpxe only contains 1 network driver for the undi network protocol that is built into each bios network adapter’s firmware.
The snp.efi and snponly.efi only contain 1 network driver for the snp network protocol built into each uefi network adapter’s firmware.

Boot loaders that end in .pxe, .kpxe, .kkpxe are bios boot loaders
Boot loaders that end in .efi are uefi boot loaders

So what should you use?

For bios, undionly.kpxe
For older uefi system (older than 4 years) use ipxe.efi.
For current uefi systems you may have better utility from snp.efi

@typotony Hi, I can say much of the API because I don’t use it, but it seems from the quick docs on it there is a image delete function https://news.fogproject.org/simplified-api-documentation/

/fog/image/<IDOFOBJECT>/delete

A forum member @JJ-Fullmer has more skills with the API than I do.

@mdxlp Let me tell you how I debug post install scripts. At the top of the post install script I insert an echo with something notable so you can quickly identify it. And then right after insert a debugPause; command.

Now schedule a deploy task to your target computer, but before you hit the schedule task button tick the debug checkbox. Now schedule the deployment task.

PXE boot the target computer and it should drop you to a linux command prompt after a few screens of text you need to clear with the enter key. This is debug mode.

To start the debugging process in single step mode key in fog and press enter.

{sidebar} If you want to remote debug your post install script get the current ip address of the target computer with ip a s and then set root’s password on the target computer with passwd. Set it to something simple like hello. Now you can connect to the target computer using ssh or putty from a remote computer. Key in fog to start the single step imaging process {/sidebar}

The deployment script will stop at each debugPause command. Keep pressing enter until you see your echo statement you put at the beginning of the post install script. At this time if you press ctrl-c you can exit the deployment script. This will give you a command shell with all of the proper environment variables you can inspect with the set command. Running the curl command from my previous post should produce all of the fog variables.