MiSTer FPGA Forum

Imagine- installing brand new Sanwa parts on your arcade stick and testing in MiSTer on an arcade core running from RetroNAS and all is great... only an hour later MiSTer will no longer connect to RetroNAS when you sit down to play. Though running nearly flawlessly for over a year now:

The PROBLEM is that RetroNAS 'sees' the main 8TB external HDD but refuses to MOUNT it anymore. I refreshed myself on Linux commands like fstab, chmod and changing over to root do do admin but no online tutorials thus far have sorted it. I tested the external 8tb on another computer and it mounts fine and all games/files are present, etc.

I'm nearly ready to reinstall RetroNAS all over again in HOPES that my external HDD will be recognized again (as if I swapped out say a Rpi3 for a 4 or 5 as RetroRGB's tutorial suggested).

Can I avoid this with a simple fix to get RetroNAS and my main RetroNAS 8TB to re-handshake?

Hi, I'm one of the RetroNAS developers.

RetroNAS doesn't do anything special/different with hard disks than any other Linux distro would. And certainly reinstalling things is a bit of a sledge-hammer fix. The beauty of Linux is that, if you know how, it will give you very verbose output to find out what exactly is going wrong.

Maybe I can help you troubleshoot instead. What does the contents of your /etc/fstab file look like? And if you boot your RetroNAS device, log in on the command line via SSH, and run "sudo mount -av", what does the output of that say? (You can copy/paste text from an SSH terminal into a code block on these forums, rather than manually transcribing things or embedding image).

Is the disk maybe going into power save mode after a while?

Plug the HDD in to a Windows PC and run checkdisk on it to repair any faults that it may have. Could be that you did not unmount it properly or the computer did an incomplete write to it. Just because the files show up on it does not mean that everything is OK. I used to have this problem when running NTFS or exfat formatted disks under linux back in the day.

Thank you all for offering to help. I don't think the drive powers down because it has worked consistently for over a year now and likely would have done this prior. The drive shows up accessible on another linux machine, but on an old win7 machine, the drive is 'there' but not showing under 'My Computer' to where I can run chkdisk.

Plugging the drive back on the Retronas debian system, the drive doesn't show as "8TB" like it does on the other Linux machine, but instead as the more generic "Seagate Expansion SW" which is not my naming. Could this be part of the problem?

I tried some things requested here: [NOTE: The two "serial redacted" other drives below are unmounted, unplugged Plex media drives to ignore]

root@retronas:/home/pi# sudo mount -av
/ : ignored
/boot : already mounted
/boot/efi : already mounted
none : ignored
/storage : already mounted
mount.nfs: timeout set for Tue Jun 11 17:03:59 2024
mount.nfs: Failed to resolve server /dev/disk/by-id/usb-Seagate_Expansion_Desk[serial redacted]-0: Name or service not known
mount.nfs: timeout set for Tue Jun 11 17:03:59 2024
mount.nfs: Failed to resolve server /dev/disk/by-id/usb-Seagate_Expansion_Desk[serial redacted]-0: Name or service not known
root@retronas:/home/pi#

Ran Checkdisk on Retronas/ Debian with the 'Disks' program:

"Filesystem intact: Filesystem ext4 on Seagate Expansion SW is undamaged."

Funny too is that when I press the 'play' button to mount it in disks it says it is now mounted and I can hit the square 'stop' button to unmount. Yet, if I go to the drive listed under 'Computer' and double click it, it has doublespeak:
"Unable to mount location - Can't mount file."

fstab info:

root@retronas:/home/pi# cat /etc/fstab
/etc/fstab: static file system information.

Use 'blkid' to print the universally unique identifier for a
device; this may be used with UUID= as a more robust way to name devices
that works even if disks are added and removed. See fstab(5).

systemd generates mount units based on this file, see systemd.mount(5).
Please run 'systemctl daemon-reload' after making changes here.

