@srfougere Those are things that are recorded on capture, deploy will work fine if the settings are correct (path, image type, compression, etc)

@Tom-Elliott I can reproduce his issue by enabling FOG_FTP_IMAGE_SIZE and then going to the image listing.

[Wed Mar 16 10:39:57.982297 2016] [:error] [pid 21773] [client 192.168.1.31:53632] PHP Fatal error: Call to a member function get() on null in /var/www/fog/lib/pages/imagemanagementpage.class.php on line 70, referer: http://192.168.1.154/fog/management/index.php?node=about&sub=settings

@junkhacker Interesting, I am running Centos 7 and it still works fine for me.

Is there anything relevant in apache logs?

@rocksteve69

Can you give it a try with kernel parameter nvme_core.default_ps_max_latency_us=5500 ?

Given that it connects to the DHCP server and gets an IP as we can see from the screenshot but fails after loading the IPXE file, I’d suggest serving a different IPXE boot file and see if that works.

You’ll have to modify your router DHCP settings to serve a different file (eg ipxe.pxe instead of undionly.kpxe)

@ch3i I’m literally facepalming right now, I just skipped over the options trying to rush it.

Thank you

Try the latest init files. You need to manually download those from our server. https://fogproject.org/inits/init_32.xz and https://fogproject.org/inits/init.xz

@george1421 This one is auto-built by Jenkins using the github repository, the other one was the one I made for testing, but wasn’t fully complete (missing progress update patch)

Other than that they’re identical

@rocksteve69

Once you have the init.xz you can rename it to init_partclone.xz or something and then copy it to /var/www/fog/service/ipxe

Then you can change the host init in the WebGUI at host settings to init_partclone.xz or whatever you named it.

@agray Just looked at the PCAP.

Your router is also dishing out IPs at 192.168.1.1 which is causing the conflict as suspected.

You can check it out by installing wireshark and typign in bootp as filter

If you can’t turn off or modify the router DHCP, you will need dnsmasq proxyDHCP on the FOG server.

https://wiki.fogproject.org/wiki/index.php?title=ProxyDHCP_with_dnsmasq

@Scott-B Could you check on a non-VM machine if it works? I’m not overly familiar with VM but I do know VM’s can be weird with PXE sometimes, they’re particularily picky with what network adapter will work.

@Sebastian-Roth https://github.com/FOGProject/fos/pull/24

@HG12 Hopefully new inits will be available then!

@rocksteve69 Thanks!

Looks like that version is running on Linux Kernel 5.2.9-2, potentially including some NVME fixes for certain devices.

I am compiling that kernel, hopefully that’s the only thing needed, because otherwise I am unsure where to start looking.

Will post a link here when it’s done.

@agray Good shout, I get the same problem on the ICH9 chipset, the PIIX3 one works fine though.

@Scott-B What does your /etc/default/tftpd-hpa file look like?

@Sebastian-Roth Corrected the cli as per the info given, same results however.

I am using gawk because I’m running the tests on my Centos machine and if I don’t explicitily call gawk it will run awk (which for some reason gawk isn’t symlinking too on this system) which misses out on a variety of the requirements used in the script (and lint)

Forcing a skip in the for loop at line 563 delivers the output makes it look more normal, but then the partition table doesn’t make sense since the starts aren’t properly recalculated.

My gawk version seems to be an older version than the one Buildroot has been running for a while, so I’ll see if a newer version delivers better output.

Gawk version was the issue indeed. (was 4.0.2, now 4.2.1)

New output:

# Partition table is consistent.
label: gpt
label-id: 6D7D4E9F-F276-4554-945E-D42EF1DB667D
device: /dev/sda
unit: sectors
first-lba: 34
last-lba: 1871362046

/dev/sda1 : start=        2048, size=     1083392, type=DE94BBA4-06D1-4D40-A16A-BFD50179D6AC, uuid=0E09A256-6313-43EA-9C45-1BDB234A17A3, name="Basic data partition", attrs="RequiredPartition GUID:63"
/dev/sda2 : start=     1085440, size=      202752, type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B, uuid=E004F3EB-3497-45AC-8BC2-40BF62ECF868, name="EFI system partition", attrs="GUID:63"
/dev/sda3 : start=     1288192, size=       32768, type=E3C9E316-0B5C-4DB8-817D-F92DF00215AE, uuid=B4553686-67E2-4177-BC7D-AC092860D2CF, name="Microsoft reserved partition", attrs="GUID:63"
/dev/sda4 : start=     1320960, size=   188101120, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=0005FBFB-A630-456B-9938-D501F6F70B00, name="Basic data partition"
/dev/sda5 : start=   189422080, size=  1681939456, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=5F76FA4B-76D2-43B0-8ECB-F3EB8596E490, name="Basic data partition"

By the way, @Cheetah2003 looking over the code, I think what it tries to do is assign the new size as a the same percentage as it took on the previous image if the partition is resizable. At least that’s what the intention is supposed to be.

The output here looks valid and more or less what we expect the script in its current iteration to do; but I could be missing something of course.

@Rusty Not sure how much work you already put into it, but it’s probably safer to just start over.

Also, you can only update Windows 10 to a certain point, you can’t do “upgrades” unless you exit audit mode (you can later go back into audit mode if you remove two registry files)

FOG will detect the imagetype based on what’s on the disk, not what mode the PC is running in. (though mostly it doesn’t care about it anyway)

I personally use the Virtualbox EFI image -> boot legacy PXE to capture method and it works fine.

Just make sure to choose shutdown after complete for your capture task.

@eric0626 If the PXE is located on the same server all you should need is

chain pxelinux.0

If it’s located on another server then

chain tftp://10.2.5.239/pxelinux.0

Should work.

Assuming your tftp directory is /tftpboot you will need the following:

/tftpboot/pxelinux.0
/tftpboot/pxelinux.cfg/default (<- config file)

And of course other relevant PXE files.

@george1421 There were some changes to GPT related stuff, not a lot, but some

https://github.com/FOGProject/fos/commits/master/Buildroot/board/FOG/FOS/rootfs_overlay/usr/share/fog/lib

I also think I remember a case where an existing image only started showing odd issues after updating FOG, so I’m currently leaning towards FOS, especially since I have experienced no problems on the latest Windows 10 versions at all.

So I’m guessing there’s something funky going on under certain conditions, but not sure what. Given the ambiguity it might not even have anything to do with GPT, but since those were the only relevant changes to the files currently being examined it seems the most likely path all the same.

@mlnancejr8808 You can extract the files from the exe’s with the /a command switch if I’m not mistaken.