bptillman

Got this solved on my own. I noticed the attached warning in the top right of the screen, and when I looked in the content of the flash drive, there was a basic, trial, and plus key files. I assume all three were in there since I started with a trial, then moved to basic and eventually plus. Once I removed the trial and basic key files then I was able to replace the flash drive without issue. Hope this helps anyone else that might have run into this issue.

I purchased a new flash drive to replace the one in my system, and followed the steps outlined here but when I got to to the step on the Flash drive page to Replace the key, there is no Replace Key button present as you can see in the attached image? This is my first time to ever try and replace the flash drive so I am not sure why I am not given the option to replace it.

After the latest update to tt-rss was applied and the schema was migrated, I am now getting an error when loading my tt-rss instance. The first error seen was: E_URL_SCHEME_MISMATCH URL scheme reported by your browser (https) doesn't match server-configured SELF_URL_PATH (http), check X-Forwarded-Proto. Additional information: SELF_URL_PATH: http://tinyrss.mydomainhere.com CLIENT_LOCATION: https://tinyrss.mydomainhere.com/ For reference before this, I was able to go to https://tinyrss.mydomainhere.com to hit my ttrss instance behind a reverse proxy, so the error made sense to me since http was specified in my config.php. From seeing that error I changed the config.php from being http like this: putenv('TTRSS_SELF_URL_PATH=http://tinyrss.mydomainhere.com/'); to being https like this: putenv('TTRSS_SELF_URL_PATH=https://tinyrss.mydomainhere.com/'); After doing that and restarting the container, now when I visit https://tinyrss.mydomainhere.com , instead of the fatal error I am seeing: Startup failed Please fix errors indicated by the following messages: Please set SELF_URL_PATH to the correct value detected for your server: http://tinyrss.mydomainhere.com (you're using: https://tinyrss.mydomainhere.com) After that I also tried renaming the existing config.php and replacing all of the needed config values with docker environment variables that all start with TTRSS_ per the newest changes and am still seeing the "startup failed" message from directly above. So I'm not sure what other configuration issue it could be causing this.

Answered my own question. Looks like the config also changed variable names so if anyone else sees issues you've got to change your config.php like so: define("DB_TYPE=mysql") to putenv('TTRSS_DB_TYPE=mysql') I had to make this change to DB_TYPE, DB_HOST, DB_USER, DB_NAME, DB_PASS, DB_PORT, SELF_URL_PATH. Once I made the changes to all those it worked.

It looks like after the latest update to the tt-rss container it's looking for config values in environment variables instead of using what is in config.php. What does the migration path look like for someone with an existing instance to get this working?

Okay I'll see about finding a replacement breakout cable and test things again once I get it.

I re-ran SMART test on both disk1 and parity which showed success. But then I went and did a second SMART on disk1 and it for some reason spun down during the smart test, so I spun it back up and started the test again and it passed. I double checked the spin down delay in settings and its set to 4 hours currently and the disk1 is set to use default so I'm not sure why it spun down since the server had only been online for half an hour at that point. Attached are the latest diagnostics after all this. allthethings-diagnostics-20201127-1129.zip

So I added in a LSI SAS9211 controller card and plugged the two 14TB drives into it instead and ran parity sync and after almost an hour I started getting disk read errors. Nothing with millions of errors like the last time but still errors. I didn't see anything in the log about the sata link being dropped this time though. Attached are the diagnostic logs. allthethings-diagnostics-20201126-2314.zip

That's what I was starting to think.

I had been running Unraid 6.8.3 for a few months now without any issue in my HPE MicroServer Gen10 with 4 drives (5TB,4TB,2x2TB) and SSD cache, but recently bought two 14TB Western Digitals to replace all the existing drives. After pre-clearing each of the 14TB drives successfully in their external enclosures and then moving off everything I needed to a backup drive, I reset the config and installed the two 14TB drives and let it run the parity check. During the parity check I was alerted to errors and looked at the UI to see it showing millions (billions?) of reads/writes on the two drives in the array along with errors, and then the two drives showed up in the unassigned devices list instead of being in the array. Looking in the logs around the time this happened I see it has lines about hard resetting the sata link and the link being down (11/24/2020 22:08). This is actually the second time this has happened and after the first time I double checked all the connections in the drive cage and the connection to the motherboard on the breakout cable the server uses to ensure it was all connected but forgot to download the logs before shutting it down. I'm not sure what else to check or what could be going on. Is this a possible issue related to the Marvel 88SE9230 controller that this server uses? Attached are the diagnostics. allthethings-diagnostics-20201124-2244.zip