pikvm
Xbox One doesn't detect virtual drive
I do electronics repair for a living. I do many computers and game systems. Of course, the PiKVM is no-brainer when it comes to computers, but I was curious to see if it would work on an Xbox -- I do a lot of HDD replacements on these machine (and PS4 as well).
So, I made an Xbox OSU (restore) drive image using fdisk/mkfs.ntfs and attempted to attach it to an Xbox in recovery mode. Unfortunately, the Offline Update option never lit up. I assumed that may have screwed up the image when I was making it, but I went ahead and cloned the crafted image onto an actual flash drive and plugged it into the system. The system picked up the physical flash drive just fine and lit up the Offline Update option -- so, it wasn't a malformed image.
I was curious if the PiKVM emulated a USB hub (after all, it has to send keyboard, mouse, drive all via one cable), so I repeated the same experiment using an unpowered USB 3.0 hub. (Flash drive, keyboard, and printer -> USB 3.0 HUB -> Xbox). The Xbox also picked up the flash drive from the unpowered USB hub as well. There has to be some kind of bug that is preventing this from working as expected.
I was using the SuperSpeed port on the Xbox and the flash drive I was using was a Sandisk USB 2.0 drive (didn't have any USB 3.0 drives available).
I lack the required tools to be able to diagnose this properly (a USB protocol analyzer would be super helpful here I would think).
Hello. This is an interesting application. I have a USB analyzer, but no Xbox. If I can get it, I'll try to look at it.
I found another image that has a similar problem, maybe. The image is the Steam Deck recovery image located here. I was trying to use the PiKVM to recover my Steam Deck using the official image, since the device only has a single Type C port and I needed at least a keyboard and the drive and I don't have a Type C hub currently. The PiKVM seemed a perfect fit here too. But, when the image is loaded to the PiKVM and activated, the image fails to boot for an unknown reason. However, the same image on a USB flash drive attached via a USB A-to-C adapter works perfectly fine.
This one is a little less hardware-specific. The Steam Deck is a handheld x86_64 computer with an InsydeH2O BIOS -- a pretty standard setup. One thing that I did notice about this BIOS, though, is that it doesn't detect a USB 3.0 keyboard in the EFI for some reason. I have to plug in a USB 2.0 keyboard to go through BIOS/GRUB menus on it. I don't think that's necessarily related since, I believe, the PiKVM acts as a USB 2.0 hub (and the InsydeH2O BIOS of the Steam Deck does see the disk image to boot from it).
I'm not sure if it's the same problem as the Xbox, but it might be a little easier to test.
I still don't have any of these devices :) But I hope that someday I will have a chance to explore it.
I did a little testing with KVM, looks like I get a similar issue on the Q35/TianoCore combination. At first, I thought KVM was acting as expected when I had the Steam Deck image attached as a USB drive to the VM and it worked (it also works with a physical imaged drive passed through to the VM). However, when I attached the PiKVM composite USB device to the virtual machine using USB passthrough via libusb/Spice (I used virt-manager for this), it hangs just as on the Deck. Since there is no boot logging, hard to say what's actually going on.
Is there any way to log the PiKVM disk activity more than the default to maybe get something useful? In the mean time, I'm going to try to unpack the GRUB image to see if maybe I can enable boot logging.
There is no log activity, for this case I need to use hardware USB protocol analyzer to debug it :/
Yeah, so Plymouth is hiding any logs I think. I'm working on repacking the initramfs to get log messages. It turns out that the kernel is booting, since if you pull out the USB stick a few seconds after booting it will say "Unable to read sector xxxx" (kernel message). So, I just have to set the Plymouth theme to 'details' to get it to show log messages. Unfortunately, SteamOS uses Dracut instead of mkinitramfs, which uses Systemd (and pulls in Plymouth somewhere). Doesn't look like the Dracut-systemd-plymouth reads the rd.plymouth kernel parameters. So, I have to re-pack the special Dracut initramfs to disable it.
OK, so I got a boot log finally, though I actually figured out the issue before I got to that point: the SteamOS recovery image needs to be read-write, rather than read-only. Some systemd units were failing due to not being able to write to the drive (kind of weird for an otherwise "live" system). Of course, by default, the PiKVM mass storage image store is mounted read-only. I was able to bypass the issue by remounting /var/lib/kvmd/msd as R/W and then using the manual command kvmd-otgmsd in order to set the drive (not sure if that was totally necessary, but I do know the web UI changes the read-only status of this partition when, say, uploading a new image).
I actually wasn't able to figure out why it was failing due to the logs alone. I was attempting to move the image to the PiKVM via the MSD connection because it's faster than the WiFi (I don't have mine connected via Ethernet right now). Only then did I realize the key difference between the USB drive plugged in via an adapter and the one provided by the PiKVM -- write access. I did a quick test and, sure enough, my modified image booted. I'm moving the original image over the PiKVM now in order to do a final test (EDIT: It works! But, it only works in read/write mode!)
Though, I am curious if this is also the reason the Xbox was failing. The next time I get an Xbox into my shop, I'm going to try it out.
One thought though: Would it be possible to put an "Allow write" or "Allow R/W" checkbox in the interface? I understand that read-only should be the default for CD-ROM images, but, generally speaking, I don't think read-only is necessary or generally desired for images mounted as a non-CD-ROM. Of course, having the option to change that default on non-CD-ROM could be useful. It definitely might have saved me the large headache had that option been available in the web interface. I feel like if I had seen that option I would have been much more likely to catch the mistake very quickly as I would have been forced to consider that possibility at some point due to the existence of a settable option in the interface. However, since the fact that the MSD mount point is read-only by default isn't made clear within the interface, it was not something that I had even considered until just today!
Excellent investigation. I am glad that the problem has been partially solved.
As for RW access, it is quite difficult to implement, there was a task about it #21, but now it is a low priority.
Damn, thanks Max! I was actually working on implementing this myself for a pull request. I got the switch added to the UI, but there are a lot of interconnected parts in PiKVM and I was still trying to figure out how they all worked together.
Anyway, I saw the "Writable" switch and once I realized that it wasn't mine and tried it out I came here to thank you in advance. But, you beat me to the punch!
Still waiting on an Xbox. I don't see Xboxes for repair nearly as much as Playstations, but I'll be sure to let you know as soon as I am able. It would be strange if this solves the issue, but then again Xbox also requires an NTFS filesystem for recovery so it's all pretty strange.
You're welcome) In fact, I'm also wondering what the problem is with the Xbox.
I got an XBox in a couple of days ago with an HDMI chip issue. I wasn't able to see the screen but I tried the test on it anyway. Typically, when entering recovery mode with the Xbox, you hold the correct buttons and hit the power button. You get one power-on chime followed by two more power-on chimes about 7 seconds later. Then, the recovery menu appears on the screen. Of course, since I haven't go the HDMI chip fixed just yet, can't verify whether it's actually working. With R/W mode enabled, I get the three power-on chimes. However, with R/W off (the default) I get the same three power-on chimes followed rapidly by a power-off chime. So, it seems like R/W mode may have fixed the issue, I just have to wait until I can get the HDMI chip replaced on Monday to get a definitive answer.
Well, no dice. Unfortunately, the customer came to pick it up before I could do thorough testing. In both R/O and R/W mode, the recovery option would show up, but as soon as it's clicked it would just to an E101 error. I did a restore normally before trying this though, so it's possible it could be due to that. Just didn't have a whole lot of time to tinker with it. I'll try again next time. My PiKVM has a new home at the office for the time being until I can dig a little more.
Well, I will wait for news :)
By the way, it would be useful if you specified which xbox of the cheapest models can be used and wrote a small step-by-step instruction on how to reproduce this problem. I've never played on xbox and I'm unlikely to, but I could find an old xbox to test. Just so that I or someone else doesn't have to figure out how to do it.
The only Xboxes I've had the opportunity to try this with have been Xbox One S and One X. The original Xbox One has a different recovery file, so I'm not sure if it behaves the same. I also rarely see original Xbox One consoles; they were replaced fairly quickly with the One S and One X.
The process to restore the console (including making the recovery drive) is located here. The OSU1 file needed for the Xbox is updated every once in a while, so I almost always make a fresh drive when re-installing system software on the Xbox (usually due to HDD failure).
- Create an install disk by formatting a USB drive as NTFS and then extracting the
$SystemUpdatefolder within the OSU1.zip file (found at the link above) onto the root of the drive. Plug this drive into the Xbox. - Boot the Xbox into the Troubleshoot mode by holding Eject, Bind and click the power button while continuing to hold Eject and Bind. The console will do its power-up beep, followed by a delay of about 8 seconds and then two follow-up beeps. After the third beep, release the buttons and the Troubleshoot menu should appear.
- If a correctly formatted USB drive is detected, the section of the menu that says "Offline System Update" should become available (if the disk is incorrectly made/formatted, the menu item will stay grayed out)
- Highlight the "Offline System Update" menu item and press A to start the process.
After step 4, the expected behavior is that the Xbox will install the update for a few minutes, restart, finish the update, and then reboot to the setup screen or the login screen. However, with the PiKVM, when you hit the "Offline System Update" option the machine acts normally at first and seems to start the first phase of the update, but within just a few seconds (maybe 5-10 seconds) the process fails with an error. I thought I got a picture of if, but it appears I didn't.
I believe the error was E101 (An Xbox error is of the form E000 XXXXXXXX XXXXXXXX, where E000 is the major error code and the XXXXXXXX are more specific, but undocumented hexadecimal numbers [memory address/stack frame? who knows]) . The Microsoft troubleshooting for E101 is laughable and basically just reiterates how to make the OSU flash drive. I got the same major error code with both the R/O and R/W modes on the PiKVM (though, I'm unsure if the minor error numbers were the same).
Anyway, at my next opportunity I will try to get more hands-on time with a machine. This particular customer was just very, very eager to get his console back.