Distributing images with Focusrite Scarlett connected is not possible

[DennisMeinen]

Unfortunately, we have about 120 PCs, and seven of them still have Focusrite Scarlett connected via USB. Almost all the PCs have NVMe drives, except for one room which has regular SSDs.

The problem arose after updating to the latest version. We were using the version from a few months prior, I believe from August 2025.

[darksidemilk]

So it's suddenly selecting a usb disk instead of the nvme/ssd disk as the first disk?

I mean in theory, you could go into one of the computers and in the fog boot menu select the fog compatibility option and check the hard disk compatibility, somewhere in there it should list the disks as fog sees them and you note the nvme of /dev/nvme0n1 or something like that. Then put all the computers with this usb in them in a fog group and bulk set the group primary disk to that disk and hit update to apply that to all the hosts in the group. This should force them all to use the nvme to boot to. If that usb is bootable, you may run into issues with using exit option for the menu, which now works with UEFI but it may try to boot to the usb if its being seen as the first bootable drive. That's harder to be sure about but if there's consistent behavior its possible to work around it.

[GFUCyrusTechnik]

I tried setting the primary disk to /dev/nvme0n1 explicitly, as well as various other disk path formats, but in all cases the deployment hangs right after selecting the image – just before it should hand off to partclone. It never proceeds into the actual deploy process.

Our current workaround is to physically unplug the Focusrite Scarlett before every deployment, but since we redeploy every machine at least once a week, and we rely on helpers who sometimes forget to unplug it, this is not a sustainable solution.

What makes this especially confusing: the Focusrite Scarlett is a USB audio interface – its USB storage component only exposes driver/firmware files, it is not intended to be a bootable device in any way. The BIOS does not select it as a boot target either. So FOG picking it up as the primary disk candidate feels like unexpected behavior on FOG's side.

Is there a way to blacklist specific USB devices or device classes from being considered as a target disk in FOG? That would be the clean fix for our use case.

[George1422]

t hangs right after selecting the image – just before it should hand off to partclone.

This is a little confusing to me. There is a whole lot that goes on between selecting the image and partclone running. I assume that bzImage has booted and then somewhere before partclone starts it fails?

To debug this I would go into the fog settings/configuration and turn log level up to 7. Then schedule another test deployment, but before you schedule the deployment tick the debug check box. Now pxe boot the target computer. The target system will drop you to a linux command prompt after a few screens of text you need to clear with the enter key.

Hopefully you can get to this point. At this point lets collect some information. (take one or more clear pictures of the output with a mobile phone).

lsusb
lsblk

The lsblk will list all of the storage devices in the computer. We are looking maybe the sound recorder has storage device.

once you collected the information lets start to single step through deployment to see the exact spot that the target computer fails to image. key in the master imaging script name

fog

the imaging script will pause at each breakpoint where you need to press enter to go to the next step. where it fails will help the developers to look in the code to see the results.

[darksidemilk]

There probably is a way to blacklist it, probably something you'd want to make a custom kernel for that as blacklisting might cause unexpected behavior for others.
We'd need to isolate more info on the Linux side for the device I imagine. Or try to remove usb storage drivers from a custom kernel. I'm on my phone so linking is hard but we have an article on docs.fogproject.org related to building a custom kernel. Or maybe we could add something in fos to catch this.
You could also try snponly.efi instead of ipxe.efi which is a long shot but it could load less drivers and maybe help.