kaiguy

Hmm... this is a little odd. So I ended up successfully able to run the command locally on my unraid server (without specifying an IP address). I no longer see bond0 at all, but I also still don't have the bond configuration option. It's almost like the command just killed the bond without exposing that option. If I force refresh the network settings screen, it does end up showing the bond conf option before logging me out. When I log back in its not visible. What I do have is now the ability to choose enabling the LAN on eth0 or eth1 under Network IP settings, and also the ability to register eth0 and/or eth1 to the BMC. Maybe I'm just misunderstanding that I thought I would see 3 eth options (the 2 LAN and 1 IPMI LAN). Edit: Ok, I got the bonding configuration to show up. Required me to do a BMC cold reset in the settings. Ultimately, though, something is just not working for me. No matter what, I can't seem to get the board to utilize the IPMI port. Even with bonding disabled it's always attaching the IPMI mac address to either eth0 or eth1. I wonder if its related to this bug, but I'm not feeling confident or motivated enough to do anything about it. Oh well.

Thank you both, @Hoopster and @JimmyGerms. I tried the command locally on my server but as Hoopster experienced it didn't work for me. I don't have a secondary unraid server, so I am going to spin up a VM on a different machine, install ipmitool, and give it shot. I'll edit this post with my results.

Thanks, @JimmyGerms. I am on the same as well. I wonder if I need to plug a cable into LAN2 for the option to show up? Next step will probably be pulling power from the server to soft-reset the BMC. Weird.

Rehashing the IPMI bonding question earlier on this page... Although I have a network cable plugged into both the IPMI LAN and LAN1 (LAN2 is unused), I notice that my new Unifi switch is associating both MAC addresses with a single port. So I figured I'd just go and break the bonding, but I don't seem to have the "Network Bond Configuration" option in the GUI. I also didn't see anything in the BIOS. Any thoughts?

Been running the last few rc's without issue, and updated to stable tonight just fine. Thanks for all of the work that went into this huge release!

Working great so far. Thanks @Taddeusz! Supper happy I can now use ed25519 keys.

Thanks for the heads up, @Hoopster. I've never ran into that before, but I have had an intermittent issue where trying to login to the HTML5 IPMI gui would just keep going back to the login screen. The only way to correct it was to shut down and pull the power from the server, but I might try reflashing the BMC next time I encounter it.

Closing the loop. Since disabling turbo boost (once again), I have not encountered another CPU_CATERR crash, even with some pretty intensive CPU workloads.

Thanks for sharing this. Using your script (with the minor edit that @ICDeadPpl highlighted--it was erroring out for me as well without adding the backslash). What is your recommendation, @mgutt, for identifying what is making /var/docker/overlay2 writes? I'm getting pretty consistent writes still even after incorporating the script.

For whatever reason, the QR code doesn't seem to work with my Bitwarden app. Never ran into that problem before (it just won't scan). I just tried setting up TOTP on another site and it worked just fine. Odd.

1.5.0 has dropped.

I use Adguard Home, but my unraid server specifically bypasses Adguard for DNS. My firewall does utilize blocklists, but only for ingress. So short answer is, no.

Might be too early to fully confirm, but disabling Turbo Boost has helped my server survive a few more nights without a CPU_CATERR. I'll stick with you, @Hoopster, and keep Turbo Boost disabled from now on. Thanks for your input.

