-
Notifications
You must be signed in to change notification settings - Fork 619
Open
Labels
issue-doc-bugSomething is out of date, unclear, confusing, or broken in the article. Blocks customer success.Something is out of date, unclear, confusing, or broken in the article. Blocks customer success.needs-triageWaiting - Needs triageWaiting - Needs triage
Description
Prerequisites
- Existing Issue: Search the existing issues for this repository. If there is an issue that fits your needs do not file a new one. Subscribe, react, or comment on that issue instead.Descriptive Title: Write the title for this issue as a short synopsis. If possible, provide context. For example, "Typo in
Get-Foo
cmdlet" instead of "Typo."Verify Version: If there is a mismatch between documentation and the behavior on your system, ensure that the version you are using is the same as the documentation. Check this box if they match or the issue you are reporting is not version specific.To pick up a draggable item, press the space bar. While dragging, use the arrow keys to move the item. Press space again to drop the item in its new position, or press escape to cancel.
Links
Summary
Could you please add an example showing how to use Set-VMFirmware
to add a VMBootSource firmware path?
Details
For example, I have a bootable Gen2 (UEFI) VM where I installed Debian that has the firmware path pointing to the debian shimx64.efi
:
PS C:\Windows\system32> (Get-VMFirmware -VMName gen2-debian-test).BootOrder | Where-Object { $_.BootType -eq 'File' } | Select-Object -ExpandProperty FirmwarePath
HD(1,GPT,FFB61BB9-ADBE-49BC-BCE8-22AF4F699210,0x800,0x100000)/\EFI\debian\shimx64.efi
PS C:\Windows\system32>
I want to add a similar setting to another new Gen2 VM, but I am having trouble figuring out how to do that.
I know the disk identifier, but I just can't figure out how to set the firmware path using Set-VMFirmware
.
Suggested Fix
Add an example showing how to set firmware path to EFI shim, please.
websafe and luckylinux
Metadata
Metadata
Assignees
Labels
issue-doc-bugSomething is out of date, unclear, confusing, or broken in the article. Blocks customer success.Something is out of date, unclear, confusing, or broken in the article. Blocks customer success.needs-triageWaiting - Needs triageWaiting - Needs triage
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
websafe commentedon Jan 5, 2025
+1
luckylinux commentedon Jan 15, 2025
@atsaloli : same Problem at work on a Windows 11 Workstation Laptop with HyperV Manager.
I was trying to use these Powershell Commands to basically "clone" a Template Archive containing a Folder Structure generated from
Export-VM
(and.vhdx
Hard Disk,.vmcx
Configuration, etc).I also was pulling my Hair out to be honest for a few Hours 😕 .
To be fair, at least for MY Case/Issue based on MY Experience (i.e. Importing a Virtual Hard Drive Image using
Add-VMHardDiskDrive
into the newly created VM that was setup usingNew-VM
), it's actually NOT needed to add thisVMBootSource
Entry by Hand.Maybe it's just not possible. Or it's automatically detected by HyperV Manager. Or these
NVRam
Objects are setup duringgrub-install
orupdate-grub
. Not sure why it just automatically detected it after 1 Startup (and possibly 1 Shutdown).I also attempted to copy the Object that was present in the
.vmcx
Configuration File (you need to analyze it usingCompare-VM -Copy -Path
if you want to go down that Rabbit Hole) but of course it has the wrong$VM.Id
and$VM.Name
associated with it. And trying to modify those yields aRead Only Property
Error.What worked (nothing special really):
New-VM
Add-VMHardDiskDrive
(I just setup the VM Hard Drive as the only Boot Device for the VM)
As soon as I booted the newly created System (Ubuntu 24.04 AMD64 VM), the
File
Type Bootentry was automatically created/detected pointing to the sameshimx64.efi
File. No boot Issues at all (I was actually surprised by this). Strangely the Template had 2File
asVMBootSource
pointing to 2 differentshimx64.efi
Files / Partition IDs. The New VM only had 1. Well, it seems to work anyways 🤣 .I know this is not really answering your Question (or mine) 😞. But this is what I could observe at least. Secure Boot was ENABLED as per the Source/Template VM. Both Template and New VM are of Generation 2.
Anyways, it seems to "just work" (knock on Wood), at least like this.
ViliusS commentedon Jul 5, 2025
I was in the similar boat. Had CentOS upgraded to Rocky Linux which left an old Hyper-V UEFI entry pointing to the CentOS EFI binaries. I've banged my head to various Microsoft documentation, until I found that all these entries can be created from the guest OS.
In order to create new UEFI entries on Rocky Linux use:
efibootmgr -c -L 'Rocky Linux' -l '\EFI\rocky\shimx64.efi' -d /dev/sda
You might need to use
-p
and adjust other options for your needs.One thing to note is that due to limited Hyper-V UEFI support you won't be able to modify these entries, but creation of new and deletion of old ones would work just fine.