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.

[mastacontrola]

Are these odd machines, by chance, housing SSDs that are 4kn, while the NVME are likely 4k drives, they can accept 512e (emulated) into 4k, so a single block can be distributed into 8 blocks of 512. With 4kn drives, there is no "emulated" capability. And with the recent experiences of this lately, I'm going to guess this is the problem.

77358661 x 512 = 39,607,634,432 (~40 GB)
77358661 x 4096 = 316,861,075,456 (~315 GB)

Which I'm pretty confident is larger than the disk in 1 partition not to mention 3.

More likely The real number of blocks should be roughly 9669833 but because it thinks it's dealing with 512 it's split inaccurately.

One of the nice parts of "512e" is that it knows I only have 9669833, and they're asking for 77358661, we can do that nicely. With 4kn, apparently this is not possible.

I'd recommend creating an image specifically for this lab. Then see if that can be deployed only to the machines within that lab.

yes it means one more image to maintain, but there really isn't anyway for us to do it.

In a similar "problem" you wouldn't be able to put a 4kn on a 512 only disk. because while the blocks would match, the actual available space would be far out of bounds.

[mastacontrola]

Your screenshot has the answer: the deploy went to /dev/sda on a machine whose OS disk is NVMe, and every partition is "too big for the disk". That /dev/sda is the Scarlett's USB storage, the small device that carries its driver files. It enumerates ahead of the NVMe, and FOS took the first disk it found.

Fixed in FOS (FOGProject/fos#177): USB and removable devices go to the back of the list and are never chosen automatically while an internal disk exists. They can still be named in Host Primary Disk, and a machine whose only disk is USB still images.

Please try the experimental init from https://github.com/FOGProject/fos/releases/tag/EXP_20260902-204611: put its init.xz in /var/www/html/fog/service/ipxe/ on the server, keeping a copy of the current one, and deploy to one of the seven machines with the Scarlett plugged in. No Host Primary Disk needed.

On the separate report that setting Host Primary Disk to /dev/nvme0n1 hung before partclone: that is a different symptom and I cannot see it from here. If it still happens on this build, please open a new issue with a photo of where it stops.