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

[george1421]

@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]

@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]

@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.

1. 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.
2. This efi boot partition is behind the OS partition keeping it from expanding correctly because the EFI partition is not expandable or portable.
3. You have a non microsoft standard disk layout
4. 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]

@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]

@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]

@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]

@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]

@lukebarone Thank you for your feedback

[george1421]

@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]

@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

[Jonathan Cool]

Hey !
I’m back … with some good news : it’s works !
After deployed the new 21h2 clean image, i can see the C:\Windows\DRV\x64 on the 640G2 !
Youpiiiiiiiiiiiiiii … but … the script fog.copydrivers can used .CAB with DELL or not ?
Because i tried to deploy my 21h2 clean image on a o7050 … and no DRV folder after deploy … maybe we need just use x64 folder for all machines instead of .CAB for DELL now ?

#!/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 $osn/${machine}/$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