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

@george1421 Thanks, I really appreciate your help!

@mkeane Using USB boot. Start looking into this here: https://forums.fogproject.org/topic/6350/usb-boot-uefi-client-into-fog-menu-easy-way

@fatbunny I think I would take this approach. Recreate your master image using the smallest disk possible. Make sure the root lvm volume is the last one allocated on the disk. Capture with FOG it will still capture as RAW. Then using a post install script that detects either the image name or linux issue the LVM commands to extend the lvm volume to the size of the (new) disk and then extend the root lvm volume to the size of the lvm disk. Its a bit strange on how to handle it, but it should work.

The basic idea is to create your source image as small as possible then expand it post deployment.

I know this is kind of old, but I had this same issue yesterday. I fixed it by running the installer and upgrading.

I think it would have been fixed by simply re-running the installer if I didn’t have to upgrade. I was only one version behind. I’ve notice most issues with Fog can be fixed this way.

I just figured out that sending stuff out with the image doesn’t work as well as one would like. None of the fog hosts seem to be working and the like. I try to make it grab the new image off one of the clients and it doesn’t actually grab them.

What do you mean by this? Do you see anything in the C:\fog.log on the clients? Or are you saying that they aren’t imaging correctly?

For that example snapin, if you’re just wanting that file to show up in C:\users a simple snapin pack. I’d take a look at the link @george1421 gave on snapinpacks and make a zip with a script that copies that file to C:\users.

As a simpler test you could create a powershell or batch script that just makes a hello world text file and see if that works.

i.e. powershell

"Hello World!" | Out-File -encoding oem -filePath C:\users\public\Desktop\hello.txt -force;

So put that into a file called hello.ps1 and make a new snapin with the Powershell template and upload the simple script. The snapin read-only command at the bottom should look like this
powershell.exe -ExecutionPolicy Bypass -NoProfile -File hello.ps1
Then add it to a host and deploy it as a single snapin task and see if it works.
You can deploy it then if you have access to the host you can run this in powershell to open up a dynamic version of the fog log to watch what’s happening on the client

cat C:\fog.log -wait ##cat is an alias for get-content. You can also do this with Get-FogLog if you install the FogApi powershell module

@george1421 Yeah, I think having a FOG server at the 3 locations is probably the logical option. Which weirdly enough building those out and ongoing support would still be significantly cheaper than the ongoing subscription we have with SmartDeploy.

@george1421
Thank you very much, thats all i need to know.

@Julien-asv I’m glad you have a working path. Yes you will need to get in contact with your network admins to enable port-fast on every network port that you need to pxe boot from. This is a common error when people leave the default settings enabled on their network switches. So we have seen it before that is why I had you try the “time fixed it” path for debugging.

I didn’t have time to test the rEFInd downgrade yet but found a workaround for the issue with the missing boot entry in the BIOS.

Rebuilding the BCD obviously solves the “problem” (which only HP BIOSes have).

Recovery process in short:

Boot to recovery console Assign drive letter to EFI partition rename old BCD (\EFI\Microsoft\boot\BCD) bcdboot c:\Windows /l en-us /s [Assigned letter]: /f ALL

Still I’m wondering why this is an HP only issue.

Edit: I’m almost sure that “bcdboot C:\Windows /addlast” will also do it but currently do not have a victim to test upon.

@Chad said in Not able to capture Image:

My biggest pain point was letting my Check Point firewall handle DHCP. All options were set properly, however the TFTP file name was never passed to the host, so it got an IP, but didn’t know what to do next.

This is what I’m thinking about the sonicwall, or its not configured correctly for dhcp options 66 and 67. Also what we find in most firewalls is that they only support static dhcp options. So with static dhcp options you have to pick either bios or uefi support.

I solved this by creating a separate subnet and then letting FOG handle DHCP on that network.

This is not necessary if you install dnsmasq on your FOG server. DNSMASQ only supplies pxe boot info overriding anything the dhcp server tells the client. We find most soho routers will always send the lan interface as the boot server instead of the FOG server. DNSMASQ will fix this broken behavior.

If the OP has the sonicwall configured correctly and the target computer still isn’t pxe booting we have a tutorial on configuring the FOG server to capture the pxe booting process so we can see what is going wrong.

Sonicwall help shows how to configure the sonicwall for pxe booting: http://help.sonicwall.com/help/sw/eng/published/1334883822_5.8.1/PANEL_dhcpStatProps.html Relevant steps are 18 == ipxe.efi and 19 == fog server IP (I know it says dns name, use the ip address here). Note you may also need to configure the generic options in step 20 for dhcp options 66 and 67. Some dhcp implementation steps 18 and 19 are configuration for bootp and step 20 is for dhcp booting. They are two different protocols.

@ricardomartins So you are using the FOG server for dhcp services? If so then its already configured for dynamic pxe booting between uefi and bios. There is nothing else you need to do then.

@george1421 said in Change FTP on fog server to SFTP??:

So that means FOG would need to compile lftp for the FOG host server during install. I have not checked the lftp from FOS Linux but we would also need to ensure that lftp in FOS supports ssl too. We have a bit more control of FOS Linux support of ssl than the FOG Host server.

From my point of view FTPS (FTP with SSL) is no better than FTP from a firewall/network/security point of view and I wouldn’t spend a second on trying to make this work.

If we really think about making this part more secure I would want to push this down the SSH/SCP/rsyncOverSSH way instead! I have not looked into this yet but I could imagine we can make this work for 1.6.x some weeks down the road.

I think he’s asking for a default role via the access control plugin. @Fernando-Gietz any thoughts on that?