Welp, started getting unraid lockups due to CPU_CATRR again after over a year of stability. No changes to my unraid or server config aside from swapping in some larger disks over the past couple of weeks. It's now happened twice in the last 4 days, the most recent one during a data rebuild. The day before the first recent CPU_CATRR I enabled Plex's new credit detection, which I believe is fairly CPU intensive. Considering the hangs have occured during the time where Plex is doing its maintenance tasks (between midnight and 4am), I'm fairly certain this is the catalyst, and makes me worry my CPU cooling is just insufficient for max load. I'm going to keep the Plex container shut down until my rebuild is complete, then I might try disabling Turbo Boost (as I seem to recall that helped back in late 2021 when I was getting it fairly frequently, but it's been enabled for quite some time now). Bummer.

Thanks, @ljm42. As I mentioned before, the unraid-api restart does show as connected for a bit, but the API_KEY under unraid-api status continues to show as invalid (after 5 seconds, 30 seconds, 10 minutes, always). Is that expected behavior? Logging out and back in does not correct the API_KEY: invalid issue.

I don’t think that’s the problem on my end, as I don’t even want to utilize unraid’s remote access. I think it’s related to the API key as showing invalid.

I recently switched firewalls from pfsense to OPNsense, so I absolutely understand that I may have mucked up some configuration. But I can't seem to track this down so I figured I might as well try to eliminate unraid/My Servers as the culprit. I setup my firewall rules pretty much exactly as before, and my topology hasn't changed. Any thoughts? When I access https://forums.unraid.net/my-servers/ , my server shows as offline. I can log out and log back in on the plugin, and it will show as online for a period of time. Not doing it this time though to show the following... This is what the My Servers section of Management Access page looks like on my server: And the API report: <-----UNRAID-API-REPORT-----> SERVER_NAME: titan ENVIRONMENT: production UNRAID_VERSION: 6.11.5 UNRAID_API_VERSION: 2.55.1 UNRAID_API_STATUS: running API_KEY: invalid MY_SERVERS: authenticated MY_SERVERS_USERNAME: kaiguy CLOUD: STATUS: [error] MINI-GRAPH: STATUS: [DISCONNECTED] ERROR: [API Disconnected] SERVERS: ONLINE: OFFLINE: ALLOWED_ORIGINS: </----UNRAID-API-REPORT-----> And output of update DNS: root@titan:~# php /usr/local/emhttp/plugins/dynamix/include/UpdateDNS.php -v (Output is anonymized, use '-vv' to see full details) Unraid OS 6.11.5 with My Servers plugin version 2023.01.23.1223 ✅ Signed in to Unraid.net as kaiguy Use SSL is auto ✅ Rebind protection is disabled for myunraid.net Local Access url: https://192-168-0-10.hash.myunraid.net:8443 ✅ 192-168-0-10.hash.myunraid.net resolves to 192.168.0.10 Request: { "keyfile": "[redacted]", "plgversion": "2023.01.23.1223", "internalhostname": "*.hash.myunraid.net", "internalport": "8443", "internalprotocol": "https", "remoteaccess": "no", "servercomment": "unRAID 6 Server", "servername": "titan", "internalip": "192.168.0.10", "unraidreport": "{\"os\":{\"serverName\":\"titan\",\"version\":\"6.11.5\"},\"api\":{\"version\":\"2.55.1\",\"status\":\"running\",\"environment\":\"production\",\"nodeVersion\":\"v18.5.0\"},\"apiKey\":\"invalid\",\"myServers\":{\"status\":\"authenticated\",\"myServersUsername\":\"kaiguy\"},\"minigraph\":{\"status\":\"DISCONNECTED\",\"error\":\"API Disconnected\"},\"cloud\":{\"status\":\"error\"},\"flashbackup\":{\"activated\":\"yes\",\"error\":\"no\"}}" } Response (HTTP 200): [] success Attaching diagnostics. Would appreciate any feedback. Thanks! Edit: When I run unraid-api restart, the My Servers page will show as online again but the api report will still display the API_KEY as invalid. titan-diagnostics-20230209-1036.zip

For the first time the other day I noticed that Community Applications has the ability to mass update plugins/containers directly from the Apps tab. Cool new(?) feature! I'm not sure if this is expected behavior, but when I went ahead and kicked off the update from within the Apps tab, all updated non-running containers with auto-start disabled ended up being started after the update. This is not the same behavior if I would have updated from the Docker tab (non-running containers would remain non-running). Just wanted to report this observation should the desire be for the behavior to be aligned.

Appreciate sharing this fix. I was getting this with one container, then a few days later another, and finally I had 5 containers with this issue. I was pulling my hair out thinking I had some issue with my DNS blocklists.

Hi! For unrelated reasons, I decided I need to downgrade back to 6.10.3 after briefly trying out 6.11.0. The change to 6.11.0 incorporated the SSD trim plugin into the OS, so the plugin was autoremoved. After the downgrade, I attempted to reinstall the plugin (which appeared to install successfully), but there is no plugin displayed nor any setting for TRIM that can be found. I seem to recall years ago before the trim plugin, that I could setup a cron job to manually apply the trim command. Is this my best avenue for the time being? I have a few SSD cache pools, so I am unsure if this is a safe alternative. Any suggestions? Edit: Looks like I'm getting an error on the plugin install. plugin: installing: https://raw.githubusercontent.com/bergware/dynamix/master/unRAIDv6/dynamix.ssd.trim.plg plugin: downloading https://raw.githubusercontent.com/bergware/dynamix/master/unRAIDv6/dynamix.ssd.trim.plg plugin: downloading: https://raw.githubusercontent.com/bergware/dynamix/master/unRAIDv6/dynamix.ssd.trim.plg ... done plugin: downloading: https://raw.githubusercontent.com/bergware/dynamix/master/archive/dynamix.ssd.trim.txz ... failed (Generic error) plugin: https://raw.githubusercontent.com/bergware/dynamix/master/archive/dynamix.ssd.trim.txz download failure (Generic error) Updating Support Links Finished Installing. If the DONE button did not appear, then you will need to click the red X in the top right corner

Had to rollback to 6.10.3 due to the EDID block 0 issue spamming my syslog, and like another user I see that I cannot get the SSD trim plugin to reinstall (it said it installed via CA, but it does not display under plugins and there is nothing visible under settings). Any thoughts? Posting in this thread since it appears to be a byproduct of the downgrade from 6.11.0. Thanks!

Updated without issue. All seems to be working well, though I am seeing something I've never observed before. About every 20 seconds, one of my CPU cores (core 6 per the dashboard) maxes out for a bit. I was monitoring htop, sorting by CPU activity, but I can't seem to find a correlation. Anyone have a suggestion for how I can try to find out what is causing this intermittent core activity?

Your suspicion was absolutely correct. Reloading nginx properly showed a renewed cert. Thanks so much! Do you think this is something I should file a bug report for? Or could this have been an isolated incident? In any case, if I run into this again in the future, I'll know exactly what to do. Appreciate your help!

Hi there. Running 6.10.3. Searched for this error but I didn't seem to find anything in the forums. Today Firefox gave me a warning when accessing the unraid GUI that the ssl cert was invalid. I took a look and it expired 3 days ago. The Management Access settings also shows that the cert is expired, and the buttons for renew and delete are greyed out. This appears to be the relevant log items: Aug 12 08:09:38 titan nginx: 2022/08/12 08:09:38 [error] 12133#12133: OCSP response not successful (6: unauthorized) while requesting certificate status, responder: r3.o.lencr.org, peer: 184.28.78.21:80, certificate: "/boot/config/ssl/certs/certificate_bundle.pem" Aug 12 10:53:03 titan nginx: 2022/08/12 10:53:03 [error] 12133#12133: OCSP response not successful (6: unauthorized) while requesting certificate status, responder: r3.o.lencr.org, peer: 184.28.78.21:80, certificate: "/boot/config/ssl/certs/certificate_bundle.pem" Any suggestions for how to address?