@nerdstburns If the host is turned off and wake on LAN (WOL) works in your environment, then it will just be started automatically and do the image deployment. You can have it reboot after the task (default) or let it do a shutdown via adding shutdown=1 as Kernel parameter (general FOG settings or individual host settings).

When you use the FOG web UI to schedule a normal deployment task you see the selection:

Schedule instant (default selection) Schedule delayed (one shot at a certain time) Schedule cron-style (repeating task as often as you like it to happen, once a day or every other hour or whatever)

@vemoya Well 3 GB/s is on the bottom edge of acceptable (in my book). There may be some tuning needed to do in your infrastructure. Its not horrible just a bit slower than expected.

Just be aware with 3 ongoing unicast images you will saturate a 1 GbE link (125MB/s or 7.5GB/min theoretical max) This isn’t a fog issue specifically but a limitation of 1GbE ethernet. You can supplement this by adding additional network cards in your FOG server and then creating LAG links between your network switch and the FOG server. Even if you create these LAG links between the FOG server and switch, if your switch to switch links are 1GbE links that will become your next bottleneck. Again this isn’t a FOG issue, but a byproduct of using a FAST imaging solution. Also if you are imaging more than 2 computers at a time, its best to have an SSD or RAID array in your FOG server and not try to serve multiple unicast streams with a single spindle HDD. That single HDD will not be able to feed the data fast enough to the network adapter.

You mentioned multicasts. This is a great solution to push out one image to many computers, but it also has its drawbacks. You need to ensure your network is capable of multicast imaging (again not a fog issue). If your target computers are on the same subnet as the FOG server that is the easiest solution. You just need to turn on IGMP Snooping on your network switches and then multicast away. Just remember the slowest computer in your multicast group sets the pace for the group. But if properly setup you can multicast 30 computers in about the time it takes to image 2 computers (serially) using unicast imaging.

@wuast94 This is what I found when I was researching this issue for another poster in the forum: https://linuxhit.com/raspberry-pi-pxe-boot-netbooting-a-pi-4-without-an-sd-card/

There were a couple of other ones that I found but it appears I didn’t save the links.

@george1421 said in Clone Image Without LAN Port:

@mikmatcr said in Clone Image Without LAN Port:

What I mean is using an image captured with FOG but displaying it with Clonzilla. It’s possible?

No capture the image with clonezilla and deploy it. If you don’t have a clonezilla image, deploy with fog and have fog power off the computer after imaging. Then boot from clonezilla usb and capture image. Not clean but without a network port you are a bit stuck.

How can I put this answer as a solution and close this thread?

I don’t believe this is a Hyper-V issue. We have Fog running in a Hyper-V Ubuntu VM, with 8 CPU and 16g of ram, with no issues. The storage is backed by a hybrid disk array with 10TB of SSD accessed via ISCSI, and network is provided as 4x 40g links in a LACP bond.

Routinely see 13-15g on NVME backed clients, 4-6 on spinners, 3ish on the 5400 rpm spinners.

@dennis-porter FOG does not capture/deploy UEFI boot entries because almost all UEFI firmware out there is able to boot without explicit creation of boot entries and some firmware even has trouble when FOG would so this. So for now I don’t see why we’d add this to FOG.

Though in your case the firmware seems to not be able to find the boot partition and loader and won’t boot from it. In this case you can use Post deploy scripting to add the entry using efibootmgr Linux command included in the FOS inits.

@kaywokke Great to hear you got this working with the help of @george1421! Well done, as this is definitely not an easy one to setup if you’re still a FOG beginner.

You might want to share your code and steps in this topic to help the community. I am sure someone will find this helpful one day.

@Fog_Newb Yes.

@Junkhacker said in Live Image:

@Technolust no, this is not something fog is capable of or designed for.

Thank you @Junkhacker, I had a feeling this was the case and wanted to verify.

@Sebastian-Roth

Thanks.

I see. I decided to just uninstall the fog client and reinstall the latest and point it to the current fog server.

@alexthunder I reckon you got the wrong forum here. This is about FOG project (fogproject.org)…

Issue resolved over chat: The root of the issue is that something happened to the dhcp server configuration file and it was damaged. Once dhcp server config file was updated the target computers pxe booted and imaged again.

@AdamsLor said in How do I Upgrade my Fog Server?:

I have the same problem does not go away, no matter what I do

Unless your conditions are exactly like the OPs (upgrading from 1.3.5 to 1.5.7 on ubuntu 16.04, you should open a new thread. Also include screen shots of any errors you see. That will help us set the context around the error message.

I am totally geeking out hearing this! The film technology they used is also quite fascinating.

That did it jest as described. Thank you so much!!!

I found a solution. I am using WinNTsetup4 which I run from winPE and it works. I don’t know what else he does but it works so I won’t look. Thank you for helping me !

@george1421

Thank you for this response. I am looking into getting Volume licenses. If it is viable for the company I will be moving forward with FOG Project.

I see thank you for explaining that.

@Sebastian-Roth

Hell yeah dude, that cleared it right up.