@Tom-Elliott Also my existing images don’t seem to be deploying properly:

is it possible to roll back the update somehow?

@Tom-Elliott Hi Tom, thanks for the reply. It’s on version 1.5.10.34.

There are two VMware machines I update then capture regularly and neither seem to be working since i’ve updated FOG.

I don’t understand enough about disk operation for that bugzilla to make such sense to me haha, both drives are listed as NVME in VMwares settings. Do I disable acpi for the VM then?

I recently updated my FOG server to the newest version, ever since I get some odd errors when capturing and It never seems to complete. Would appreciate some help with this, thanks.

@george1421

Hi George, thanks for the response,

Apologies if I’m doing things wrong here, the log level was set as 4 in the fog settings, changing it to 7 doesnt seem to have done much here. Also for the initrd=init.xz it returns ‘command not found’ unless i’m entering this in the wrong place or something?

As a sidenote, the http transfers are far slower than normal in this parallels environment, I’m testing the Hirens BootCD image I have on the server and its moved the boot.wim 3% in the time I’ve typed this out.

I have found a workaround for this as parallels does let you import .VMX files from VMware, I have to assume its some kernel incompatability or something.

Thanks for the suggestions

I’m running parallels with bridged networking on an intel iMac, i’m attempting to deploy a windows image to it (successful on other machines and VM’s on the same LAN) but i’m getting the following error:

Not sure why this behaves so differently as it shouldn’t be ARM and is EFI like my vmware vm’s, I assume this is an issue with init.xz not being pulled across, but I’m not really sure why

-Tauric

@Tauric

I guess its just something wrong with this specific build of windows, I freshly reinstalled windows and setup the image again, this time it seems to be capturing the correct size

Still not sure what the issue here was, I guess fog was unable to resize the partition?

Hi all,

I have 4 images in my FOG server at the moment, they all show the correct ON CLIENT size aside from one, for some reason it is showing the size of the fixed disk that I captured from (64.01gb)

I doubt this is anything more than a cosmetic issue as images deploy fine and show the correct size after deployment, however I was wondering if there’s any easy fix for this? I tried recapturing but the size didn’t change.

d1.minimum.partitions (below) shows the Microsoft Reserved Partition as 132892160 sectors, which at 512kb per sector in gibibytes is 63.37GB.

d1.minimum.partitions.txt

The deployment looks odd as the total block progress is at a lower percentage than the data block process, it does show the actual space in use on the image as 17.1GB which is correct:

when this partition finishes the total block progress jumps to 100%

Edit: A normal deployment at part 3 for reference:

As far as I can see none of the settings are different between images.

Thanks for any suggestions

@george1421 Just got around to testing dnsmasq today, It worked flawlessly (and took less than 10 minutes lol). Thanks for the help here

@george1421 That makes sense, i’ll mark the thread as solved tomorrow if that works, the process does look pretty simple

I’m unsure as to why the Draytek router is sending the DHCP options like this, but honestly it is a bit old and they aren’t the most reliable in general haha

@george1421 I sent the pcap as is, aside from renaming it, I moved it from the ubuntu machine to an smb share on my windows box before uploading it here, I did notice the unprintable characters but I just assumed that was some issue with how the pcap was captured, I checked in the draytek and the options look fine, 66 is set as an address and the value is 192.168.0.26, not sure what you mean about the trailing character on ipxe.efi for 67.

Cheers for the advice on this, ill probably just go with the dnsmasq as suggested

Thanks for the help
-Tauric