Golden W10 21h2 : fog.drivers : wrong partition on HP 640 G2 laptop
-
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 youOther 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 :-)"
-
@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.
-
@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]#
-
@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]#
-
@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
-
@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
x64I 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 ?
-
@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).
-
@george1421
I created the universal image with VirtualBox.
Her, we can see the table partition on the VM Windows … https://ibb.co/2Y0LS48We can see a recuperation partition … heh … the culprit ?
-
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
-
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 /]#
-
@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.
-
@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 ?
-
@jonathan-cool said in Golden W10 21h2 : fog.drivers : wrong partition on HP 640 G2 laptop:
First I recommended
lsblk
notblkid
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.
-
@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
-
@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.
-
@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.
-
@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
-
@lukebarone Thank you for your feedback
-
@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.
-
@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