> You probably want to remove the disks anyways so Windows doesn’t install its boot manager to an EFI System Partition on a local disk. To boot with iPXE later, you’ll want Windows to create an EFI System Partition on the iSCSI disk. ↩
Oh the frustrations I’ve had with Windows and more than one disk during install. For months I had Windows installed on SSD, except the bootloader was on a HDD. I didn’t even realise till I removed the HDD and got the familiar no boot drive found.
Turns out if a drive has Windows on it, and then you decide to install Windows on a new drive, it will detect that bootloader on the old drive and use that. Instead of putting it on the drive you just asked it to install Windows to.
Lesson learned here is always unplug any other drives when installing Windows!
When you install it to a system with other partitions or drives that are accessible, it silently autoencrypts them all using Bitlocker which is now on by default.
It's not too bad unencrypting your C: volume afterward with a few clicks, but if you don't have a Microsoft Account then you won't have a readily available key (to type in) or easy decryption option for the other volumes. It can be a lot easier to reformat and recover those non-C: volumes from backup than bother to decrypt, you've got to virtually overwrite the entire drives anyway :(
Simply installing the latest Windows is definitely more likely to be the direct cause for loss of more gigabytes than most malware I've seen.
I assign the standard Linux GUIDs on non-Windows volumes to be sure, as appropriate even though the regular "Basic Volume" GUID is often found since it works "for all".
The standard Linux Partition_type_GUIDs as shown in Wikipedia (please refer to it) after expanding ("show") the condensed table:
4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709 for the OS root
0FC63DAF-8483-4772-8E79-3D69D8477DE4 for data
8484680C-9521-48C6-9C11-B0720656F69E for usr
0657FD6D-A4AB-43C4-84E5-0933C84B4F4F for swap
These can be SET ID from Windows, plus you can set GPT Attributes to hidden and/or readonly temporarily because it is getting more difficult to trust Windows so that's why I'm experimenting so much.
Also you can safely change the ESP volume GUID from standard to basic, and Windows will most likely still boot normally on many PCs, you can then assign a volume letter to the ESP and after another reboot have full admin access to the ESP and its black pearl, the EFI folder within, from the GUI.
> always unplug any other drives when installing Windows!
Many motherboards and enterprise notebooks have functionality to disable SATA/NVMe ports, so there's increasingly less need to faff with physically unplugging discs.
It's easy when SATA drives are stacked to unplug the ones you want.
It's not easy when M.2 requires removing a heatsink to press the PCI-e unlock to extract the 2 ton GPU to access the primary M.2 slot underneath to use your screwdriver on the screw the size of a PopRock clinging on trying to not shake because it's holding onto the screwdriver with the magnetic force equivalent of a fridge magnet.
Swapping the actual nvme drive out is easy. But then getting that screw back in is even worse than removing it. Sometimes you get lucky and the motherboard is improving the hotswapping capability with the newest yearly reimplementation of a screw with a string on it so if your screwdriver has trouble holding a fridge magnet against the gravity of the earth then the string keeps the screw from phase warping. My favorite has been the rubber peg designs but we're 10 years out from combining the peg with the string tech.
That's when reading the manual to figure out the port numbers to disable in the BIOS makes sense. It just seems like missed opportunity they didn't make M.2 external facing.
Too bad my Lenovo lets me disable the SATA but not NvMe :(
Plus I remember doing this for years under bios until some version of NT6 came along and Windows could access them even when disabled in BIOS on some mainboards.
You really want the Administrative Command Prompt for best functionality.
However, remember if using Powershell instead it's still having trouble with the curly brackets so in every case they need to be quoted in commands, such as this example:
Bcdedit /set "{default}" Description "Win11 23H2 on Dell 512gb SSD part 2"
Which gives a much more useful description than the plain "Windows 11" that exists already on installations otherwise. Even though these "descriptions" never display until there are more than one choice on the bootmenu.
Concentrate on the commands, BCDEDIT, BCDBOOT, and familiarize with DISKPART which opens its own sub-shell to handle drives. When you are done with Diskpart, you have to type "exit" to go back to the regular command line,
Inbuilt Help docs for the regular command prompt are obtained the same old DOS way, for example "bcdedit /?".
As an example, Bcdedit is too complex to learn from the Help messages, and there are hidden sub-help "chapters" which add to the confusion, so learn this one from the internet and its expert examples.
OTOH Bcdboot is straightforward, but either way, to access a particular (naturally hidden) EFI folder (other than the one you are booted from at the time) on a chosen HDD or SSD you would first have to make the volume visible by giving it an alphabetic designator using Diskpart, the ASSIGN command.
Under Diskpart, ASSIGN, "GPT ATTRIBUTES", SETID, ATTRIBUTES are 4 good ones to know even if you are not going to use Diskpart for partitioning.
While in the Diskpart sub-shell, the inbuilt Help docs are accessed their own way, type "help assign" for instance to get Assign syntax examples.
OTOH with the Attributes command, "Help Attributes" only tells you that you need to use "Help Attributes Volume" or "Help Attributes Disk" instead to get the examples you have in mind.
A lot of this stuff I know already but I still use the help docs a lot to copy & paste the syntax examples from the CMD window into Notepad for editing before copying back to execute.
I type `bcdedit /set "{bootmgr}" path \EFI\refind\refind_x64.efi` so many times a year that it's probably getting close to time to buy a macro keyboard so I can set it up on a macro.
I have rEFInd on a USB stick because I need to recover bootloaders on machines often enough. I commented on Lobsters recently the errors I've seen over the years.[0]
systemd-boot installs itself as bootx64.efi (or platform equivalent) if it doesn't already exist, and most motherboards will scan for it, which has reduced how often I need the USB stick.
Oh the frustrations I’ve had with Windows and more than one disk during install. For months I had Windows installed on SSD, except the bootloader was on a HDD. I didn’t even realise till I removed the HDD and got the familiar no boot drive found.
Turns out if a drive has Windows on it, and then you decide to install Windows on a new drive, it will detect that bootloader on the old drive and use that. Instead of putting it on the drive you just asked it to install Windows to.
Lesson learned here is always unplug any other drives when installing Windows!