@victor-r Interesting… there must be some other code that is doing that. Rerun the fog installer to put things back.

Just to be sure I’m looking in the right area, you are trying to replicate your images from the FOG server to the windows storage node or are you trying to capture directly to a windows storage node?

@sebastian-roth not really, there are a few references to the same problem, and only one person said they were successful by taking the undionly.kpxe file from a debian 10.4 installation.

I will complete this image on a physical machine, it not a big issue. It is just super convenient when working remotely that’s all.

Thanks for taking to time to reply.

Zufar

@bluedude For a longer term solution I would implement the dhcp policies from the document Sebastian provided. That solution will help you when you have a mix of bios and uefi systems on your campus.

BUT for a test right now, replace undionly.kpxe with snponly.efi then try to pxe boot that troubled target computer. Understand when you move away from the bios boot loader the bios systems will fail to pxe boot. But what we are looking at right now is/does snponly.efi resolve uefi booting on this troubled computer. Once you find out then put back the undionly.kpxe file until you can get the dhcp policies setup. I can tell you they do work because I have them setup in my environment.

@vemoya All I can say you get what you’re paying for.

Create a new iPXE menu that looks similar to this.

Menu Item: os.chainwdsimaging
Description: Boot WDS Imaging Solution
Parameters:
cpuid --ext 29 && set warch x64 || set warch wx86
iseq ${platform} pcbios && set bootfname wdsnbp.com ||
iseq ${platform} efi && set bootfname wdsmgfw.efi ||
chain -ar tftp://10.254.0.155\\boot\\${warch}\\${bootfname}
boot || goto MENU
Menu Show with: All Hosts

The script parameters looks a bit complicated but it basically checks to see if the target is x86 or x64 and uefi or bios to pick the right location and file name to boot.

Understand that for pxe booting there is two methods and it appears you are using both in your setup.

There is the static mode where you define dhcp options 66 and 67 listing statically the boot server and file name to use. In your case your dhcp server looks like you have policies defined to switch between uefi and bios boot files this is good.

The second method you are using is called proxy dhcp this is where you add your pxe boot server (WDS or FOG running dnsmasq) to the last host in your dhcp-helper service on your router. Both WDS and FOG running dnsmasq will respond with the proper boot file when it hears a dhcp discover from the target computer (this is why you have it listed in the dhcp helper service). The proxydhcp server (WDS or dnsmasq) will only provide the pxe boot information leaving your main dhcp server to provide the rest of the boot information. If you have a proxydhcp server configured its settings will override the static settings you have defined in dhcp options 66 and 67.

The reason why I’m telling you this, if you don’t stop the proxydhcp service on WDS it could respond to proxy boot requests giving you a random boot experience. Its ok to have static and dynamic assigned boot files, just know that proxydhcp will override static settings, when you can’t figure out why things are working as intended.

Be aware I did not test the script above only wrote it on the fly without much thought. YMMV

@george1421

That appears to have resolved it! Thanks!

@george1421 Hello, tsc=unstable worked! Thanks. Since some of the computers don’t belong to our campus, and just come here to be reimaged, I tried to apply that parameter in the settings in all clients and it didn’t give us compatibility issues with more modern systems (I tested for example in HP Elite 8200’s and it worked perfectly).

Thank you for your assistance! 🙂

@Vango The upper picture shows the new FOG version 1.6 we keep working on since a long time, mostly it’s @Tom-Elliott’s great work.

The version is confusing as the work in this branched off at around FOG 1.5.7 and has not been updated to 1.6.x for some time as it was still a very early alpha version not quite ready for production. It’s great to hear you have been using it for a year now already! We are still working on it and hope to release an official 1.6.x in the next months.

You can get the current stage of it as we work on it by checking out the branch working-1.6.

Let us know if there is anything that needs fixing.

@brakcounty While I can imagine an upgrade to break things in rare cases I would not think this would happen for a service like ISC-DHCP which has been around for so many years. But hey, you never know. Everything is possible.

@wmw509 Give the steps outlined by George a try but I can imagine this being caused by some fancy logic within the UEFI firmware. As George said FOG is not at all touching any firmware or boot settings… unless you have added post deploy scripts doing something special.

Here is another test: Schedule the deploy task as debug. When you get to the shell run efibootmgr command (don’t know if you need parameters or not from the top of my head) and take a picture of the output in screen. Now start the task with command fog and step through it. At the end run efibootmgr again, take a picture and compare/post here. Before you type reboot schedule another debug task for this machine and see if it PXE boots into it.

Ok lets hit the common things here.

What exactly do you have configured for dhcp option 67? I’m going to guess the computer is in uefi mode so dhcp option 67 needs to be ipxe.efi.

Ensure that secure boot is disabled

Not an issue at the moment but will be.

Make sure the disk mode in the bios (firmware) is configured for ahci mode not the default of Raid-On.

Ensure you update the FOS Linux kernel via the web ui by going to FOG Configuration -> Kernel Update. Make sure you download both the 64 and 32 bit kernel for 5.6.18. You will need this kernel to support the newest hardware.

My bad!! Disregard the last. I had changed to ipxe.efi in scope section only … not sever options. Fixed that and it’s booting to Fog now.

Thanks so much!!

@george1421 Sim, bem esquisito mas esta funcionando, so registro que nao esta funcionando corretamente neste caso ate troquei para BZImage412.

@bluedude Thanks for the update. Unfortunately I have not a clue what could have been wrong with those disk that kept your machine form even booting up. No idea really. Looks pretty alright in the pictures.

