3 ms·

Hey Kenton! I figured you had done something similar with the LAN Party House. If I hadn't figured it out I was going to ask/look for your setup. > You observ

Hey Kenton! I figured you had done something similar with the LAN Party House. If I hadn't figured it out I was going to ask/look for your setup. > You observed some slowness using Windows over the network. Mini-ITX makes it a bit difficult to upgrade to 10GbE (only one PCIe slot!), and the slowness isn't bad enough in-game to deal with upgrading it just yet. > BTW, a frustrating thing: The Windows 10->11 updater also seemingly fails to include network drivers and so you can't just upgrade over iSCSI. I've read (and also observed, now) that if you install directly on iSCSI Windows doesn't make the recovery partition. This evidently also breaks 10->11 upgrades.

kentonv 2y ago
Oh, maybe the lack of recovery partition is my real problem, because I definitely deleted mine. The installer isn't really clear why it's failing, it just does its thing for a bit and then reboots into Windows 10 and says it didn't work, no explanation.
- fuzzfactor 2y ago
  Things like this iPXE have a similarity to multibooting to where you may be a lot better off NOT having a (single) dedicated Recovery partition at all, but you need full responsiveness to Windows Update. And please no hibernation for multibooting. POWERCFG /H OFF. For recovery manipulation you need to utilize the REAGENTC command, and take advantage of the existing default C:\Recovery folder. Normally this is not considered the best location for "recovery" since if C: gets borked so does default recovery console. And this really gives an example of essential use of inbuilt Helps. On a mainstream system all you have is a single (hidden) ESP volume containing its EFI folder: In admin CMD, type Bcdedit /Enum All to show all your boot entries. If "recovery" is even set up, there will be a Boot Loader entry where the Device is a Ramdisk. If so there will also be a volume letter in square brackets if the target volume is unhidden at the time. But for those of you with no recovery set up, you get to do it yourself as you see fit. Type Reagentc /info, it will confirm recovery is disabled. Reagentc /? gives you the next clue, the example /setreimage. Copy the displayed REAGENTC.EXE /setreimage /? from the display down to the active command line (or just type it in). You get two syntax examples, it's the second one. But you probably don't even have an R: volume and you want to use C: anyway to make Windows more self-sufficient from its own partition. edit it so: REAGENTC.EXE /setreimage /path c:\Recovery\WindowsRE /target C:\Windows After this operation is successful, there is still no apparent change under Reagentc /info, recovery is still disabled. And your BCD remains unchanged with no ramdisk object yet. "Reagentc /enable" will then autoadd the ramdisk recovery bootentry to the BCD, directing the recovery routine (when triggered) to point to your C: volume which will always exist accessibly, plus most likely have enough free drive space to accommodate the larger updates to the recovery WIM files themselves, which are recently giving users show-stoppers when their dedicated factory recovery partitions were not big enough for that. Now for the good news. Once you find a ramdisk recovery bootentry in your BCD, an easy baby-step toward multibooting is a piece of cake. Everybody already has a Windows boot menu that you are using every time you boot, it is simply not displayed if there is only one entry, like most factory set ups. So add the Recovery Console to the menu your dang self. It can come in really handy. From the Bcdedit output text, copy the shown GUID for the main ramdisk recovery object, so you can paste afterward and don't have to type it all into the following command: bcdedit /displayorder {your-guid-here} /addlast Then if you don't want to maintain the default 30 second timeout before progressing to the default OS on the bootmenu, set it for something like 5 seconds: bcdedit /timeout 5 That's it. Now if you don't have a touchscreen, you probably would be better off with the "legacy" text menu, for that you would need to change the bootmenupolicy from Standard to Legacy for the GUIDs that have a bootmenupolicy. Bcdedit /set {target-guid-here} bootmenupolicy Legacy. Also remember if using Powershell it's still having trouble with the curly brackets so in every case they need to be quoted like Bcdedit /set "{target-guid-here}" bootmenupolicy Legacy.
xen2xen1 2y ago
God bless you for this sir. I've been wanting to get Windows iscsi boot working, but there's always one more thing. Did you get anything else fun working with ipxe? all the exampled online seem so outdated.
- terinjokes 2y ago
  Since the goal was just to have non-virtualized Windows to satisfy game developers, I haven't tried much else. Sorry. > all the exampled online seem so outdated. Many of the guides felt like they've been only slightly dusted since the Windows XP days. I've seen none that even hinted at making the DVD ISO a target, leading me to believe it wasn't well supported 20 years ago.
  - wolrah 2y ago
    > I've seen none that even hinted at making the DVD ISO a target, leading me to believe it wasn't well supported 20 years ago. One of the most underrated things about UEFI in my opinion is how it made booting simple. No longer did you need to use special tools (or arcane knowledge) to stick a special real-mode binary in to a normally hidden area of your intended media, now you just drop a few PE binaries in a filesystem your UEFI can read and let it figure itself out. I just created a bootable restore image for one of my clients and it's literally a zip file that can be extracted in to the root of a FAT32 disk drive and will boot on any x86-64 UEFI PC, with Secure Boot fully operational. No special tools required, just drop files on any disk using a filesystem any computer that matters can read/write.
    - lmz 2y ago
      I guess for removable media that's fine, but Windows still likes to hide the ESP.
      - wolrah 2y ago
        > I guess for removable media that's fine, but Windows still likes to hide the ESP. It's not hidden, it's shown in disk management, it's just not mounted by default. IMO that is perfectly reasonable considering 99.999% of users will never want or need to do anything with it and those who do want/need to access it should have no problem finding a single well-documented command. For everyone else it's just a "delete system32" level temptation to do something stupid that'll break their system. mountvol <letter>: /s I honestly have no idea what it'll do if multiple EFI system partitions are present though. I presume this command will mount the one Windows has booted from.