<file system> <mount point> <type> <options> <dump> <pass>
/dev/mapper/retronas--vg-root / ext4 errors=remount-ro 0 1
/boot was on /dev/mmcblk2p2 during installation
UUID=dd63f556-d137-45b2-97cb-7c442258f310 /boot ext2 defaults 0 2
/boot/efi was on /dev/mmcblk2p1 during installation
UUID=15E7-618A /boot/efi vfat umask=0077 0 1
/dev/mapper/retronas--vg-swap_1 none swap sw 0 0
UUID=21b5068f-3eb6-4ec9-8cab-027b673aba58 /storage auto defaults 0 0
/dev/disk/by-id/usb-Seagate_Expansion_Desk[serial redacted]-0:0-part2 /media/pi/MOVIES auto nosuid,nodev,nofail,x-gvfs-show 0 0
/dev/disk/by-id/usb-Seagate_Expansion_Desk[serial redacted]-0:0-part2 /media/pi/TV auto nosuid,nodev,nofail,x-gvfs-show 0 0
root@retronas:/home/pi#

Ok, the weirdest thing just happened.

I've been doing file transfers on a local PC while waiting to see if any replies to my last post would turn up. Suddenly, my RetroNAS mapped drive in 'My Computer' noticeably turned from red to blue (implying I had access now?!?). I then typed \\retrosmb in the bar of 'My Computer' and suddenly I have access to my 8TB library again. I literally changed nothing to either cause the problem and nothing to fix it either.

The optimist in me says "Yay" and I should be happy it is working. The other school of thought is:

• What, how, and why the heck did this happen in the FIRST place and how did it now magically 'self-heal' many days later?!?
• How do I know this won't happen AGAIN at the most inconvenient time?
• Should I just hope the AVGN 'glitch gremlin' had his fun and will move on to wreak havoc elsewhere?

My mind never appreciates 'sometimes' problems I can't replicate, nor inexplicable solutions that I didn't earn, robbing me from a lesson to learn from.
Such frustrations are not directed at all towards the truly wonderful RetroNAS, nor elvis here. I truly appreciate the work put in and offering to help.
As said, it is likely Debian working in cahoots with Murphey's Law.

The only [tongue-in-cheek] critique of RetroNAS is that it is SOOO good and useful that all my consoles that depend on it are suddenly unusable without it.

seastalker wrote: ↑Wed Jun 12, 2024 11:52 am

Ok, the weirdest thing just happened.

I've been doing file transfers on a local PC while waiting to see if any replies to my last post would turn up. Suddenly, my RetroNAS mapped drive in 'My Computer' noticeably turned from red to blue (implying I had access now?!?). I then typed \\retrosmb in the bar of 'My Computer' and suddenly I have access to my 8TB library again. I literally changed nothing to either cause the problem and nothing to fix it either.

The optimist in me says "Yay" and I should be happy it is working. The other school of thought is:

• What, how, and why the heck did this happen in the FIRST place and how did it now magically 'self-heal' many days later?!?
• How do I know this won't happen AGAIN at the most inconvenient time?
• Should I just hope the AVGN 'glitch gremlin' had his fun and will move on to wreak havoc elsewhere?

My mind never appreciates 'sometimes' problems I can't replicate, nor inexplicable solutions that I didn't earn, robbing me from a lesson to learn from.
Such frustrations are not directed at all towards the truly wonderful RetroNAS, nor elvis here. I truly appreciate the work put in and offering to help.
As said, it is likely Debian working in cahoots with Murphey's Law.

The only [tongue-in-cheek] critique of RetroNAS is that it is SOOO good and useful that all my consoles that depend on it are suddenly unusable without it.

Can you report what your SMART monitor output is for the drive? Inconsistent functioning could be an indication that the drive is faulty.

I've had so many 8TB Seagate drives go bad that I stopped using them. I now opt for lightly-used (and still warrantied) data center drives I get from ebay. They're cheaper than new external Seagate / WD drives, I don't have to shuck them, and they should last longer.

I always format fresh drives because I personally don't like any factory software on them. Even if I wasn't like that, I think the storage drive one uses with RetroNAS HAS to be formatted entirely during setup anyway.

I did run checkdisk (from Debian Linux) on it and it displayed that there were no errors.

Though my PC now can access the drive and all files, I can't yet login to retronas from a browser using the IP Address:9090 method. I just tried my MiSTer and see it too is not connecting to CIFS again yet either.

Still some work to figure out but at least it's progress.

More problems were happening so the amount of time spent isn't worth it anymore. I'm reinstalling. I tried the latest Debian 12 and so far can't stand it's new desktop environment, and already hiccups arose BEFORE even getting to start any RetroNAS installation.

