Ben deBoer

Swapped my i5-10400 for an i5-11500 this morning on an ASUS Prime B560M-A AC running Unraid 7.3.2. Board posted fine and the boot menu came up, but it would load bzimage and bzroot and then just sit there. No kernel text, no network, nothing. I was on BIOS 2001 from 2023. Flashed 2803 with EZ Flash (it posts fine with the 11500 so you can do it with the new chip in) and it booted right up after that. There's a short pause after bzroot now but it gets through. B560 supports 11th gen out of the box so I didn't think the BIOS would matter, but apparently it does. If you're doing a 10th to 11th gen swap on one of these boards, update the BIOS first.

After updating to 7.3, I have the same issue as above the above poster. Using a SAS Xratex DAS with HGST drives. I don't know if I can be of any other help, let me know if there is something I can post.

I like the latest tag if you can do it. Would make it slightly easier instead of numbers

updated to that image. works now

there is an update for the manager and manager client from 1.8 to 1.9. I did the update, and it somehow changed my password so I couldn't access the manager again.

note to self, don't update from inside the container itself.

works great for me. Now I can administer all my proxmox instances without clustering them.

I keep on getting the following error in my log. Any idea about where I should start to resolve it? [richdocuments] Error: Failed to fetch the Collabora capabilities endpoint: Client error: `GET https://**nextcloud_address**/apps/richdocumentscode/proxy.php?req=/hosting/capabilities` resulted in a `404 Not Found` response: **nextcloud_address** is the address for my server I kind of figured it out. The problem is NextCloud office app. It is trying to connect to a CODE server, which is another app. I installed that one, and get different errors. Either way, I don't deal much with office files on my server, it is more for storing pictures, so I just disabled the Nextcloud office app.

I managed to fix it, the issue is with the new version of sabnzbd. Basically it has to do with the way it is identifying itself with SABnzbd. I just added a username and password for sabnzbd, and added that to all my configs and it works now. Thanks

Maybe I am doing something wrong. I have all my *arr stack on one docker network, however, when I go to link them together, I have to use the IP addresses of the docker network, which means that I need them to startup in a certain order. I set sonarr get the bit-torrent program, but as soon as I add binhex-sabnzbdvpn to the name to allow it to go the sab it gives me the error unable to connect. Test was aborted due to an error, HTTP failed forbidden. When I type in the docker IP address, everything works fine. anything I can try?

I am having the same issue as BigMal. did you ever get it resolved? I can access the app internally just fine, however, if I try to use my reverse proxy, it shows the login screen, but doesn't go beyond that, even with the right password Re-read the .env files from the GitHub. Add a new variable TRUSTED_PROXIES = ** ( not the IP of the proxy as I was doing )

Yes, I have confirmed that the web UI is basically freezing/locking up on me. Any other logs or things to list?

I was running a Pi-Hole docker container on this server, and the WebUI was hanging every 5 - 10 minutes, and that message was the only thing scrolling in the logs. I have since removed the Pi-Hole docker container, but I am still getting the messages but a lot less frequently. I haven't experienced loss of the WebUI recently, however, I can't say for sure that it doesn't happen. Whenever the WebUI used to hang, and I get back in, there was always a new string like that. If it is normal that it renames like that all the time, that is fine. I am just wondering if it is failing when it has increased networking traffic, which would be a big problem as I am looking to add Jellyfin to the server.

I recently upgraded to 6.11 from 6.8, and I have noticed that my ethernet has been cutting out sometimes. Has anyone else seen this? Nov 13 22:06:18 Tower kernel: eth0: renamed from vethe781b3d Nov 13 22:06:18 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth69db3b0: link becomes ready Nov 13 22:06:20 Tower avahi-daemon[23070]: Joining mDNS multicast group on interface veth69db3b0.IPv6 with address fe80::c00e:26ff:fe95:afb6. Nov 13 22:06:20 Tower avahi-daemon[23070]: New relevant interface veth69db3b0.IPv6 for mDNS. Nov 13 22:06:20 Tower avahi-daemon[23070]: Registering new address record for fe80::c00e:26ff:fe95:afb6 on veth69db3b0.*. Nov 13 22:06:25 Tower kernel: br-5180425399c9: port 2(veth69db3b0) entered disabled state Nov 13 22:06:25 Tower kernel: vethe781b3d: renamed from eth0 Nov 13 22:06:25 Tower avahi-daemon[23070]: Interface veth69db3b0.IPv6 no longer relevant for mDNS. Nov 13 22:06:25 Tower avahi-daemon[23070]: Leaving mDNS multicast group on interface veth69db3b0.IPv6 with address fe80::c00e:26ff:fe95:afb6. Nov 13 22:06:25 Tower kernel: br-5180425399c9: port 2(veth69db3b0) entered disabled state Nov 13 22:06:25 Tower kernel: device veth69db3b0 left promiscuous mode Nov 13 22:06:25 Tower kernel: br-5180425399c9: port 2(veth69db3b0) entered disabled state Nov 13 22:06:25 Tower avahi-daemon[23070]: Withdrawing address record for fe80::c00e:26ff:fe95:afb6 on veth69db3b0. Nov 13 22:06:26 Tower kernel: br-5180425399c9: port 2(veth05ce39d) entered blocking state Nov 13 22:06:26 Tower kernel: br-5180425399c9: port 2(veth05ce39d) entered disabled state Nov 13 22:06:26 Tower kernel: device veth05ce39d entered promiscuous mode Nov 13 22:06:26 Tower kernel: br-5180425399c9: port 2(veth05ce39d) entered blocking state Nov 13 22:06:26 Tower kernel: br-5180425399c9: port 2(veth05ce39d) entered forwarding state Nov 13 22:06:26 Tower kernel: eth0: renamed from veth686bcb1 Nov 13 22:06:26 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth05ce39d: link becomes ready Nov 13 22:06:28 Tower avahi-daemon[23070]: Joining mDNS multicast group on interface veth05ce39d.IPv6 with address fe80::208f:d4ff:fed1:8f54. Nov 13 22:06:28 Tower avahi-daemon[23070]: New relevant interface veth05ce39d.IPv6 for mDNS. Nov 13 22:06:28 Tower avahi-daemon[23070]: Registering new address record for fe80::208f:d4ff:fed1:8f54 on veth05ce39d.*. tower-diagnostics-20221114-2156.zip

Has anyone had an issue like this?