xen2xen1 2y ago
Also interesting using it as an EFI executable. Remind me to start adding that to the menu of ... well, everything.

kentonv 2y ago

Oh, maybe the lack of recovery partition is my real problem, because I definitely deleted mine. The installer isn't really clear why it's failing, it just does its thing for a bit and then reboots into Windows 10 and says it didn't work, no explanation.

fuzzfactor 2y ago
Things like this iPXE have a similarity to multibooting to where you may be a lot better off NOT having a (single) dedicated Recovery partition at all, but you need full responsiveness to Windows Update. And please no hibernation for multibooting. POWERCFG /H OFF. For recovery manipulation you need to utilize the REAGENTC command, and take advantage of the existing default C:\Recovery folder. Normally this is not considered the best location for "recovery" since if C: gets borked so does default recovery console. And this really gives an example of essential use of inbuilt Helps. On a mainstream system all you have is a single (hidden) ESP volume containing its EFI folder: In admin CMD, type Bcdedit /Enum All to show all your boot entries. If "recovery" is even set up, there will be a Boot Loader entry where the Device is a Ramdisk. If so there will also be a volume letter in square brackets if the target volume is unhidden at the time. But for those of you with no recovery set up, you get to do it yourself as you see fit. Type Reagentc /info, it will confirm recovery is disabled. Reagentc /? gives you the next clue, the example /setreimage. Copy the displayed REAGENTC.EXE /setreimage /? from the display down to the active command line (or just type it in). You get two syntax examples, it's the second one. But you probably don't even have an R: volume and you want to use C: anyway to make Windows more self-sufficient from its own partition. edit it so: REAGENTC.EXE /setreimage /path c:\Recovery\WindowsRE /target C:\Windows After this operation is successful, there is still no apparent change under Reagentc /info, recovery is still disabled. And your BCD remains unchanged with no ramdisk object yet. "Reagentc /enable" will then autoadd the ramdisk recovery bootentry to the BCD, directing the recovery routine (when triggered) to point to your C: volume which will always exist accessibly, plus most likely have enough free drive space to accommodate the larger updates to the recovery WIM files themselves, which are recently giving users show-stoppers when their dedicated factory recovery partitions were not big enough for that. Now for the good news. Once you find a ramdisk recovery bootentry in your BCD, an easy baby-step toward multibooting is a piece of cake. Everybody already has a Windows boot menu that you are using every time you boot, it is simply not displayed if there is only one entry, like most factory set ups. So add the Recovery Console to the menu your dang self. It can come in really handy. From the Bcdedit output text, copy the shown GUID for the main ramdisk recovery object, so you can paste afterward and don't have to type it all into the following command: bcdedit /displayorder {your-guid-here} /addlast Then if you don't want to maintain the default 30 second timeout before progressing to the default OS on the bootmenu, set it for something like 5 seconds: bcdedit /timeout 5 That's it. Now if you don't have a touchscreen, you probably would be better off with the "legacy" text menu, for that you would need to change the bootmenupolicy from Standard to Legacy for the GUIDs that have a bootmenupolicy. Bcdedit /set {target-guid-here} bootmenupolicy Legacy. Also remember if using Powershell it's still having trouble with the curly brackets so in every case they need to be quoted like Bcdedit /set "{target-guid-here}" bootmenupolicy Legacy.

xen2xen1 2y ago

God bless you for this sir. I've been wanting to get Windows iscsi boot working, but there's always one more thing. Did you get anything else fun working with ipxe? all the exampled online seem so outdated.

terinjokes 2y ago
Since the goal was just to have non-virtualized Windows to satisfy game developers, I haven't tried much else. Sorry. > all the exampled online seem so outdated. Many of the guides felt like they've been only slightly dusted since the Windows XP days. I've seen none that even hinted at making the DVD ISO a target, leading me to believe it wasn't well supported 20 years ago.
- wolrah 2y ago
  > I've seen none that even hinted at making the DVD ISO a target, leading me to believe it wasn't well supported 20 years ago. One of the most underrated things about UEFI in my opinion is how it made booting simple. No longer did you need to use special tools (or arcane knowledge) to stick a special real-mode binary in to a normally hidden area of your intended media, now you just drop a few PE binaries in a filesystem your UEFI can read and let it figure itself out. I just created a bootable restore image for one of my clients and it's literally a zip file that can be extracted in to the root of a FAT32 disk drive and will boot on any x86-64 UEFI PC, with Secure Boot fully operational. No special tools required, just drop files on any disk using a filesystem any computer that matters can read/write.
  - lmz 2y ago
    I guess for removable media that's fine, but Windows still likes to hide the ESP.
    - wolrah 2y ago
      > I guess for removable media that's fine, but Windows still likes to hide the ESP. It's not hidden, it's shown in disk management, it's just not mounted by default. IMO that is perfectly reasonable considering 99.999% of users will never want or need to do anything with it and those who do want/need to access it should have no problem finding a single well-documented command. For everyone else it's just a "delete system32" level temptation to do something stupid that'll break their system. mountvol <letter>: /s I honestly have no idea what it'll do if multiple EFI system partitions are present though. I presume this command will mount the one Windows has booted from.

xen2xen1 2y ago

Also interesting using it as an EFI executable. Remind me to start adding that to the menu of ... well, everything.