Can I backup current emulator state - corrupted memory stick

CaptRobovski

Hello all,

I've been a follower of these forums for years but have come unstuck on an issue with a memory stick. I'm hoping that I might be able to get some help here! :)

I have Retropie setup on a Raspberry Pi 5 running Raspbian Bookworm. I have the OS running off the SD card and all the roms are stored on a USB memory stick. I followed the guide in the Retropie docs for this so it automatically mounts at boot.

From my phone, I can access the Pi via SSH and FTP.

It's been mostly running OK for around a year - occasionally I have to reboot for EmulationStation to pick up the roms. I put that down to the Raspberry Pi 5 support still not being 100%.

Unfortunately, I have a problem with the memory stick. The Pi can find and load the roms, but it cannot write any data to it. This means that any time we quit a game, any progress is erased. It's no longer able to create emulator-based save states or the battery backed saves you would get on cartridges of yore.
I think the drive is toast - Kingston are going to replace it under warranty. The problem is, they need a serial number printed on the USB plug of the drive, which means unplugging it from the Pi.

My kid has completed Yoshi's Island on the SNES and is halfway through trying to get the bonus levels. It's not a challenge I've ever had the stomach for! So if we quit to Emulation Station or the Pi is turned off, we'll lose all the progress.

Is there any way I can backup the current state of the drive, or the SNES emulator so we can restore it later on a new drive? Any temp files?

What I've tried so far:

I've tried to access the drive from ssh and FTP and it's not recognised at all. It doesn't show up. I believe the roms were stored in ~/RetroPie/roms, but exploring via FTP it shows a count of 0 files. Under SSH it shows nothing when I ls -a the directory.

With the Pi powered off, I unplugged the stick and tried it on my Macbook Pro - in the System Report tool (closest thing to Windows Device Manager), and it didn't even show up on the USB bus.

It's very strange, because once a game is running on the Pi it's absolutely fine - N64 and SNES are great. So the Pi itself must be able to read it, just not write to it. And other users can't see it via ftp or ssh, as if it's hidden or locked. And other devices can't see it at all.

Any help would be really appreciated! When I get another drive, I'll look into automatic backups to another server I think!

Thanks in advance

sugarfree

You can try to change the save paths from the RetroArch menu and save the changes for the game or core with an override.
https://docs.libretro.com/guides/change-directories/#

CaptRobovski

@sugarfree thanks, I wondered about that. However, does the emulator need to be reloaded before the config change takes effect?

sugarfree

@CaptRobovski I believe so. By the way, save files are created when you choose to exit the emulator. Before that, they are stored in the
memory.

CaptRobovski

@sugarfree sounds like I'm going to be out of luck then :(

Can't back up the current memory, as I don't think you can really do that unless you're a dab hand with forensic style tools (I'm certainly not!)

Would hot swapping the flash drive possibly work? As in, if I remove the drive and plug in a different one, would RetroArch write to it on exiting the emulator? Or is the mount restricted to a specific disk identifier?

CaptRobovski

Kingston have supplied a new memory stick under warranty and I'm wondering if I'm able to hot swap it for the old one?

If I run df at the terminal, the original stick doesn't show up at all.

Do I need to configure the new stick with the correct UUID or anything for it to pick it up?

CaptRobovski

I've just checked again - the first line of output from df was:

pistation@pistation:~ $ df -h
df: /media/usb0: Input/output error

sugarfree

@CaptRobovski
Your issue is very strange. How is it possible for the system to run the ROMs but not have them be visible? Did you try accessing the files from Midnight Commander or Samba share? https://retropie.org.uk/docs/Transferring-Roms/"

CaptRobovski

@sugarfree aha! That's a great shout!

Sorry for the delay in replying - been a busy week and just had time to try.

In this time, the Pi has crashed once or twice, so the original desire to save progress is now a lost cause. However, I'm hoping I can copy the contents of the USB off onto another, so I can keep srm and roms at least.

I have a feeling that this may be a combo of:

A failing USB drive.
A permissions problem.

With the second one, I did all setup via ssh, including downloading roms. It worked without issues for ages, but I'm wondering if somehow there's ended up being a conflict where the ssh user can't see the contents of the drive, but the user for retropie can.

It may be in reality the same user...! 🙈 I use Linux a bit for web work, but I'm not great at all the stuff for using it as an actual computer.

The other thing that makes me think it could be permissions/access is I have been trying to get a Dualshock 4 controller to connect via Bluetooth. If I ssh into the Pi and run the retropie_setup script as per the guidance, it can connect to the controller, but not do anything in Emulation Station. Running it with ds4drv doesn't work either.

Then I tried to do the same from the Emulation Station front end (Retropie > Retropie Setup) and it worked flawlessly. I can control everything with the Dualshock 4 without any further setup.

So I've tried to access the USB stick via Emulation Station frontend too. Retropie > File Manager. They're all there!

Then on to point 1 above - after around 5 minutes in the file manager I started getting error messages. Have taken a couple of photos of them, as I wasn't able to copy any output. Lots of blocks failed. Lots of references to error - 71.

photos of error messages

I'm using an official Raspberry Pi 5 power supply and only have the USB stick and Bluetooth running, so I don't think there's any power issues going on.

Thank you again for your help and advice here!

sugarfree

I believe that the flash drive is failing and should be replaced. Some of the data may be corrupted. You can try to repair it with controversial results, but you have to unplug/unmount it first.

Lolonois

You noted you have a official Rpi power supply. Is it rated 3A or 5A?
--> https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#maximum-power-output

If it is a 5A power supply, underpowering is out of the mix.

Then, run lsusb and note the USB ids of the Kingston USB device. The USB ID looks like this format 174c:1153, which is VendorId:ProductId.

It is a wild guess from the distance, but I assume it might be a faulty implementation of the USB power suspend (of the device).

To work around this inhibit power suspend for the Kingston device (power/control=on) [1]

To testdrive if it solves your issue:

sudo su
echo -1 > /sys/module/usbcore/parameters/autosuspend

However, this will not survive a reboot.

To persist it:
Put a udev rule below /etc/udev/rules.d/, e.g. 99-kingston-power-control with the content (unverified):

ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="174c", ATTRS{idProduct}=="1153", TEST=="power/control", ATTR{power/control}="on"

Read: Whenever a usb device is added which has the vendor and product id and has the attribute of power/control to set it to on.
Replace the values for idVendor and idProduct with the values from the Kingston.
You can find a little context for example here [2] and the udev spec here [3].

Restart the udev system sudo udevadm control --reload

HTH

[1] https://www.kernel.org/doc/html/v6.14-rc7/driver-api/usb/power-management.html#the-user-interface-for-dynamic-pm
[2] https://hackology.co.uk/2015/selective-usb-power-saving-linux-laptop/
[3] https://wiki.archlinux.org/title/Udev