@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

@Sebastian-Roth

I just meant that I am having to rebuild the FOG server on an updated OS. I figured that an up to date version of initrd with NFSv4 support enabled would be a good idea. We have been utilizing NFSv4 for about a year and a half now. This was a requirement from our Cyber security team.

I am was running Ubuntu 18.04 before and now running Ubuntu 22.04. The new server is currently in production with the old initrd_NFSv4 george1421 made for me, working. I just wanted to make sure there wasn’t new code in the initrd that could be an issue later down the road, that would interfere with new features and what not. Which is why I guess I was asking if we could get the newest version but built to enable NFSv4 support.

@george1421 said in Feature request for FOG 1.6.x - Configure image capture to use NFSv4 instead of NFSv3:

Changes needed to FOS for NFSv4 support

Understand these instructions are for the FOG Devs and not the general FOG admin. You need to know the insides of FOS Linux development to understand some of my notations. I did not test with the option of port=2049. The hope is that is the default so it shouldn’t be needed. By defining a specific port firewall rules can be crafted much easier than with NFSv3 and earlier.

1. In buildroot the nfs-utils packages in the nfs-utils.mak file nfsv4 support must be enabled.

NFS_UTILS_CONF_OPTS = \
        --enable-nfsv4 \
        --enable-nfsv41 \
...
HOST_NFS_UTILS_CONF_OPTS = \
        --enable-nfsv4 \
        --enable-nfsv41 \
...

2. nfsvers=4 must be added to the mount command in the following files in the overlay fs directory
   ./rootfs_overlay/bin/fog line:14
   ./rootfs_overlay/bin/fog.mount line:17,20
   ./rootfs_overlay/bin/fog.av line:15
   ./rootfs_overlay/bin/fog.photorec

3. Done. Now rebuild initrd filesystem in buildroot

I’ve compiled a FOG 1.5.9 NFSv4 version of the initrd here: https://drive.google.com/file/d/1EHLhmM9-kXpFO7kfk3H1ydEZF3q8lID1/view?usp=sharing

@george1421 It has been quite some time but I have been tasked with having to completely rebuild FOG on a new OS. I was wondering if you could spare some time to generate a new initrd-NFSv4 from the “dev-branch” for me?

Or if there are instructions somewhere I can follow to do this myself, I would be very much willing to do that as well.

@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

@JJ-Fullmer I am sure you are incredibly busy. I was just wondering if you had a few minutes to help me out with the FOG API and changing inventory values?

@george1421 Do you know of any pointers you could provide me?

I have been battling this for the last few days. I don’t know if my json body is wrong or what?

I am trying to update the inventory item “other2” with an IP address

When I try to test doing this from Postman, I have tried formatting different ways and no luck. I am hoping you can help point me in the right direction. I am also using powershell to perform a fair amount of automation

$params = @{
    Uri         = "http://<URL>/fog/host/283"
    Headers     = @{ 
    'fog-api-token' = "$fog_api_token"
    'fog-user-token' = "$fog_user_token"
    'Content-type' = "application/json"
     }
    Method      = 'PUT'
    Body = $jsonbody
}
Invoke-RestMethod @params

JSON Body:

{
    "inventory":  {
                      "other2":  "10.1.5.35"
                  }
}

@george1421 I was able to get it working, yes. I was able to do both a capture and a deploy with NFSv4 being setup.

I now have the ability to only open two ports in the firewall for all of my FOG clients. Ports 2049/tcp and 80/tcp. I have a DHCP relay server that sits on each network, and it delivers the both ipxe.efi and default.ipxe via TFTP and everything else is done with HTTP. I haven’t figured out a way to boot not using TFTP but it seems that only works if HTTP network boot is an option for the device. This way I do not have to expose a TFTP service on the FOG server or having to use a helper to get it where it needs to be.

@Sebastian-Roth Quickly looking at that discussion it seems that maybe SSH might be the future but it comes with some performance loss and some other struggles.

I would be more than happy to just have NFSv4 be the default standard because at least that is improvement until a more in depth development and assessment can be done to do something different.

Thank you all!!!

@george1421 I was able to capture and deploy!!! Thank you for helping me through this process. I am being forced to use this starting in September now.

How much modification would it take to even just allow NFSv4 to work in FOG as it stands today?

@george1421 Thank you for that SSH tip!!! Saves me from having to go into the office almost everyday to test this stuff.

I don’t have any network access into my test environment but at least I can do it from a Windows or Linux client that’s already on the network instead of the console.

This is the command result:

Now what I am unsure of is if I did make any modification to the boot.php. I will try and find that file and make the necessary modifications.

UPDATE: I was able to change the boot.php file which is what you had mentioned at the very beginning. I was thinking that was part of the initrd file but clearly it is not. It is capturing right now. After it is done, I will be testing a deploy as well.

@george1421 I have been testing quite a bit of the day with all sorts of different configurations on the server. Come to find out it appears that in the initrd that you uploaded, for some reason the NFS mount is being mounted as “Read Only File System”.

If I issue on the FOS client mount -t nfs -o vers=4 10.0.0.5:/capture /images I am able to then write to the /images directory no problem… The only issue is that I still can’t continue to run the capture as it marks /images directory as read-only again.

I don’t know what to look for in FOS for the reason why it is mounting the NFS as a read-only file system?