@mrp Added to the official FOS inits now. Can’t wait any longer for you to test.

@sebastian-roth Thanks for your reply, we will try the alpha version.

My teammate ask me to say a big thank you because since 2008 we use fog and we see you’r answer are very quick and we are very happy to use fog.

did i need to do something to indicate the post as resolved ?

@george1421

Thank you for this response. I am looking into getting Volume licenses. If it is viable for the company I will be moving forward with FOG Project.

That error says that partition 4 is too small. So it seems to think that the image is bigger than the spin 5’s drive.
Looking at your image settings I’d recommend recapturing using partclone zstd at compression level 19. Probably won’t fix this problem, but might speed up your imaging while saving space on the server.

I believe the when fog captures the image it shrinks it down to only what is actually in use, so your scenario should work. Personally, as a fail safe, I use a 80 GB virtual disk size for my images which never had an issue deploying to 120 GB drives. Granted after a while we found that users with 120 GB drives ran out of space just from windows maintenance (updates, caches, etc.), well that and the users never deleting an email in outlook.

So if it’s feasible, maybe try recapturing the image with the virtual drive being smaller than anything in your environment. (80-120 GB perhaps).

@Mr_Matten Ah, glad you figured it out!

This is where computer imaging isn’t exactly a smooth process. Unfortunately, machines implement displaying a drive however they see fit, even across the same model of different machines. Typically the channels that an HDD is connected to (SATA 0, SATA 1, etc…) are followed to some level, but sometimes this isn’t the case (as I imagine you’re seeing now).

It is possible to tell FOG which drive to use, though it doesn’t know if the drive is ssd or hybrid or spinner. This is completely dependent on the machine, and if you can’t rely on which will be populated as what letter (my guess is your machines were setup in RAID mode of sorts?) that isn’t really going to help you much.

One way you could do this though, is to swap out the /usr/share/fog/lib/funcs.sh file and change the getHardDisk function to detect your drive sizes. (You can do the swap out using postinit scripts.) But then it’s implicit that all machines will follow the same method.

The steps I would take, albeit more time consuming initially:

Install the SSD to the 1st SATA Channel (if that’s how your machines are setup – I can’t help much in the case of NVMe/MMC builtin controllers as I have nothing to base them on yet).

Move the 1TB to the second SATA Channel.

Ensure the machine’s firmware is updated to the latest and greatest.

Ensure the machine’s SATA operation mode is AHCI.

If these don’t make your SSD display as /dev/sda then I don’t know else to tell you to try.

@Tom-Elliott absolutely, was looking for how I could mark resolved this side funnily enough,