bptillman

Members
  • Posts

    8
  • Joined

  • Last visited

bptillman's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. 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.
  2. 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.
  3. 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?
  4. Okay I'll see about finding a replacement breakout cable and test things again once I get it.
  5. 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
  6. 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
  7. 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