I'm wondering if this is even worth reporting at this point, since they have moved on and this is probably an extreme corner case. Anyway.... The 6000 and 7000 series AMD based handheld consoles have mini-SD card ports. You can create a bootable SD card with the Windows 10 installer on it, it boots just fine but there is bug at some point where a hand off occurs and the installer loses track of the driver needed to talk to the SD card. Obviously I have all of the drivers integrated into the boot.wim and install.wim files (first thing I tried) and manually navigating to the needed drivers on a different drive does let the installer see he SD card again and complete the install without issue. I looked into this some more and found the needed driver on the X: drive so the installer already has everything it needs to see the SD card, it just wants you to hold its hand and navigate to that driver. In my case its X:\Windows\System32\DriverStore\FileRepository\rtsper.inf_amd64..... I was attempting to set this up so I could leave a SD card permanently installed with both game backups and an OS installer so that if I ever had a serious system issue, I could quickly get back to normal without even needing an internet connection or flash drive.
I keep this image updated with drivers and updates to avoid post install work. Integrating new drivers and updates is pretty easy. Keeping an entire VHD up to date is a lot of work. "Do it differently" to dodge a Windows bug is a pretty Windows way of dealing this though.
That's one of the reasons I use only native vhds, everywhere. It's way faster to update/integrate/customize a vhd than doing the same thing on an ISO. Just boot it inside Hyper-V update it, and (if needed) sysprep it Alternatively you can dual boot it, and enter in audit mode, to avoid the annoying sequence of creating an user, doing your work, then sysprep/generalize. To start a fresh OS just copy it in place of the old one (from SD to internal storage in your case)
Ok, better than nothing, but still something that involves a bunch of unneded steps. Let assume you want to update your image to the current CU (which is a pointless operation in its own) You need to #1 mount your wim (which takes time) #2 use dism to add the LCU (which takes time) #3 commit the changes (which takes time) (i'm omitting reset base, and export wim for simplicity, but both take time) #4 when needed you need to boot from WinPE (or from a parallel system) to dism /apply the wim on a partition or a native vhd) which takes time. The same procedure using the native vhd #1 Boot the system in audit mode (which takes 15 seconds on a modern system) #2 launch WU and let it do its job (which takes time, but WU is working, not you) #3a if you launched the vhd from the SD you are done #3b if you copied the vhd on internal storage you need to copy the file back to SD (which takes 1/2 minutes depending how fast is your SD) #4 When needed, you need just to copy it back and boot. So evaluate yourself which of the two procedures is faster and more convenient
You do remember that I literally posted a bug thread, right? I don't think you have mentioned the actual bug once. I know you need this so yes, you are super good at setting up windows.
Ok it's a bug, what do you expect that a random user magically fixes it w/o even owning the HW involved? I suggested a way to workaround a bug, which as a "byproduct" involves a hugely better way to manage the installations. Now you can choose to test personally what I suggested and learn something new or continue to moan about a problem that maybe will be solved in two years. It's up to you.