Golden W10 21h2 : fog.drivers : wrong partition on HP 640 G2 laptop

Jonathan Cool · Dec 9, 2022, 1:22 PM

Hi all,
I’m using golden image since few years now (Win7 / W10).
I’m using the fog drivers injections methods with fog.postdownload script …

It’s works successfully but recently, i saw a problem : on HP 640 G2 with a W10 21h2 sysprepred image, the Windows/DRV folder is always empty …

Today, i tried some reveleant tests : on the affected computer :

i ran a debug task
i ran fog script …. and CTRL+X the scrit just after the « preparing drivers » text
i checked the product name with the de dmidecode command : dmidecode -s system-product-name :HP ProBook 640 G2 → OK, it’s good
i umounted the ntfs folder and re-mount with ntfs-3g -o force,rw /dev/sda2 /ntfs
i manually ran this command : rsync -aqz --exclude=‘*.CAB’ “/images/Drivers/Win10/HP ProBook 640 G2/x64” /ntfs/Windows/DRV → OK good, the copy of drivers works correctly.

So … i retried the debug task but killed the fog script just after the mount partition : after that, i do an « ls /ntfs », i saw the wrong partition : system reserved partition. I think, this is the culprit but … i don’t know i can fix this … because, with others model like DELL Optiplex 5050, the drivers copy works correctly … and the system partition is correctly detected.

Any idea ?
Thank you

