@Tom-Elliott can confirm, this does now appear to work in 1.6 - huzzah! @george1421 looks like your hard work has paid off and it will eventually be in the stable branch!

I did update the fog server to the latest version and still the same issue. I am not sure where to go. Virtualbox has the extension installed and vm workstation should work.

I did do this from broadcom

https://community.broadcom.com/vmware-cloud-foundation/discussion/disabling-hyper-v-hypervisor-on-windows-11-pro-host-to-get-vmware-17s-cpl0-vs-ulm-monitor-mode

@chevengur there is not enough information to help you in that picture. If we could see more of the error message that partclone threw (i.e. just above the top of your picture) we would know what happened. At the point in the script all we know is that partclone wasn’t happy.

Thank you!

Ok, nevermind, did the git thing, got it working, cheers 🙂

@george1421 noted. When I was initially testing, I did not know this and it took some digging in the forums to find this tidbit of knowledge. Given that having separate storage groups stops replication between the nodes in my mind it makes most sense to have a more distributed setup of normal servers at each site to handle all of my requirements. Thanks for the input!

@Tom-Elliott Cheers, works as expected now!

@george1421

Ok so the system in question has an on board nic (enp128s31f6), 1 single port Intel PCI-E Gigabit NIC (enp5s0), and 1 dual port Intel PCI-E Gigabit NIC (enp3s0 and enp4s0).

So I booted the system with a Linux system rescue USB key. The network cable is plugged into the single port nic. You can see that it has the IP address 172.16.57.22 was fetched. Without any issues. The mac addresses on the identified nics are:

enp128s31f6 - d4:a2:cd:b7:17:f2 enp3s0 - 00:13:3b:50:b2:b0 enp4s0 - 00:13:3b:50:b2:b1 enp5s0 - ec:08:6b:04:f9:d9 (the one that is attached to the network cable)

SysResecue-Image.jpg

Now when I boot the system up into debug mode with FOG into the FOS environment it seems whatever port is pluged into the lan it adopts another NIC’s mac address as shown below:

FogClient-Image.jpg

Now you can see when the fog client boots the mac address changes on the port that is connected to the LAN as:

enp128s31f6 - d4:a2:cd:b7:17:f2 enp3s0 - 00:13:3b:50:b2:b0 enp4s0 - 00:13:3b:50:b2:b1 enp5s0 - ec:08:6b:04:f9:d9 --> Changed to 00:13:3b:50:b2:b0 (the one that is attached to the network cable)

Now I’ve plugged the cable into enp128s31f6 and setup dhcp on that port as well and tested it. When the fog client starts all of sudden the enp128s31f6 has another NIC’s mac address…

Just a re-cap if I pull the two network cards, and do the re-image on the system I have no issues. It only occurs when I put an additional nic into the system… Any suggestions?

@Tom-Elliott Thank you so much Tom, as always I appreciate your support and guidance.

@Tom-Elliott thx👍

@rodluz
Problem solved - the disk with the image was damaged

@Clebboii https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_MySQL#Database_Maintenance_Commands

Please see if this helps? Specifically the task related items. Sometimes stale (old/bad items suddenly show up from long ago.) admittedly I’d love to know what caused (or causes?) this but it has so far eluded me this far.

@Tom-Elliott What’s the difference between the full and quick registration processes then? because AD join exists in full, but not in quick…

I am confident I have ruled out NFS. I can now connect to the NFS from localhost and Ubuntu to /images & /images/dev without issue and all the permissions that come with it. The only thing failing now is FOG, any guidance would be great!

@sloeckle You can use an older kernel for now, but I’ll work on a fix for this issue. I don’t have access to the hardware needed to reproduce this issue. Are you willing to help us test some kernels?

@Tom-Elliott cheers - looks like someone changed working branch in 2019 to add hdbios, and it’s not something that’s in the dev branch either!

@george1421 No, they were in proper failover config and the options replicated between the scopes. But it’s all good now and that’s the important thing ❤

@Tom-Elliott latest pull resolved the issue. Appreciate your help on this!

@Tom-Elliott no stress, with so many posts it’s normal to miss some 😉

@lsdo FWIW blanking out information regarding a private network address space isn’t helpful to get a full picture of the situation. If that information is for public ip addresses then you have every right to blank it out, but knowing your fogserver is at 192.168.1.100 is of little use to a hacker and it makes trying to understand what is going on a bit harder.

Based on the error message it appears this is a download (being able to see the results of the type variable would help to know for sure) but it appears that FOS (the OS that captures and deploys images) can’t find a hard drive in the target computer to deploy to. I’ve seen this in Dell computers if the sata adapter is in Raid-On mode, a quick test is to switch it to ahci mode in the uefi firmware to see if it can then locate the hard drive.

If you can’t get it by switching to ahci mode, lets dig a bit deeper into this target computer’s hardware.