System partition is not the first UEFI boot entry after successful install

[skyblaster]

Describe the bug After successful install via OSDCloud, the {bootmgr} UEFI Firmware entry is pointing to a stale volume (non-existent volume 7 in my testing). This results in UEFI searching for a valid boot entry. On various Dell systems in particular, this means hitting the "HTTPS Boot" menu if it is not disabled (enabled by default). This is resolved by pressing OK and allowing UEFI to find the next valid boot entry, which is hopefully the System partition.

To Reproduce Steps to reproduce the behavior:

1. Boot a Dell Latitude 3420/3520 with an OSD 23.3.29.1 created Universal WinPE / WinRE
2. Run Start-OSDCloudGUI and step through install
3. Reboot to HTTPS Boot menu

Expected behavior Boot to Windows Boot Manager (volume 2 in my testing)

Screenshots https://pbs.twimg.com/media/FaowiCnVEAAp19N?format=jpg

Proposed Resolution As per instructions here, decide where in the installation process to run the following commands.

diskpart.exe
select disk 0
list volume
select volume 2   // assuming volume 2 is the system partition
assign letter=s

I've only tested this once, but it appears to fix the issue. It changes the {bootmgr} device path from "partition=\Device\HarddiskVolume7" to "partition=S:"

Perhaps there is a cleaner method using a single BDCEdit command.

[skyblaster]

Since I suck at git, I'll just link this: https://github.com/OSDeploy/OSD/commit/61d9983a84e5428c27de60e8c8abb68b25d63ce2

I think this is the relevant code currently in use. Will test tomorrow.

[skyblaster]

Sorry for the screen glare, but my edit to Diskpart-FormatSystemPartition.ps1 is unnecessary as illustrated below.

In troubleshooting with diskpart/list volume, the S drive letter remains intact until Get-WindowsEdition is called. Then it is dropped for some unknown reason.

[OSDeploy]

Confirmed, System partition is mapped to S: as detailed in New-OSDPartitionSystem

[skyblaster]

Commenting lines 1087 and 1091 in OSDCloud.ps1 does the trick with regards to solving the original issue.

$SystemDrive | Remove-PartitionAccessPath -AccessPath "S:\"

Running diskpart/list volume again from OOBE doesn't show the letter, so I won't begin to understand when or why it's necessary.

EDIT: Upon further testing. All I can say is: 60% of the time, it works every time.

[OSDeploy]

Running diskpart/list volume again from OOBE doesn't show the letter, so I won't begin to understand when or why it's necessary.

Maybe I should have taken better notes and added them to the script, but removing the S: partition was necessary when I created this file, possibly for certain versions of WinPE10 had issues where S: was still visible after reboot, if I remember correctly. I'm not open to removing those two lines unless I can fully confirm there won't be any issues, and that will take some time testing previous versions of WinPE and previous versions of Windows

[skyblaster]

Eeek. I think your latest commit foiled my testing. EDIT: Scratch that. I'm still using OSD 23.5.18.1

Essentially my solution would have been to simply add the following line before nuking the S: volume mount.

In CMD: bcdedit /set {bootmgr} device partition=s:

or in PS:

bcdedit /set '{bootmgr}' device partition=s:

[skyblaster]

For reference, my reference was this: https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/bcd-system-store-settings-for-uefi

[skyblaster]

I've yet to test the new bcdboot options, but after reading the documentation, the command looks sound.

You may want to consider adding a /p switch for those who may have existing grub2 or rEFInd boot loaders in place....or simply for those who want to preserve their existing boot order.

[OSDeploy]

Solution:

[OSDeploy]

Closing this issue as complete with the latest release of OSD