Can I backup current emulator state - corrupted memory stick

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