Best posts made by quinniedid

@george1421 @Sebastian-Roth I just discovered the solution to this issue.

Back a while ago we had HP Z400 workstations that required us to put a global kernel argument of “ahci = off” as they would fail to deploy an image without it. The reason we made this global as it did not have an impact on any other devices and I would not have to specify it specifically on every workstation. The oddness of this all, when the VM was running in BIOS this was not an issue with capturing the image with the SCSI controller. When the VM was UEFI it would fail and would require us using the SATA controller which slowed capturing to be almost a 2 hour process. Removing this kernel argument now allows us to capture an image at full speed again using teh SCSI controller and it fixed a hang issue that occurred in the beginning that was also previously reported with the “can’t find IRQ”.

All in all this is now fixed removing that kernel argument. I am just shocked that it would be affected differently between BIOS and UEFI specifically on a VM.

Thanks for all your help.

@Birgit-Godfrey

We are an all HP environment so we have found that 0.11.0 rEFInd is required for all of our machines to boot. We also have to change in the refind.conf that Sebastian mentioned is the line scanfor netboot,internal to scanfor internal

You might want to try some of the things mentioned in this post: https://forums.fogproject.org/topic/11993/refind-pxe-booting-issue/

@Jonathan-Cool I find it very interesting that a SYSTEM account will work on Windows 7 but not Windows 10. One thing I would like to see is doing the same thing with PSExec running as the SYSTEM account and once you have that command window open change the directory to where you usually have the drivers dumped to. Run the xcopy from the NAS. I would be curious to see the behavior difference between Windows 7 and Windows 10.

Also, can you capture a screenshot of the security permissions of the folder specially on Windows 10 that the drivers are dropped into? Something like this:

@Sebastian-Roth Yes it does return. I even see a ton of data being downloaded. I have cut off the data towards the end due to the length of the capture.

563	13.682607	10.86.96.177	10.85.195.199	TCP	74	50514  >  8080 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=1729539897 TSecr=0 WS=128
569	13.742557	10.85.195.199	10.86.96.177	TCP	78	8080  >  50514 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 SACK_PERM=1 TSval=400875488 TSecr=1729539897 WS=64
570	13.742594	10.86.96.177	10.85.195.199	TCP	66	50514  >  8080 [ACK] Seq=1 Ack=1 Win=29312 Len=0 TSval=1729539912 TSecr=400875488
571	13.742693	10.86.96.177	10.85.195.199	HTTP	161	CONNECT fogproject.org:443 HTTP/1.1 
575	13.801898	10.85.195.199	10.86.96.177	TCP	66	[TCP Window Update] 8080  >  50514 [ACK] Seq=1 Ack=1 Win=771008 Len=0 TSval=400875548 TSecr=1729539912
576	13.864407	10.85.195.199	10.86.96.177	HTTP	105	HTTP/1.1 200 Connection established 
577	13.864424	10.86.96.177	10.85.195.199	TCP	66	50514  >  8080 [ACK] Seq=96 Ack=40 Win=29312 Len=0 TSval=1729539942 TSecr=400875608
579	13.87112	10.86.96.177	10.85.195.199	TLSv1.2	583	Client Hello
582	13.992592	10.85.195.199	10.86.96.177	TLSv1.2	1414	Server Hello
583	13.992609	10.85.195.199	10.86.96.177	TCP	166	8080  >  50514 [PSH, ACK] Seq=1388 Ack=613 Win=771008 Len=100 TSval=400875738 TSecr=1729539944 [TCP segment of a reassembled PDU]
584	13.992616	10.86.96.177	10.85.195.199	TCP	66	50514  >  8080 [ACK] Seq=613 Ack=1488 Win=32128 Len=0 TSval=1729539974 TSecr=400875738
585	13.992893	10.85.195.199	10.86.96.177	TCP	1414	8080  >  50514 [ACK] Seq=1488 Ack=613 Win=771008 Len=1348 TSval=400875738 TSecr=1729539944 [TCP segment of a reassembled PDU]
586	13.992908	10.85.195.199	10.86.96.177	TCP	166	8080  >  50514 [PSH, ACK] Seq=2836 Ack=613 Win=771008 Len=100 TSval=400875738 TSecr=1729539944 [TCP segment of a reassembled PDU]
587	13.992916	10.86.96.177	10.85.195.199	TCP	66	50514  >  8080 [ACK] Seq=613 Ack=2936 Win=35072 Len=0 TSval=1729539974 TSecr=400875738
588	13.992928	10.85.195.199	10.86.96.177	TLSv1.2	640	Certificate, Server Key Exchange, Server Hello Done
589	13.995298	10.86.96.177	10.85.195.199	TLSv1.2	192	Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
593	14.114585	10.85.195.199	10.86.96.177	TLSv1.2	117	Change Cipher Spec, Encrypted Handshake Message
594	14.114752	10.86.96.177	10.85.195.199	TLSv1.2	182	Application Data
598	14.237584	10.85.195.199	10.86.96.177	TCP	1414	8080  >  50514 [ACK] Seq=3561 Ack=855 Win=771008 Len=1348 TSval=400875988 TSecr=1729540005 [TCP segment of a reassembled PDU]
599	14.237599	10.85.195.199	10.86.96.177	TCP	166	8080  >  50514 [PSH, ACK] Seq=4909 Ack=855 Win=771008 Len=100 TSval=400875988 TSecr=1729540005 [TCP segment of a reassembled PDU]
600	14.237607	10.86.96.177	10.85.195.199	TCP	66	50514  >  8080 [ACK] Seq=855 Ack=5009 Win=40704 Len=0 TSval=1729540036 TSecr=400875988
......
.....
....
...

@george1421 I have my fog server configured with an FQDN instead of IP addresses as we have had to change our IP a few times. So ${fog-ip} is not an actual IP. Also, all computers/VM’s in our network our UEFI configured. I just find it interesting that Clonezilla will work but not this particular version of Gparted.

I changed the files to the following versions and the associated results:

0.33.0-2-i686 - Won't even boot
0.33.0-2-AMD64 - Will boot but crashes later due to the FQDN not resolving for some reason, if IP specified on fetch booted no problem
0.33.0-1-AMD64 - Will boot but crashes later due to the FQDN not resolving for some reason
0.32.0-1-AMD64 - Will boot and works with the FQDN no problem!!! :)

This is the iPXE parameters I am using:

kernel tftp://${fog-ip}/gparted/vmlinuz
initrd tftp://${fog-ip}/gparted/initrd.img
imgargs vmlinuz initrd=initrd.img boot=live config components union=overlay username=user noswap noeject ip= vga=788 fetch=tftp://${fog-ip}/gparted/filesystem.squashfs
boot || goto MENU

@sebastian-roth I just wanted to check-in. Just letting you know I am trying to get this tested but because of the holidays and COVID exposure I am unable to be on-site to test this. It will most likely be in early January as to being able to go back on-site. I will provide an update once we are able to get this tested. We are using a custom background and will try to use a default background of both the white and black.

@Dee Although you had those errors at the beginning it appears it found the disk to capture. Based on your most recent upload it might be that your server is out of disk space.

Would you please run this command on your server and report back?: df -h

@Trev-lchs We are an all HP shop. We have to use rEFInd version 0.10.9 for all of our systems to boot correctly. This is definitely something with HP’s EFI setup.

I ran into this problem myself, which you can reference the post https://forums.fogproject.org/topic/11993/refind-pxe-booting-issue

Let me know if you were able to get this working with this version