@Piplup said in Proofread concept:

I discarded the VLAN idea because it’s too late to implement safely now for me.
You’re right - there is 1 L3 10 Gigabit Switch and A lot of L2 1 Gigabit Switches
My question was, is a network as described with the network plan I provided realistic?

I worried that because everything is in one LAN (192.168.5.0/24), and the ISP router is effectively the DHCP Server, that this may lead to broadcast storming or other fatal performance loss in the network because every Client has a dynamic IP.

No worries for the number of hosts. With tcpip there is not really an issue with broadcast storms. If you are using an old lan technology like netbeui, spx, or banyan vines then broadcasts would be a concern. With TCP the main type of broadcast are ARP messaging (in general).

Regarding the HDD - it’s supposed to be 2 SAS HDD’s in RAID 1, because these are the only harddrives in the paper server. So effectively 1 HDD. I know 200 Mbit’s is much, I’m still debating in changing it to 2 SSD’s. I was just worried they would break faster.

One HDD or 2 in Raid-1 same difference since only one is the leader disk an the other is the mirror or follower disk. If you are using a traditional RAID controller then the onboard cache memory will help a bit with performance. But remember you are dealing with multi GB files for imaging so the cache will only help so much. In regards to SSDs, for FOG imaging they will not break faster than HDD. What breaks SSDs is many writing to the drive. In the case of standard fog imaging its a write once, deploy (read) many times. SSDs are ideally suited for FOG imaging. I would say the HDD would have a shorter life because of the head thrashing about the disk when you have multiple imaging going on at the same time.

Last thing regarding the Bottleneck … So, the image server cannot deploy faster than his own read speed and the write speed of the Client, right?

Here are actually the bottlenecks in imaging. Lets assume a deployment here server->client

FOG Server disk to network Network infrastructure Network to fog imaging Fog imaging to disk

In the case of a FOG deployment, the fog server does very minimal work. On the FOG server it only moves data from the disk storage to the network adapter and then manages the overall progress of imaging. If you wanted to you could run the FOG server on a Raspberry PI 4 server. The key is getting a fast data path from disk to the network.

For fog imaging the target computer does all of the work. The target computer takes in the image from the network, decompresses the image dynamically, and then writes the image to the local hard drive on the target computer. So impacts on deployment speed is network, CPU (Ghz and number of cores), memory speed, and local storage drive.

So if you were to setup FOG and deploy to a computer the program that writes the image to disk is called PartClone. PartClone gives a performance number. This is usually in GB/min. This number is actually a composite number that indicates how fast Partclone can write the image to disk. But behind that number is all of the defined bottlenecks. Lets say you take 2 computers one is a 2010 Core2 Duo with a HDD and the second is a 2019 Quad Core with an NVMe drive. Using that same FOG server the Core2 computer will probably deploy in the 4GB/m range (bottleneck is CPU or local HDD). Where that Quad Core with NVMe drive will deploy in the 6.5GB/min range (bottle neck is the 1GbE network)

@init32 said in Need help for a test setup:

Your (client) IP address: 192.168.1.229
****Next server IP address: 192.168.1.1
Relay agent IP address: 0.0.0.0

Above is the problem with soho routers they put themselves as the pxe boot server. This is where we use dnsmasq to override this poor behavior.

Well done getting it setup!

@AlexPDX When I looked at this on the smartphone earlier today it did not load the second picture and so I misunderstood the issue. The master nodes sends a HTTP request (URL http://x.x.x.x/fog/status/freespace.php?path=/images) to the storage node to get that information. The storage node checks if the given path exists, is readable and a directory. If not it returns no values.

So your link /images -> /home/fogproject/images is causing the issue. Linking can be somewhat hideous and I would never advice anyone to link to the images directory just to mask that it was setup the wrong way in the first place.

I suggest you move all the content from /home/ to a temporary location, re-mount that partition (/dev/mapper/centos-home) into /images and move all the stuff you had in /home/fogproject/imagesover to the new/images` (residing on the extra partition.

WOW that solved it.
changed it from tftp to http and instantly see gigabit transfers.
thanks for your help @george1421
also noteworthy to make sure your files are moved over to the default http directory of /var/www/html

@dgcortes While I haven’t been following the thread, I see what is common in a setup if you are not watching.

The /root partition has 45G allocated to it (where the /images default to) and /home has 435GB. The /home is never used in a FOG setup so you have 435GB wasted space.

@xardoniak
I was using Ubuntu 18 Server install, but I was able to get it working like this.

I created a /images/os/ubuntu folder and copied the ubuntu ISO file contents in there.

I created a folder /tftpboot/os/ubuntu
There I put the initrd and vmlinuz files from the casper folder in the ubuntu iso.

Here are the parameters I used in FOG.
kernel tftp://192.168.160.12/os/ubuntu/vmlinuz
initrd tftp://192.168.160.12/os/ubuntu/initrd
imgargs vmlinuz initrd=initrd boot=casper root=/dev/nfs netboot=nfs nfsroot=192.168.160.12:/images/os/ubuntu/ ip=dhcp rw
boot || goto MENU

This allowed me to start the installer from that usb, but I haven’t got a working live OS running yet, though I hope to have that soon.

@xubohead Do you mean language support in FOG software or here in the forums?

FOG already has Chinese language pack included but I am not sure how well the translation is made. In the forums we don’t seem to have anyone understanding Chinese and so we prefer English. But sure you can use online translators and post your request both in Chinese and English at the same time. This way we have the best chance of getting all the details. Our answers will be in English.