Hi, thanks for the reply and information. I was able to solve my problem, by using the fog-api in the postdownloadskript. Now i am able to read the hosts group-name and create automatic dessiscions for manipulating the unattend.xml in windows based on that.
Best,
Floppyrub
Thank you very much for the detailed explanation of the problem and for adjusting the code.
I’m not on the dev branch yet, but I’ll make sure to switch and use debug mode to trace the function.
It’s likely that the tip about using the serial number as the Primary Host Disk will need to be incorporated into my process.
At the moment, I have a large number of Windows 11 reinstallations to handle due to the end of support, so it will probably be a few weeks before I have time for this.
I’ll post an update in this thread once I get to it.
I wanted to just accept the situation as it is. However, I’ve already suffered a second painful data loss because I overlooked a SATA HDD and didn’t disconnect it. I don’t think it’s working the way it should. All my systems are Dell machines that were previously deployed using FOG, and the correct NVME drive was always selected as the target before. Is there anything I can do to solve the problem?
@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.
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?
Hi, thanks for the reply and information. I was able to solve my problem, by using the fog-api in the postdownloadskript. Now i am able to read the hosts group-name and create automatic dessiscions for manipulating the unattend.xml in windows based on that.
Best,
Floppyrub
Hi,
I have a question, how can I get to the group-name assigned to a host during the runtime of a postdownload script. I saw that the group is stored in group64. However, I cannot read this variable. Is there a way to get the group name in a postdownload script or do I have to create an extra script that makes a query in the database?
Best,
floppyrub