-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
System partition is not the first UEFI boot entry after successful install #59
Comments
Since I suck at git, I'll just link this: 61d9983 I think this is the relevant code currently in use. Will test tomorrow. |
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. |
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 |
Eeek. I think your latest commit foiled my testing. Essentially my solution would have been to simply add the following line before nuking the S: volume mount. In CMD: or in PS: bcdedit /set '{bootmgr}' device partition=s: |
For reference, my reference was this: |
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. |
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:
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.
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.
The text was updated successfully, but these errors were encountered: