@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.

@Dan_Ansel Ok, now that the other issue is solved and I have a bit more time we might take a look at this one again.

Though I would not trust the “size on client” value shown in the FOG web UI in all cases but if you really see the image size to be 510 GB in the blue partclone capture screen I would imagine the disk really is that big.

Please post the contents of the text file d1.partitions you find in the /images/IMAGENAME/ directory on your FOG server. That will surely give us a clue on the actual disk size.

Possibly this is just a calculation issue?! e.g. 510 GB * 1000 * 1000 / 1024 / 1024 = 486 GB?!?

@Dan_Ansel said in Size Difference after capture:

udevd [3760] failed to execute ‘/lib/udev/${exec_prefix}/bin/udevadm’ ‘${exect_prefix}/bin/udevadm trigger -s block -p ID_BTRFS_READY=0’ : No such file or directory

Where exactly do you see this message? On your FOG server or on the host/client when capturing/deploying? I have not seen this message before. At first I thought you’d see this on your FOG server logs but the more I think about it I can imagine this to be on the host/client and it might point us to something being wrong with your partition layout. Just a wild guess here.

@Sebastian-Roth Hi Seb, no problem I get it very well, you all made great job ! Keep me in touch if you need any test 😉

@george1421 ok so lets wrap this thread up nice and neat.

On the HP EliteDesk 705 G5 computers, they for what ever reason, do not like the unidonly.kpxe iPXE boot loader. iPXE undionly.kpxe will issue a dhcp request and the dhcp servers will send an OFFER packet but iPXE rejects the offer and just sends a DISCOVER packet again. And it continues over and over with the DISCOVER and receiving an OFFER but rejecting the given OFFER.

We did find that ipxe.kpxe did work correctly on these HP systems. So this kind of tells me the UNDI firmware driver in the network adapter is faulty. I’m suspecting a future firmware update will address the issue. In the mean time we had to work out a solution to send ipxe.kpxe to these computers only and send undionly.kpxe to all other bios based systems. Luckily the OP had linux dhcp servers on this subnet so we set out to see if we can identify these systems based on their UUID. Through testing unfortunately the UUID on these HP systems are globally unique instead of encoding the model and unique ID in the UUID field like Dell does. So the OP settled on identifying the systems based on mac prefix. This is the following setting we added to the isc-dhcp server on his network.

class “Legacy-hpbroken” { match if (substring(option vendor-class-identifier, 0, 20) = “PXEClient:Arch:00000”) and (substring(hardware, 1, 3) = 00:01:02;); filename “ipxe.kkpxe”; }

You are going to have to explain a bit more how FOG fits into this picture. What LAN is the fog server on?
What LAN is the FOG server’s imaging nic connected to?
Where is your main dhcp server?
Do you have full routing between the subnets?
Do you have a dhcp helper service configured on your subnet router?

@p4cm4n You can do that, there is a tutorial (for uefi) to create a boot drive the easy way. This will load iPXE from a usb stick and then boot into FOG. https://forums.fogproject.org/topic/6350/usb-boot-uefi-client-into-fog-menu-easy-way

For those that can’t use iPXE I have FOS Linux on a usb stick too. You lose about 30% of the functionality of FOG but you can image no problem with it. https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image

I’ve seen this request but not quite sure how to move forward.

Please understand, Access controls, with this iteration of FOG Server, are coded after the fact.

What do I mean by this?

FOG didn’t really have any real security controls in place. You, indeed, needed to be logged in to do actions of course, but there weren’t any utilities in place for “modifying” access.

For a period of time, there was a thing called “mobile” user which basically just allowed a user to use a mobile interface. This interface was coded along side the FOG system, and was a cumbersome tool to maintain. So when we moved to a responsive design, I removed that “mobile” gui as the new GUI is also mobile accessible.

The Access control plugin is a huge leap toward getting a tool available to limit access based on rules/roles etc…, but it’s not a perfect system as it relies on the User existing in the database first.

I’m sure we could work to add a utility to enable a “default” role association but right now it doesn’t exist.