@elvis, the documentation I see (and remember now) says only Debian 11 is supported. To clarify, is that note outdated to where it will/should work with LATER versions (currently Debian 12)? If not, it looks like Debian's page links for 11 may only go to NET installers that don't play nice with flashing USB sticks. Even the links to the CD versions map to Net versions.

In revisiting this topic, I've discovered some things over the past month...

Though I'd personally LOVE to see updated documentation soon on the RetroNAS install instructions/wiki page re: compatibility with Pi5 as well as current Debian 12 (bookworm), I did find some hints of the latter's current status online in a few places that may be helpful to others:

Plans to extend compatibility to PiOS w/ Debian 12 (bookworm)?
https://www.reddit.com/r/retroNAS/comme ... ?rdt=40419

RPIOS - Debian version 12 (bookworm) support #366
https://github.com/retronas/retronas/issues/366

Debian 12 / Ansible 2.14 support #345
https://github.com/retronas/retronas/issues/345

**Also note that apparently newer debian distros for the Raspberry Pi do NOT create a default user of 'pi' with default password 'raspberry' anymore. Newcomers to RetroNAS may hit a snag now if following Bob's (of RetroRGB) very helpful installation video. [Things change- No fault of Bob's of course]
The fix for this is to create your bootable media with the official Raspberry Pi Imager software, AND WHEN IT PROMPTS YOU ASKING IF YOU'D LIKE "OS CUSTOMIZATION", be sure to click "edit settings" and tick the box for 'set user name and password' and enter what you wish here to create a user. For example, you can set "pi" as your username and "raspberry" as your password and Save. This now creates the original default 'pi' user/password and bakes it right into your installer OS.

I'm currently reinstalling on my pi3 using a LITE version of 11.10 (bullseye) to at least have as a backup RetroNAS. I may get more powerful hardware (and larger internal storage so I can also re-add Plex Media Server and not worry about metadata filling it).

Are there any advantages of using a pi5 (IF compatible) over a pi4 for the exclusive use case of retroNAS (...ok, well AND Plex serving)?

RetroNAS apparently barely needs 512MB tops- so I'd rather not OVERspend, but willing to invest more for the RAM and hardware that makes price/performance sense. I'm leaning towards a pi upgrade due to the simpler installer but would consider alternative hardware like a MiniPC, N100 family, etc.

Finally, about some of the problems I'd been having:
The old Asus X205T laptop from around 2014/2015 I was using is an odd duck... I found this reddit post: https://www.reddit.com/r/linux4noobs/co ... us_x205ta/
Ignoring the extra 'a' in the model number, [nearly the same], mine was having the same problems: I learned though it technically has a 64bit cpu, the uefi is stuck at 32bit. As soon as I wrote a 32bit USB OS, I can boot. 32bit may have issues with larger hard drives so not my best choice for RetroNAS.

UPDATES: Firstly, I was able to install RetroNAS on the latest Debian 12 (bookworm)

I want to share info with others in case they run into the same problems I had while installing the fantastic RetroNAS from the guides on the web:

1. Debian headless not working correctly directly after install - If you installed minimal you will need to install sudo with:
   apt-get install sudo

2. Cockpit won't allow signing in as Root (only as user) - Check for the existence of /etc/cockpit/disallowed-users
   You may follow all tutorial instructions perfectly and find that when signing into cockpit, you find it will only accept login via your user account but NOT as root. The workaround is to edit a file. In terminal, type:
   sudo nano /etc/cockpit/disallowed-users
   On a fresh install, this will likely be a short document. It basically lists 'root' as disabled. Add a # to cancel that to make it read
   #root
   Then hit CTRL+O to write the change, hit ENTER key to save the current file, then CTRL+X to exit the file.

3. This is a minor one but helpful: I saw the creator of RetroNAS's install video used SSH via a windows CMD prompt to login into headless Debian on the pi. This makes it much easier to just use copy/paste for each line of code to install RetroNAS from the instruction page... but what if Windows barks at you that 'ssh' is not recognized as an internal or external command: install/use the free program 'putty' on windows. It's windows native ssh agent

Happy RetroNAS-ing!!