@rmishra1004 Thanks for reporting. We have another user but I wasn’t able to replicate the issue yet and didn’t get the information needed to find what is causing this. Cross linking the topics so we keep track of this: https://forums.fogproject.org/topic/14160/image-size-on-client-incorrect Can you please post the contents of the text file d1.minimum.partitions here in the forums. You find that on your FOG server in /images/Win10LTS/ folder.

@TaTa said in Download speeds slow after upgrading to 1.5.8: On the web UI at the login window it says Latest Version:1.5.7, Latest Development Version:1.5.7.120 and on FOG Configuration page says “You’re running the latest alpha-branch version: 1.5.7.958”. Should all be 1.5.8 or later? Sorry for that. There were some minor issues in the version checking on our webserver. Fixed that just now. Thanks for letting us know. Ok, back to the issue. So turns out the slowdown is not between 1.5.7 and 1.5.8 but has been there with FOG 1.5.7 but only in UEFI mode. That an interesting one because at that stage I would expect there to be no real difference between UEFI and legacy boot. The Linux kernel uses a so call EFI stub for it to be loaded in UEFI mode but as far as I know should behave more or less the same after bootup either way. Sure there are differences like EFI VARs (/sys/firmware/efi/efivars) only being accessible in UEFI mode but I would think that most drivers should not see the difference. Please make absolutely sure this is happening on the very same machine (not just same model) and confirm.

@dmoseley Can you verify the behaviour is different depending on the image you deploy to the exact same machine? I would expect BIOS version and/or settings to make the different. Or it’s model specific.

Perhaps share how the custom task was created, what you’re trying to achieve etc so others can weigh in with suggestions? Above is not really much to go on. regards Tom

@Sebastian-Roth https://imgur.com/a/j0WJInw

@Mark-Shelton Thanks for the information. Please let us know if compilation works fine adding the wget commands as mentioned below. We shall add this as a bug fix soon.

@Kiweegie Thanks for sharing your solution! Without having put in much though I’d probably just force a redirect from http://hostname/ to http://hostname/fog/

@Sebastian-Roth I was hoping for a completely new one. Mine is less of a script and more of a realm join in a bash file

@quicklet said in Using FOG client to image MacOS: Also, is there anywhere (a wiki, etc) where I could have the steps written for initiating the imaging process for mac? Schedule the task in the web UI and PXE boot the Mac. It’s as simple as that.

@anwoke8204 said: it attempts to pass off to the hard drive, but it doesn’t, just goes back to the fog menu I am wondering on what happens if you switch from PXE boot back to just plain boot from disk? Does it boot Windows 10 properly then? I have tried both bios and uefi. and I get the same issue. What exactly to you mean by that? Did you play with the exit type settings for both in the web UI or did you switch the BIOS/UEFI firmware settings on the host? If you played with the firmware settings on the host I am really wondering if your image is UEFI or legacy BIOS? You can’t have a pure UEFI image and boot that on a legacy BIOS only machine or vice versa. Which exit type is set in the web UI? Have you tried all the different ones like SANBOOT and so on? Be aware there is a global setting for exit type as well as a per host setting.

These issues are typically related to how the structure is on the disk and where the data is placed. Its not really a fog issue, but an issue how the reference image placed on the golden image disk. This is important especially if your golden image is constantly recycled as you apply round 2 (through N) updates and applications. The ideal method is to rebuild your golden image every time as you upgrade your golden image. So how to fix… Make sure your C: drive is the last partition on the disk. This may require you to move or delete the recovery partition. The recovery partition is a non-resizable and sometimes non-movable partition. I also question the value of a recovery partition if you have an imaging solution in place. It is much quicker to just reimage the computer than to try to recover a failed disk. If you have done many updates to your golden image (especially over time) flush out all of your temp files and defragment the hard drive. This will (should) push all of the files towards the beginning of the disk. The idea/goal here would be to move all of the disk data below the size of the disk you will be deploying to. That makes FOG’s disk compression work a bit easier. If you are developing a golden image create that golden image on the smallest disk possible. Its is easier to expand the disk than it is to shrink it. So if you developed your golden image on a 120GB SSD, that image would deploy cleanly to 120GB disks and larger, for example.

@joanmarzo Only a real FOG Server can run the fog replicator service. Marking the nas as a master node allows it to capture and deploy images. If you want image replications to other servers you will need to setup something outside FOG to move the images. Remember I said this configuration is NOT supported by FOG but can kind of work.

I found the smart installer for 11.19 :) Now it works on http. We will try to activate https on our server and activate https on the client

@jhumpf Have you tried the scripts? Can we mark this closed or do you need any further help with this?

@Sebastian-Roth - I will try these things when I get into the office on Monday morning. I believe that I have the 1903 image that was working prior to this last batch of windows/software updates that I can get the data from.

@Robotic said in Where is the .mbr file?: As you can see in the screenshot i added that one arg pertaining to nvme latency. That wouldnt affect the image capture process would it? No, shouldn’t cause this issue. What jumps at me in the file listing is this: /images/HP-9480: total 15882304 drwxrwxrwx 2 root root 4096 Feb 6 10:11 . drwxrwxrwx 7 fogproject root 4096 Feb 6 09:36 … -rwxrwxrwx 1 root root 2 Feb 6 09:24 d1.fixed_size_partitions -rw-r–r-- 1 administrator administrator 1048576 Feb 3 08:58 d1.mbr ... Two things: The name in the listing is different than in the picture: HP-9480 vs. HP9480 The file is owned by a user called administrator. Seems like someone messed with this image. No idea why d1.mbr is missing in /images/HP-9470 directory!?!

@astrugatch Yeah, probably a good idea. We’d need to do extensive testing on this. E.g. iPXE boot, fog-client, storage nodes (php curl calls) and so on. PS: Moved to feature request.

@SBrady Looking at your pcap, you have 3 servers responding to the bootp request from your target computer. It appears the real dhcp server is at the .181 address and the 2 proxyDHCP servers are at .44 and .45. Both of the proxyDHCP servers are overriding what your main dhcp server is telling the target computer for where to get the boot file from. I can’t tell from the proxyDHCP response what type of computer it is. The response doesn’t look like a Microsoft SCCM or WDS response because it is so short. I would focus on what .44 and .45 are and why they are responding to the bootp request. Edit: Looking a bit more into the pcap there is also a WDS server responding to the DHCP DISCOVER query at the .217 address. That makes a total of 4 dhcp (and proxy servers responding) overriding what the main dhcp server was sending for dhcp options 66 and 67.