Other useful information :
stuff / fog version : check my signature
blkid on the 640G2 computer :
[Fri Dec 09 root@fogclient /ntfs/Windows/DRV/x64]# blkid
/dev/ram0: UUID=“1c9acfae-b3e6-4506-8ccc-4ffbff7bdfce” BLOCK_SIZE=“1024” TYPE=“ext2”
/dev/sda1: LABEL=“RM-CM-)servM-CM-) au systM-CM-(me” BLOCK_SIZE=“512” UUID=“DC7279F37279D32E” TYPE=“ntfs” PARTUUID=“c449399d-b51e-11ea-accc-08002700f0f8”
/dev/sda2: LABEL=“System” BLOCK_SIZE=“512” UUID=“82247DDF247DD69F” TYPE=“ntfs” PARTUUID=“c449399e-b51e-11ea-accc-08002700f0f8”
/dev/sda4: UUID=“D43A-493E” BLOCK_SIZE=“512” TYPE=“vfat” PARTUUID=“5a66023c-da39-4836-8e35-07074543bd99”

my fog.drivers

#!/bin/sh
 
ceol=`tput el`;
machine=`dmidecode -s system-product-name`; # Gets machine model
machine="${machine%"${machine##*[![:space:]]}"}" #Removes Trailing Space
system64="/ntfs/Windows/SysWOW64/regedit.exe"; # dirty way to determine if it's 64bit or not
if [ -f "$system64" ]; then
    setarch="x64"
else
    setarch="x86"
fi
#############################################
#this is not section necessary needed, it's just to make the path "human readable"
#rather than using osid for filepath
if [ $osid == "5" ]; then
    osn="Win7"
elif [ $osid == "6" ]; then
    osn="Win8"
elif [ $osid == "7" ]; then
    osn="Win8.1"
elif [ $osid == "9" ]; then
    osn="Win10"
fi
#############################################
dots "Preparing Drivers";
# below creates local folder on imaged pc
#this can be anywhere you want just remember
#to make sure it matches throughout!
mkdir /ntfs/Windows/DRV &>/dev/null;
echo -n "In Progress";
 
#there's 3 ways you could handle this,
#driver cab file, extracted driver files or both
#so on the server put extracted driver files to match below folder tree
#i.e. Model Latitude E5410, Windows 7 x86 image would be:
#/fog/Drivers/Win7/Latitude E5410/x86
#rsync -aqz "/fog/Drivers/$osn/${machine}/$setarch" /ntfs/Windows/DRV &>/dev/null;
 
#if you wanted to use driver.cab use this line below : essai de cette methode pour l instant : driver .cab avec un Opti7010
#i.e. /fog/Drivers/Win7/Latitude E5410/E5410-Win7-A07-KTT4G.CAB
#cabextract -d /ntfs/Windows/DRV "/images/Drivers/$osn/${machine}"/*.CAB &>/dev/null;
 
#if you wanted to mix both cab and extracted use these:
rsync -aqz --exclude='*.CAB' "/images/Drivers/$osn/${machine}/$setarch" /ntfs/Windows/DRV &>/dev/null;
cabextract -d /ntfs/Windows/DRV "/images/Drivers/$osn/${machine}"/*.CAB &>/dev/null;
 
#this next bit adds driver location on pc to devicepath in registry (so sysprep uses it to reference)
# remember to make devicepath= match the path you've used locally
#also do not remove %SystemRoot%\inf
#and to add more locations just use ; in between each location
regfile="/ntfs/Windows/System32/config/SOFTWARE"
key="\Microsoft\Windows\CurrentVersion\DevicePath"
devpath="%SystemRoot%\inf;%SystemRoot%\DRV";
reged -e "$regfile" &>/dev/null <<EOFREG
ed $key
$devpath
q
y
EOFREG
echo -e "\b\b\b\b\b\b\b\b\b\b\b${ceol}Done"; # this just removes "In Progress and replaces it with done :-)"

george1421 · Dec 9, 2022, 1:22 PM

@jonathan-cool OK you have done quite a bit of debugging that will help us narrow down the problem quickly.

So you say that its picking the system reserved partition instead of the C drive.

That code is in the fog.custominstall script.

That script is simple and may no longer be complete.

This is the important part.

                   if [[ ! -d /ntfs/windows && ! -d /ntfs/Windows && ! -d /ntfs/WINDOWS ]]; then
                        echo "Not found"
                        umount /ntfs >/dev/null 2>&1
                        continue
                    fi

Simply it looks to see if there is a folder called Windows on the partition, if yes then it assumes it found the C drive.

SO what I want you to do is debug your script again, again stop it just after the mount of the file system. That should once again be the system reserved partition. Check to see if there is a directory called “Windows”, if yes then we will need to find another file to reference to identify the real windows c drive vs the system reserved partition.

Jonathan Cool · Dec 9, 2022, 1:40 PM

@george1421 Hey !
Hmmm, i did some news tests … and i tried to used fog.copydrivers instead of the (old?) fog.drivers …

I did some modifications (switch $arch / $os for example) to reflect my NAS organization. But it’s fail with weird message : script found x86 arch !

So, i tried the same script (fog.copydrivers) with an DELL Optiplex 5050 … and he found an x86 arch … weird no ?

my “custom” fog.copydrivers

#!/bin/bash
ceol=`tput el`;
manu=`dmidecode -s system-manufacturer`;
dots "Identifying hardware"
case $manu in
    [Ll][Ee][Nn][Oo][Vv][Oo])
        machine=$(dmidecode -s system-version)
        ;;
    *[Dd][Ee][Ll][Ll]*)
        machine=$(dmidecode -s system-product-name)
        ;;
    *I[Nn][Tt][Ee][Ll]*)
        # For the Intel NUC and intel mobo pick up the system type from the
        # baseboard product name
        machine=$(dmidecode -s baseboard-product-name)
        ;;
    *)
        # Technically, we can remove the Dell entry above as it is the same as this [default]
        machine=$(dmidecode -s system-product-name) 
        ;;
esac

# if the machine isn't identified then no need to continue with this script, just return to caller
if [[ -z $machine ]]; then 
    echo "Unable to identify the hardware for manufacturer ${manu}";
    debugPause;
    return;
fi 
echo "${machine} Identified";

# Removes Spaces in machine name, works better with path definitions
machine="${machine%"${machine##*[![:space:]]}"}";
# Jeffrey Boulais posted that the above code did not work for his install. He
#  supplied this code as an alternative. If you run in to a problem using my code
#  comment out my code and see if his code works better for your installation. The 
#  only right way is the one that works. Thank you Jeff for your input. 
# machine="$(echo -e “${machine}” | tr -d ‘[:space:]’)"

dots "Verifying we've found the OS disk"
if [[ ! -d /ntfs/windows && ! -d /ntfs/Windows && ! -d /ntfs/WINDOWS ]]; then
    echo "! OS root Not found !";
    debugPause
    return;
fi
echo "Found";
        
dots "Verifying target Arch"
system64="/ntfs/Windows/SysWOW64/regedit.exe"
[[ ! -f $system64 ]] && arch="x86" || arch="x64"
echo "${arch} found";

debugPause

# set osn path names based on the osid set in the FOG WebGui
case $osid in
    5) osn="Win7" ;;
    6) osn="win8" ;;
    7) osn="win8.1" ;;
    9) osn="Win10" ;;
esac

dots "Preparing Drivers"
clientdriverpath="/ntfs/Windows/DRV"
# remotedriverpath="/images/Drivers/$machine/$osn/$arch"
remotedriverpath="/images/Drivers/$osn/$machine/$arch"

debugPause

if [[ ! -d "${remotedriverpath}" ]]; then
    echo "failed";
    echo " ! Driver package not found for ${machine}/$osn/$arch ! ";
    debugPause;
    return;
fi
echo "Ready";

debugPause

[[ ! -d $clientdriverpath ]] && mkdir -p "$clientdriverpath" >/dev/null 2>&1
echo -n "In Progress"

rsync -aqz "$remotedriverpath" "$clientdriverpath" >/dev/null 2>&1

[[ ! $? -eq 0 ]] && handleError "Failed to download driver information for [$machine/$osn/$arch]"

debugPause

# the following code is only valid for Windows 7 operating systems since Windows 8 and beyond
# relies on the unattend.xml section to locate OEM drivers. If you are no longer deploying Win7
# you may exclude this section. 

regfile="/ntfs/Windows/System32/config/SOFTWARE"
key="\Microsoft\Windows\CurrentVersion\DevicePath"
devpath="%SystemRoot%\DRV;%SystemRoot%\inf;";
reged -e "$regfile" &>/dev/null <<EOFREG
ed $key
$devpath
q
y
EOFREG

debug task on 640 G2

 * Testing partition /dev/sda1.......................Not found
 * Testing partition /dev/sda2.......................Success
Done
 * Press [Enter] key to continue

Image Universelle PC fixe sous Windows10x64...copie du fichier diskpart.txt permettant au setupcomplete.cmd d etendre la partition C
 * Identifying hardware..............................HP ProBook 640 G2 Identified
 * Verifying we've found the OS disk.................Found
 * Verifying target Arch.............................x86 found
 * Press [Enter] key to continue

 * Preparing Drivers................................. * Press [Enter] key to continue

failed
 ! Driver package not found for HP ProBook 640 G2/win10/x86 ! 
 * Press [Enter] key to continue
^C
[Fri Dec 09 root@fogclient ~]# cd /ntfs/
[Fri Dec 09 root@fogclient /ntfs]# ls
'$Recycle.Bin'  'Documents and Settings'   PerfLogs        'Program Files (x86)'   Recovery      'System Volume Information'   Windows       install        winTail.exe
'$WinREAgent'    DumpStack.log.tmp        'Program Files'   ProgramData            Softportable   Users                        bootTel.dat   swapfile.sys

[Fri Dec 09 root@fogclient /ntfs]# cd Windows/S
SKB/              ServiceProfiles/  Setup/            ShellExperiences/ Speech_OneCore/   System/           SystemApps/       SystemTemp/       
SchCache/         ServiceState/     ShellComponents/  Speech/           SysWOW64/         System32/         SystemResources/  
[Fri Dec 09 root@fogclient /ntfs]#

Jonathan Cool · Dec 9, 2022, 3:02 PM

@george1421 hi,
Not sure if i correctly answer to your question … :

using my classic fog.postdownload script with my classic fog.drivers

   Version: 1.5.9
   Init Version: 20200906
 * Press [Enter] key to continue

 * Verifying network interface configuration.........Done
 * Press [Enter] key to continue

 * Checking Operating System.........................Windows 10
 * Checking CPU Cores................................4
 * Send method.......................................NFS
 * Attempting to check in............................Done
 * Press [Enter] key to continue

 * Mounting File System..............................Done
 * Press [Enter] key to continue

 * Checking Mounted File System......................Done
 * Press [Enter] key to continue

 * Checking img variable is set......................Done
 * Press [Enter] key to continue
^C
[Fri Dec 09 root@fogclient /]# blkid 
/dev/ram0: UUID="1c9acfae-b3e6-4506-8ccc-4ffbff7bdfce" BLOCK_SIZE="1024" TYPE="ext2"
/dev/sda1: LABEL="RM-CM-)servM-CM-) au systM-CM-(me" BLOCK_SIZE="512" UUID="DC7279F37279D32E" TYPE="ntfs" PARTUUID="c449399d-b51e-11ea-accc-08002700f0f8"
/dev/sda2: LABEL="System" BLOCK_SIZE="512" UUID="82247DDF247DD69F" TYPE="ntfs" PARTUUID="c449399e-b51e-11ea-accc-08002700f0f8"
/dev/sda4: UUID="D43A-493E" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="5a66023c-da39-4836-8e35-07074543bd99"
[Fri Dec 09 root@fogclient /]# ntfs-3g -o force,rw /dev/sda1 /ntfs
The disk contains an unclean file system (0, 0).
Metadata kept in Windows cache, refused to mount.
Falling back to read-only mount because the NTFS partition is in an
unsafe state. Please resume and shutdown Windows fully (no hibernation
or fast restarting.)
ntfs-3g-mount: failed to access mountpoint /ntfs: No such file or directory
[Fri Dec 09 root@fogclient /]# mkdir /ntfs
[Fri Dec 09 root@fogclient /]# ntfs-3g -o force,rw /dev/sda1 /ntfs
The disk contains an unclean file system (0, 0).
Metadata kept in Windows cache, refused to mount.
Falling back to read-only mount because the NTFS partition is in an
unsafe state. Please resume and shutdown Windows fully (no hibernation
or fast restarting.)
[Fri Dec 09 root@fogclient /]# cd /ntfs/
[Fri Dec 09 root@fogclient /ntfs]# ls
 BOOTNXT   BOOTSECT.BAK   Recovery  'System Volume Information'   bootmgr
[Fri Dec 09 root@fogclient /ntfs]#

george1421 · Dec 9, 2022, 9:29 AM

@jonathan-cool OK you are using the really old script. But if it works no problem.

This is the section of code that is in doubt from your script

dots "Verifying we've found the OS disk"
if [[ ! -d /ntfs/windows && ! -d /ntfs/Windows && ! -d /ntfs/WINDOWS ]]; then
    echo "! OS root Not found !";
    debugPause
    return;
fi
echo "Found";

Here we test to see if there is a windows directory on the test partition. If yes, then we are done. I guess since this script is picking the wrong partition it see a windows directory on the system reserve partition and things it find the windows c drive.

So we must make this script look for something unique that only appears on a real windows c drive.

So my idea again is to stop the script where it “thinks” it find the windows c drive (but wrong partition). In debug mode look at that wrong partition to see if you can identify if it has a windows directory. If yes then that is what is causing the script to fail. We must find something that only exists on a windows c drive to search for that is NOT on this system reserve partition for the script to work correctly. That is the idea.

For reference here is a bit more advanced version of the script you use: https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed

Jonathan Cool · Dec 12, 2022, 7:34 AM

@george1421 Hi !
I changed my script for the newer … :

fog.postdownloadscript :

#!/bin/bash
. /usr/share/fog/lib/funcs.sh
[[ -z $postdownpath ]] && postdownpath="/images/postdownloadscripts/"

. ${postdownpath}/fog.custominstall

esac

fog.copydrivers :

#!/bin/bash
ceol=`tput el`;
manu=`dmidecode -s system-manufacturer`;
dots "Identifying hardware"
case $manu in
    [Ll][Ee][Nn][Oo][Vv][Oo])
        machine=$(dmidecode -s system-version)
        ;;
    *[Dd][Ee][Ll][Ll]*)
        machine=$(dmidecode -s system-product-name)
        ;;
    *I[Nn][Tt][Ee][Ll]*)
        # For the Intel NUC and intel mobo pick up the system type from the
        # baseboard product name
        machine=$(dmidecode -s baseboard-product-name)
        ;;
    *)
        # Technically, we can remove the Dell entry above as it is the same as this [default]
        machine=$(dmidecode -s system-product-name) 
        ;;
esac

# if the machine isn't identified then no need to continue with this script, just return to caller
if [[ -z $machine ]]; then 
    echo "Unable to identify the hardware for manufacturer ${manu}";
    debugPause;
    return;
fi 
echo "${machine} Identified";

# Removes Spaces in machine name, works better with path definitions
machine="${machine%"${machine##*[![:space:]]}"}";
# Jeffrey Boulais posted that the above code did not work for his install. He
#  supplied this code as an alternative. If you run in to a problem using my code
#  comment out my code and see if his code works better for your installation. The 
#  only right way is the one that works. Thank you Jeff for your input. 
# machine="$(echo -e “${machine}” | tr -d ‘[:space:]’)"

dots "Verifying we've found the OS disk"
if [[ ! -d /ntfs/windows && ! -d /ntfs/Windows && ! -d /ntfs/WINDOWS ]]; then
    echo "! OS root Not found !";
    debugPause
    return;
fi
echo "Found";
        
dots "Verifying target Arch"
system64="/ntfs/Windows/SysWOW64/regedit.exe"
[[ ! -f $system64 ]] && arch="x86" || arch="x64"
echo "${arch} found";

debugPause

# set osn path names based on the osid set in the FOG WebGui
case $osid in
    5) osn="Win7" ;;
    6) osn="win8" ;;
    7) osn="win8.1" ;;
    9) osn="Win10" ;;
esac

dots "Preparing Drivers"
clientdriverpath="/ntfs/Windows/DRV"
# remotedriverpath="/images/Drivers/$machine/$osn/$arch"
remotedriverpath="/images/Drivers/$osn/$machine/$arch"

debugPause

if [[ ! -d "${remotedriverpath}" ]]; then
    echo "failed";
    echo " ! Driver package not found for ${machine}/$osn/$arch ! ";
    debugPause;
    return;
fi
echo "Ready";

debugPause

[[ ! -d $clientdriverpath ]] && mkdir -p "$clientdriverpath" >/dev/null 2>&1
echo -n "In Progress"

rsync -aqz "$remotedriverpath" "$clientdriverpath" >/dev/null 2>&1

[[ ! $? -eq 0 ]] && handleError "Failed to download driver information for [$machine/$osn/$arch]"

debugPause

# the following code is only valid for Windows 7 operating systems since Windows 8 and beyond
# relies on the unattend.xml section to locate OEM drivers. If you are no longer deploying Win7
# you may exclude this section. 

regfile="/ntfs/Windows/System32/config/SOFTWARE"
key="\Microsoft\Windows\CurrentVersion\DevicePath"
devpath="%SystemRoot%\DRV;%SystemRoot%\inf;";
reged -e "$regfile" &>/dev/null <<EOFREG
ed $key
$devpath
q
y
EOFREG

After that, i ran a new debug task on the 640G2 and manually mount the wrong partition :

[Mon Dec 12 root@fogclient /]# mkdir ntfs
[Mon Dec 12 root@fogclient /]# ntfs-3g -o force,rw /dev/sda1 /ntfs
[Mon Dec 12 root@fogclient /]# ls -lha /ntfs/
total 418K
drwxrwxrwx  1 root root 4.0K May 23  2022  .
drwxr-xr-x 19 root root 1.0K Dec 12 14:02  ..
-rwxrwxrwx  1 root root    1 Mar 19  2019  BOOTNXT
-rwxrwxrwx  1 root root 8.0K Jan 30  2020  BOOTSECT.BAK
drwxrwxrwx  1 root root    0 Oct 19 07:44  Recovery
drwxrwxrwx  1 root root    0 Jan 30  2020 'System Volume Information'
-rwxrwxrwx  1 root root 402K Jun 22  2020  bootmgr
[Mon Dec 12 root@fogclient /]#

As you can see, there is no Windows folder in the Reserved Partition …

After that, i umount /ntfs and ran fog script …

Just after the copy of drivers, i breaked the script (CTRL+C).

* Testing partition /dev/sda1.......................Not found
* Testing partition /dev/sda2.......................Success
Done
* Press [Enter] key to continue
* Preparing Drivers.................................Done
* Preparing Sysprep File............................Done
* Writing Computer Name.............................Done
* ComputerName Set To...............................xxxxxxx
* Set PC To Join The Domain.........................Skipped
....................................
....................................
....................................
....................................
....................................

fog.log deleted ........................ Done !
* Mounting directory................................Done
* Press [Enter] key to continue
^C
[Mon Dec 12 root@fogclient /]# cd /ntfs/
[Mon Dec 12 root@fogclient /ntfs]# ls
BOOTNXT   BOOTSECT.BAK   Recovery  'System Volume Information'   bootmgr
[Mon Dec 12 root@fogclient /ntfs]# cd ..
[Mon Dec 12 root@fogclient /]# umount /ntfs
[Mon Dec 12 root@fogclient /]# ntfs-3g -o force,rw /dev/sda2 /ntfs/
[Mon Dec 12 root@fogclient /]# cd /ntfs/Windows/DRV/
[Mon Dec 12 root@fogclient /ntfs/Windows/DRV]# ls
x86
[Mon Dec 12 root@fogclient /ntfs/Windows/DRV]#

For the test, i have 2 folders on my NAS:/images/Drivers/Win10/HP ProBook 640 G2 :

x86
x64

I think, in the fog.copydrivers, the script who seek the architecture of the 640G2 failling because he select the x86 folder … what do you think about that ?

george1421 · Dec 12, 2022, 5:27 PM

@jonathan-cool well the old script and the new script use the same assumption (guess) that there will only be a /windows directory on the windows “c drive”. So I would expect the same results.

The second bit that I noticed here is you referenced /dev/sda1 (first partition) for your test. Typically that is the uefi boot partition. The windows reserved partition is typically /dev/sda2 (or the second partition on the disk).

Jonathan Cool · Dec 13, 2022, 9:11 AM

@george1421
I created the universal image with VirtualBox.
Her, we can see the table partition on the VM Windows … https://ibb.co/2Y0LS48

We can see a recuperation partition … heh … the culprit ?

Jonathan Cool · Dec 13, 2022, 9:19 AM

I just checked my Windows 10 VM … :

• Win10x64 v1909 Legacy BIOS : 2 partitions : Reserved partition and C partition
• Win10x64 v1909 UEFI : 3 partitions : Partition de récupération, partition EFI, partition C
• Win10x64 v21h2 UEFI : 3 partitions : Partition de récupération, partition EFI, partition C

Jonathan Cool · Dec 13, 2022, 7:37 AM

hi !
To help you to debug the script, i tried a new debug task on another HP laptop (nvme disk) : HP 640 G8 and same problem i think …

 * Testing partition /dev/nvme0n1p1..................Not found
 * Testing partition /dev/nvme0n1p2..................Success
Done
 * Press [Enter] key to continue

 * Preparing Drivers.................................Done
 * Preparing Sysprep File............................Done
 * Writing Computer Name.............................Done
 * ComputerName Set To...............................XXXXX
 * Set PC To Join The Domain.........................Skipped
....................................
....................................
....................................
....................................
....................................
....................................

fog.log deleted ........................ Done !
 * Mounting directory................................Done
 * Press [Enter] key to continue
^C
[Tue Dec 13 root@fogclient /]# ls
bin  dev  etc  images  imagesinit  lib  lib64  linuxrc  lost+found  media  mnt  ntfs  opt  proc  root  run  sbin  sys  tmp  usr  var
[Tue Dec 13 root@fogclient /]# cd ntfs/
[Tue Dec 13 root@fogclient /ntfs]# ls
 BOOTNXT   BOOTSECT.BAK   Recovery  'System Volume Information'   bootmgr
[Tue Dec 13 root@fogclient /ntfs]# cd ..
[Tue Dec 13 root@fogclient /]# umount /ntfs 
[Tue Dec 13 root@fogclient /]# ntfs-3g -o force,rw /dev/nvme0n1
nvme0n1    nvme0n1p1  nvme0n1p2  nvme0n1p4  
[Tue Dec 13 root@fogclient /]# ntfs-3g -o force,rw /dev/nvme0n1p2 /ntfs/
[Tue Dec 13 root@fogclient /]# ls -l /ntfs/Windows/DRV/
total 0
[Tue Dec 13 root@fogclient /]#

george1421 · Dec 13, 2022, 3:49 PM

@jonathan-cool said in Golden W10 21h2 : fog.drivers : wrong partition on HP 640 G2 laptop:

[Tue Dec 13 root@fogclient /]# umount /ntfs
[Tue Dec 13 root@fogclient /]# ntfs-3g -o force,rw /dev/nvme0n1
nvme0n1 nvme0n1p1 nvme0n1p2 nvme0n1p4
[Tue Dec 13 root@fogclient /]# ntfs-3g -o force,rw /dev/nvme0n1p2 /ntfs/
[Tue Dec 13 root@fogclient /]# ls -l /ntfs/Windows/DRV/

The above part is interesting.

On this same system where you have p1, p2, p4 partitions would you run this command lsblk

I find the partition layout to be non standard. Is this layout something that you created by hand, or is Microsoft going bat poop crazy here? The normal partitions are efi, system reserved, c drive, recovery Why would they skip over partition #3 and go to #4 with for the C drive. This is really suspicious design.

Jonathan Cool · Dec 14, 2022, 8:17 AM

@george1421 hi !

[Wed Dec 14 root@fogclient ~]# blkid 
/dev/ram0: UUID="1c9acfae-b3e6-4506-8ccc-4ffbff7bdfce" BLOCK_SIZE="1024" TYPE="ext2"
/dev/nvme0n1p1: LABEL="RM-CM-)servM-CM-) au systM-CM-(me" BLOCK_SIZE="512" UUID="DC7279F37279D32E" TYPE="ntfs" PARTUUID="c449399d-b51e-11ea-accc-08002700f0f8"
/dev/nvme0n1p2: LABEL="System" BLOCK_SIZE="512" UUID="82247DDF247DD69F" TYPE="ntfs" PARTUUID="c449399e-b51e-11ea-accc-08002700f0f8"
/dev/nvme0n1p4: UUID="D43A-493E" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="5a66023c-da39-4836-8e35-07074543bd99"
[Wed Dec 14 root@fogclient ~]#

@george1421 said in Golden W10 21h2 : fog.drivers : wrong partition on HP 640 G2 laptop:

find the partition layout to be non standard. Is this layout something that you created by hand, or is Microsoft going bat poop crazy here?

How i have created my UEFI W10 image ?
I had a W10x64 1909 Legacy BIOS image created with Virtualbox.
I used mbr2gpt tool to convert this image to UEFI with sucess …
After few day, i found a problem : can’t expand the C partition because the EFI partition was at the end of the disk … (because of mbr2gpt ? i don’t know)
I fixed this with gParted and … the time was past …
I cloned this VM and updated it to 21h2 … and voila, we are here ! SO, i totally forgot this point but, in fact, i have a non standard layout partitions sorry for that …

My best chance is to recreate the W10x64 21h2 UEFI image at the beginning, no ?

george1421 · Dec 14, 2022, 1:17 PM

@jonathan-cool said in Golden W10 21h2 : fog.drivers : wrong partition on HP 640 G2 laptop:

First I recommended lsblk not blkid but it did give me enough info.

That non-movable partition 4 will keep the c drive partition from expanding.

My best chance is to recreate the W10x64 21h2 UEFI image at the beginning, no ?

The easy answer for me to say is yes, you should rebuild it.

The why is a bit harder to explain but the sins of the past are now slowly dragging you into a fiery pit of hell.

You manually converted a mbr disk into a gpt disk, and relocated the efi partition to some other location than disk 1 partition 1. UEFI firmware will find the partition because it scans all of the partitions to locate its uefi boot partition.
This efi boot partition is behind the OS partition keeping it from expanding correctly because the EFI partition is not expandable or portable.
You have a non microsoft standard disk layout
You upgraded from 1909 to 21h2, that’s 5 OS generations different. In place upgrades always have strange issues (in my experience). 21h2 is a completely different OS than 1909, yes they are windows 10 but under the hood everything is different.

I think you would be best served by starting clean once again, with all of the current patches and applications for your organization. I know it will take time to recreate your golden image but I think a redo is the best answer.

NOW TO THE CAVEAT, if 21h2 is doing something different with the disk partitions and adding more windows directories its possible that even after you rebuild a clean 21h2 disk, the script may still fail.

Jonathan Cool · Dec 14, 2022, 1:32 PM

@george1421
Many thanks @george1421 for your help and explanation.
I have learned many things these days
I’m sorry for wasting your time on this problem …

i will totally recreate my Golden 21h2 image and will be back to show you the results.

“NOW TO THE CAVEAT, if 21h2 is doing something different with the disk partitions and adding more windows directories its possible that even after you rebuild a clean 21h2 disk, the script may still fail.”

The script have not tested on 21h2 ?

Thank again

george1421 · Dec 14, 2022, 2:39 PM

@jonathan-cool said in Golden W10 21h2 : fog.drivers : wrong partition on HP 640 G2 laptop:

The script have not tested on 21h2 ?

I have not personally tested the script with 21h2 (I think). Either way I think you will be in a better starting point with a clean install.

lukebarone · Dec 14, 2022, 11:36 PM

@george1421 My driver injection script (which I believe is the “new” one above) works with 21H2 golden images on both Windows 11 and Windows 10.

Jonathan Cool · Dec 16, 2022, 2:17 PM

@george1421 hi
I just fully reinstall W10 21h2 using ISO …
In audit mode, my layout partition : https://ibb.co/64qWwWc
It’s a good layout ?

Thank you

Jonathan Cool · Dec 16, 2022, 10:14 AM

@lukebarone Thank you for your feedback

george1421 · Dec 16, 2022, 2:17 PM

@jonathan-cool That layout is more normal. Did you make that layout or did the windows installer do that? I might expect 4 partitions but only see 3. But that layout looks better.

make sure you are using the fog version from the dev branch (1.5.9.200 or later) and that image should deploy and resize correctly.

Jonathan Cool · Dec 16, 2022, 3:22 PM

@george1421 hi;
I just pushed the ISO into a new VM and ran the installer … with new dynamic hard drive (vdi).

Upload to FOG is in progress … i cross fingers

Golden W10 21h2 : fog.drivers : wrong partition on HP 640 G2 laptop

247

12.0k

17.3k

155.2k