@Deimos From what you are saying I am wonder if you aware of the fact that FOG does not have persistent group settings. It’s more or less just a tool to push a setting to several hosts at once but it does not stick to the group itself.

@Nabeel Did you configure your dhcp server to supply dhcp options 66 and 67? For dhcp option 66 that needs to be the IP address of your fog server. For dhcp option 67 that should be undionly.kpxe for bios based computers and ipxe.efi for UEFI based systems.

If you need to support both systems in your environment then once you prove that the above options work you can review this article: https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence#Using_Windows_Server_2012_.28R1_and_later.29_DHCP_Policy

@george1421

Sooooo as stupid as this sounds but I have a solution / workaround.

Reduce the number of CPU’s on the VM to 1
Enable migrate to a physical computer with a different processor version

Changing either of these setting causes the speed to bottom out at 21mb/m leaving the setting at this results in 230mb/m capture speed.

OK, thought it might be possible…appreciate the reply.

@EAHarvey Can you post the content of the three text files d1.partitions, d1.minimum.partitions and d1.fixed_size_partitions from this image you deployed here. We’ll see if there is something specific in the partition layout that might cause the problem.

bcdboot D:\windows /s Z: /f ALL

I have not used bcdboot too much but I kind of wonder about the drive letters…

@0juke Guess there is some useful information for you here: https://wiki.fogproject.org/wiki/index.php?title=Add_%26_Extend_a_2nd_Virtual_HDD

Other than that we need more specific information on what exactly you did so far (“So I would like to expand the space of the server uses . I’ve done this on the VM but…”). Only when we know what exactly you did and what system/software you use we will be able to help properly.

@bigjim Are there any news on this? I am marking this solved for now as no reply within a week kind of sounds like you were able to fix this.

@im-pearce Any news on this? Is there something we can do for you to solve this?

It’s done …I have completely installed the virtual machine but also the fog server with the latest version, at the moment it seems that everything works just fine, I managed to capture the image of windows 10 with MBR, also did a full inventory of the work station , i deployed it on another workstation … momentarily I’m with kernel 4.19.36 … I’m thinking to update it at 4.19.48 … but I doubt it will not come up with the same problem … however i will try anyway 🙂
10x for the help ! …specialy @george1421 but also @Tom-Elliott ( apparently the problem started from the location where my images are saved…bad cfg )

@bartont126 Well unfortunately we need to see what the partclone error is. Partclone doesn’t give a good quality error message back to fog, other than the copy failed. FOG ties to make a good guess to why the copy didn’t happen but misses some times. If you setup a debug capture then single step through the deployment you can capture what is on the partclone screen.

@Sebastian-Roth

Updating the FOG server to the latest image appears to have resolved the issues. Good thing is did not have to modify anything after the update all models appear to be imaging successfully. 🙂

I’m on fire today guys… I apologize for all of these mis-posts… The reason why my FOG hosts aren’t getting jobs is because my old server is still online… I was running an old image that had my previous server IP on it for the client…

Boy oh boy! Glad it was that simple. I believe that is the end of it.

Please mark this as solved.

Nevermind!!! My browser must have been being an issue…

Disregard this thread. SMH…

Ha!

@Fernando-Gietz
@Sebastian-Roth

Fernando’s fix takes it! That worked!

The first statement didn’t produce any results. But the second one did and after I restarted Multicasting, things are working again! Woo Whoo!

Thanks guys! I owe you both a beer!

Cheers!

For the record, if anyone else has this issue…

This was the fix…

ALTER TABLE multicastSessions ADD COLUMN msAnon4 VARCHAR(250) AFTER msAnon3;

Here is the Error Log errorlog (1).jpg

@george1421 I ran a full chkdsk on that machine, and I still received the same error.

To see if the issue was isolated to that machine I grabbed another one, inventoried it, and ran a capture task without issue. I think we can safely call this issue solved at this point.

To all interested, Following the below guide solved my initial NFS issue with my QNAP:
https://forums.fogproject.org/topic/10973/add-a-nas-qnap-ts-231-as-a-storage-node-fog-v1-4

Thanks to everyone for their help with this project!

@arnaudrigole said in Dell Optiplex 7060 - getHardDisk error:

I used that trick to switch between “raid on” and “AHCI” during more than one year right now, and it worked well but…

Now we got NVMe SSDs in our new DELL computers, which need to be configured in “Raid ON” as “Sata Operation” to boot on Windows. Do you think that “GetHardDisk” error will be fixed in next versions ?

I think you have two different issues here. The first issue is the raid-on vs ahci mode. This is an age old issue between Intel, Linux, and uefi. With these three amigos working together linux can’t currently see any disks behind this configuration. If you change any of the three (really two) linux will see the disk. From what I understand the issue is related to intel not releasing the uefi raid drivers to the linux community.

The second issue may be new Dell hardware with these NVMe disks.

What version of FOG are you using? What version of FOS Linux kernel do you have installed? What is the model number of the computer with this issue?

@0juke If you did not make any changes to your dhcp server then that is the primary problem. PXE booting client relies on 2 settings in dhcp. They are dhcp option 66 {next-server} and dhcp option 67 {boot-file}. These options tell the pxe booting client how to boot.

For dhcp option 66 that needs to be the IP address of the fog server.
For dhcp option 67 needs to be undionly.kpxe for bios based computers and ipxe.efi for uefi based computers.

Without these settings the client computer will not know how to boot.

Thank you for the reply. I am all set now. Seeing the fogproject user had me confused. I wasn’t aware of the username change.
Thanks again for the help.

@george1421 Awesome! Thank you, George!