Wrong target device
-
I’ve currently run into a problem in FOG that I can’t resolve. I’m using version 1.5.10.1698. I have different systems with varying numbers of hard drives. All of the systems have an NVMe drive, which is where the installation is supposed to go. Sometimes the systems also have one or two additional data HDDs.
As soon as even one HDD is connected, FOG always selects it as the target device for deployment. This has already led to a painful data loss. In debug mode, the NVMe drive is displayed correctly, and if I disconnect the HDD, the installation works fine on the NVMe.
Could this issue be related to how the Windows image was created? I currently can’t rule out that when the Sysprep was performed, the HDD was also connected alongside the NVMe (the drive on which Windows is installed).
I seem to remember that in earlier FOG versions, it always selected the NVMe drives automatically. I’m now trying to find out where exactly the error occurs. Could you tell me which file in FOG determines the target disk for deployment?
-
@Floppyrub /usr/share/fog/lib/funcs.sh getHardDisk function is where the code is located.
You’ll want to look at github.com/fogproject/fos for this under the path https://github.com/FOGProject/fos/tree/master/Buildroot/board/FOG/FOS/rootfs_overlay/usr/share/fog/lib/funcs.sh specifically.
Recent updates have been made that were attempting to account for “Host Primary Disk” field allowing serial/wwn/disk size lookups to help pinpoint what drive to use for imaging when this is set.
In a point of consistency it now de-duplicates and sorts the drives, so it’s possible:
/dev/hdX is chosen as the primary drive before /dev/nvmeX because of the sorting feature.
There’s no real way to consistently ensure nvme is loaded before HDD’s though so there was always the potential, just that nvme runs on the PCI bus directly rather than the ATA busses (which are generally much slower to power on)
Now /dev/sdX (in the new layout) would most likely be safe because lexicographically speaking it would fall in after the nvme’s in naming sorting I’d imagine?
Currently, I’m aware that the released version of inits likely is also presorting by disk size first (assuming the largest drives are the primary disk you’d want to send the image to when you’re not using the Host Primary Disk feature.)
From my viewpoint (limited as it may be) you may need to start using UUID/WWN/Serial formatting more for these multi-disk connections where you don’t want to accidentally overwrite a disk.
Easier said than done, but my point is the getHardDisk feature is a best guess algorithm at its core. It “seemed” better in older systems, but as new technologies and methodologies of reading data come about, there’s no real “this is definitely the drive this user wants the OS to sit on” method available to anyone.
-
@Tom-Elliott Thanks for your detailed response. I can understand the problem well. On desktops, you can simply disconnect the HDDs if necessary. However, the day before yesterday, I had a laptop with two NVMe drives, where that would be very inconvenient. There, the installation also went to the second NVMe instead of the first.
The hint about funcs.sh is extremely valuable. I had already come across the line /usr/share/fog/lib/funcs.sh in the file fog.custominstall. When I wanted to look at the file, I noticed that this directory does not exist in my installation. I had assumed it was old custom code I had written. Now I know that’s not the case. I will download the file from GitHub and place it on the system, and I’m quite confident that this will solve the problem, at least initially.
The system was freshly installed at the end of August with version 1.5.10.1600, so the error must have occurred there.
-
@Floppyrub The code exists in the FOS system (when you boot a machine for a task, not on your server)
