Wow, thanks for the quick response!
I do agree that ideally, people should just remove the disks they don’t want affected. Unfortunately, we do sometimes run into systems where it’s difficult to do, especially in the case I mentioned where the system was an all-in-one of some sort (Dell, I think) that had an SSD cache disk as the first drive. In those cases, it’s much more than 15 seconds to disassemble the whole thing, hunt down the offending SSD (hopefully it’s in a socket that can be accessed easily), and remove it.
The feature in r3262 is helpful, but I don’t think it will work for us. When we have to specify a disk, it will have to be on a case-by-case basis. If, for example, we set it to use /dev/sdb as fdrive, then it will have to be changed back when we go back to a more “normal” use case (i.e., most of them).
Of course the solution I mentioned would be the ideal one, but I think the bare minimum we need would be a field presented to the user after selecting the image that just lets them set the fdrive parameter from there by typing it.
Seeing where you made the change did help me understand what’s going on a bit more. I will spend some time looking at the system and see if I can come up with a patch to submit so you don’t have to spend a lot of time on something that’s admittedly an edge case.
