Stop image deployment if specified disk not found

[Peter-Csatlos]

Is your feature request related to a problem? Please describe.
Some of the machines I use FOG with have multiple disks. For these machines, I have set the "Host Primary Disk" by the unique id of the SSD. After imaging around 100 machines last week, I noticed that on one machine the new image went to it's HDD. It probably had an SSD failure some time last year, so it was changed without updating the field in FOG. Now the Primary Disk setup does nothing. In this case, the actual data loss is not an issue, but I can see that this could be a major problem for someone.

Describe the solution you'd like
I would like to the image deployment process to fail if the Host Primary Disk field is set but the specified disk is not found. This should be an optional feature, so the current behavior is kept if this is toggled off.
The best implementation would be if the task would go in a "failed" state, so the admins can see on the web ui that there is an issue and the machine is not just silently in a boot loop. This failed state would remain until and admin is removing the task and the failed task should not be picked up again by the machine so it can boot back into the installed OS.

[mastacontrola]

I have transferred this where this should actually sit. That said, I think I understand what you're asking.

Effectively:

"If the host primary disk is set and the device doesn't have said host primary disk, don't try to image."

Is this correct? I know it's probably obvious but just want to make sure the language is simplified and clear.

[Peter-Csatlos]

Thank you, this is exactly what I meant.

[mastacontrola]

I'm attempting a build of the master branch as we speak. Sorry it took so long to get around to this, but I couldn't figure out how to best approach and with work and all made getting to this that little bit more difficult.

Effectively I've done as requested. I don't know if it will work, so once it builds, you will likely see an experimental release.

I forgot to tag this issue on the commit at which I hope this is fixed. Please let me know if this new thing works.

[Peter-Csatlos]

I'm attempting a build of the master branch as we speak. Sorry it took so long to get around to this, but I couldn't figure out how to best approach and with work and all made getting to this that little bit more difficult.

Effectively I've done as requested. I don't know if it will work, so once it builds, you will likely see an experimental release.

I forgot to tag this issue on the commit at which I hope this is fixed. Please let me know if this new thing works.

Thank you, I will test it as soon as I can.

[Peter-Csatlos]

I'm attempting a build of the master branch as we speak. Sorry it took so long to get around to this, but I couldn't figure out how to best approach and with work and all made getting to this that little bit more difficult.

Effectively I've done as requested. I don't know if it will work, so once it builds, you will likely see an experimental release.

I forgot to tag this issue on the commit at which I hope this is fixed. Please let me know if this new thing works.

The new release is not working unfortunately. The script is throwing a lot of errors and I get an infinite loop no matter what is in the "Host Primary Disk" field.

I have a screen capture if you want to have a look: (the FOG part start about 40 seconds)

Screencast.from.2025-07-14.15.02.32.webm

[mastacontrola]

I had a typo apparently, my apologies, I'll rebuild the expermental release. Should be ready in ~ 1 - 1.5 hrs.

[Peter-Csatlos]

@mastacontrola The new release is better, but I cannot deploy an image even with the correct disk in the machine. Have you also changed how the disk selection works? Currently, I write the full path of the disk (with the disks short id) to the "Host Primary Disk" field, like this: /dev/disk/by-id/wwn-0x50026b7266070c73
This format was working for the past 2 years, and I double checked by booting into FOG debug mode, the id is correct.

[mastacontrola]

I did change how the getHardDisk function works. but it does escape special characters so I will update to remove the special characters it will change. And we can try. The good news is it is indeed failing "correctly" although unexpectedly in the case you've provided.

[mastacontrola]

Okay rebuilding, apologies on all the back and forth, but really want to get this working and working as predicted/expected.

Thank you for the patience.

[Peter-Csatlos]

I tried the 20250715 build, I still get the disk is not found error. But something is not right with my test setup. I started a deployment with the stable release I use and the disk selection is seemingly ignored. I don't understand why, as this was working on other (production) machines back in december.
The only difference with my test setup, that I use a sata ssd here as the selected disk, while we use nvme ssds in the production machines.
So in production, the disk selection is like this: /dev/disk/by-id/nvme-eui.002538b121404d08 , I don't think this should change anything, but you might have an idea?

[mastacontrola]

So found I accidentally introduced a bug.

THis appears to be now addressed more appropriately. Apologies on lack of communication on this, but had other things come up.