bob prohaska  wrote:
> Theo  wrote:
>>
>> If the drive is USB I'd be looking at Qemu's USB passthrough at a minimum: I
>> doubt WINE would support such access.  However, given the risk of bricking
>> the drive if the firmware upgrade goes wrong, I would much prefer to do this
>> on a real Windows box.  Much less chance of something breaking halfway
>> through.
>
> Yes, the drive is USB. I agree completely that using a native Windows box is
> best, but I don't have one.
>
> Apt search reports a bunch of qemu-related packages, one of which is called
> qemu-system-arm/stable 1:3.1+dfsg-8+deb10u8 armhf
>  QEMU full system emulation binaries (arm)
>
> Would that be the package to try? It's unclear to me if -arm refers to
> the host architecture or the emulated architechture....

Unless you've put other architectures in your /etc/apt/sources.list
(or associated files), then you should only be seeing packages for
ARM host architecture. That one presumably applies to running ARM
emulation on ARM, "armhf" at the end indicates that it's an ARM
package.

But I'd agree with others here that the odds of this all working are
very much against you. WINE and QEMU are both extra layers that have
pretty dodgy support for what you're doing. WINE's hardware USB
support isn't clearly documented, but might be mainly geared at
things like game controllers which are HID devices. HIDs work more
simply than other USB devices like your HDD.

If you set up a real Windows installation in QEMU, that gives you
a bit more likelihood of success, but I still wouldn't bet on it.

--
__          __
#_ < |\| |< _#

--- SoupGate-Win32 v1.05