BentoFox

Necro~ Bummer that you never got a response. I have the same issue right after the initial setup where you create the admin account. No errors in MariaDB, it's as though it didn't even try to connect at all, despite the connection info being correct.

I totally get where you come from. Though it does seem to be completely down to that. The system's been stable since then. Also, mind I do not think it's 'enabling XMP' itself that fixes the issue, but rather that the RAM is more stable at its rated XMP speed than effectively underclocked on auto. In general I wouldn't recommend enabling XMP in a server environment - but if you had it on before and crash after disabling it ... consider enabling it 🦊

The parity check has run through completely now and it hasn't crashed since then (in safe-mode with XMP on). I now started all regular docker containers I run and it's been stable for half an hour at least. As previously it'd crash within minutes of booting even with no dockers running and the array has now been running for 2 days, I'd conclude that the issue was, indeed, that XMP was disabled as this is often recommended to do. More precisely I assume the issue is that the 'AUTO' settings which appear to reduce the RAM clock speed may have attempted to boost RAM timings, whereas XMP would use an actually working preset the RAM is rated for. So - if you recently disabled XMP and you now crash, try turning it on again if you ran stable with it before.

I've enabled XMP again and can now get into Safe Mode (maybe regular, too, I just haven't tried) and am running a parity check. Cya in 2 days 💀 If it makes it through that, I'll try booting into normal mode and leave the array online for a day (no docker / vm). If that works I'll give dockers a go. I'd be very happy if, albeit somewhat unintuitively and not recommended, enabling XMP would fix the crashes. bentobox-diagnostics-20240722-2340.zip

Things tried: - updated outdated plugins (unraid did an update recently) - skipped parity check (would crash in the middle anyway) to see if it's related to disk activity - started with dockers disabled - checked cables - fresh install of Unraid (v6.12.11) - ran memtest (success, 2 passes) - start in safe mode - pull diagnostics (safe mode) - run parity in safe mode, if it makes it through I'll wipe plugins and... - start in normal mode (and reinstall plugins one by one with a few hours inbetween) - pull diagnostics Sadly it crashes as soon as unraid boots, even in safe mode. Next up: - enable XMP again (it doesn't make sense to enable it, but it was enabled for months without issue...) - dreaded 1-by-1 rollback for which I need a stable system to make the changes

Hello folks, First off: it's a long post, bear with me - I appreciate it. 🧡 I'd like help on the best course of action to get to the root of crashes I've recently started having. Diagnostics attached to post #3 Unraid versions: v6.12.10 > v6.12.11 This is the mcelog event: mcelog: failed to prefill DIMM database from DMI data Kernel does not support page offline interface Hardware event. This is not a software error. MCE 0 CPU 3 BANK 0 TIME 1721651313 Mon Jul 22 14:28:33 2024 MCG status: MCi status: Uncorrected error Error enabled Processor context corrupt MCA: Internal parity error STATUS b200000000030005 MCGSTATUS 0 MCGCAP c0e APICID 6 SOCKETID 0 MICROCODE f4 CPUID Vendor Intel Family 6 Model 158 Step 12 Right now the system is doing a MemTest that seems successful so far (58%). My system ran stable for several months before this happened, however, I did some hardware changes and upgrades all at once (my mistake). 1. changed RTX2080 to RTX3070Ti (because it's thinner and doesn't block PCIe #2) 2. moved HBA (12G SAS3008) from PCIe #3 (x4) to PCIe #2 (x8) 3. disabled memory XMP (it was on the entire time. Never noticed) --- started at this midway point --- 4. changed 5G network card (1x #3) to 10G network card (PCIe #3) 5. changed 2x500GB SSDs (mirror) to 6x500GB SSDs (two-pair raidz1) Essentially I wanted 10G network and more (+faster) cache to keep up. The GPU change was required to physically free the PCI slot to allow adding the 10G card that requires PCIe x4; the 5G ran on 1x Things I noticed prior to the the issue (Pre Midway Point) In PhotoPrism I did a Library Sync/Import to get the pics. The system 'froze' during the process and I attempted `powerdown` via console. Upon executing the command the attached screen came alive but it couldn't shutdown, as it couldn't unmount the `/mnt/user` directory. I couldn't unmount it manually with online guides so after it seemed there was no file in transfer, I forced the shutdown. Upon restarting I let it run a parity check which it finished completely. (Post Midway Point) Added 4 SSDs and replaced NIC. in preparation to replace the cache drives, I ensured Docker+VMs aren't enabled; changed cache-using shares to 'move to array' and invoked the mover... However, this left me with 140GB of data on the cache drive anyway. Folders I set up to 'move to array' were partially still present on it. As nothing was running, I moved the files manually off cache to a subfolder on the NVMe (`mv cache\{,.[^.]}* hypercache\cachebak\`). Once it completed, I erased the cache drives, changed size 2 > 6, set it to `ZFS Encrypted` fs `raidz1 - 2 pairs` and moved the cache files back from cachebak. ----- Now, all in all that seems fine, despite the hiccup I had with the mover. But I've had plenty crashes since, within seconds after booting to unraid to a few minutes if I'm lucky. It doesn't matter if parity check is canceled or not. It also doesn't matter if Docker is running or not. For that reason I assume the GPU isn't an issue, as it's effectively not being used by anything at all. The HBA I just moved to another slot so that should also be fine. My hunch is that maybe something got corrupted, my system LIKES xmp and wants it turned back on, something's not right with the cache/mover

Be honest - has anyone actually gotten SMTP (google) to work with this container? I've configured the gitlab.rb file as per documentation (the password is an App password as Non-Secure app logins are being deprecated this september) gitlab_rails['smtp_enable'] = true gitlab_rails['smtp_address'] = "smtp.google.com" gitlab_rails['smtp_port'] = 587 gitlab_rails['smtp_user_name'] = "*******@gmail.com" gitlab_rails['smtp_password'] = "*************" gitlab_rails['smtp_domain'] = "smtp.google.com" gitlab_rails['smtp_authentication'] = "login" gitlab_rails['smtp_enable_starttls_auto'] = true gitlab_rails['smtp_openssl_verify_mode'] = 'peer' gitlab_rails['gitlab_email_enabled'] = true gitlab_rails['gitlab_email_from'] = ******************.org' gitlab_rails['gitlab_email_display_name'] = 'GitLab' ports 9080, 9443 and 22 are forwarded as per default docker template. I've later added 857, 443 and 80 as well just to be sure. Either way, the connection always fails with: irb(main):001:0> Notify.test_email('[email protected]', 'Message Subject', 'Message Body').deliver_now Delivered mail [email protected] (120122.7ms) /opt/gitlab/embedded/lib/ruby/3.1.0/socket.rb:1214:in `__connect_nonblock': Cannot assign requested address - connect(2) for [2a00:1450:4025:c03::1b]:587 (Errno::EADDRNOTAVAIL) from /opt/gitlab/embedded/lib/ruby/3.1.0/socket.rb:1214:in `connect_nonblock' from /opt/gitlab/embedded/lib/ruby/3.1.0/socket.rb:56:in `connect_internal' from /opt/gitlab/embedded/lib/ruby/3.1.0/socket.rb:137:in `connect' from /opt/gitlab/embedded/lib/ruby/3.1.0/socket.rb:642:in `block in tcp' from /opt/gitlab/embedded/lib/ruby/3.1.0/socket.rb:227:in `each' from /opt/gitlab/embedded/lib/ruby/3.1.0/socket.rb:227:in `foreach' from /opt/gitlab/embedded/lib/ruby/3.1.0/socket.rb:632:in `tcp' from /opt/gitlab/embedded/lib/ruby/gems/3.1.0/gems/net-smtp-0.3.3/lib/net/smtp.rb:643:in `tcp_socket' from /opt/gitlab/embedded/lib/ruby/gems/3.1.0/gems/net-smtp-0.3.3/lib/net/smtp.rb:656:in `do_start' from /opt/gitlab/embedded/lib/ruby/gems/3.1.0/gems/net-smtp-0.3.3/lib/net/smtp.rb:611:in `start' from /opt/gitlab/embedded/service/gitlab-rails/config/initializers/mail_starttls_patch.rb:53:in `start_smtp_session' from /opt/gitlab/embedded/lib/ruby/gems/3.1.0/gems/mail-2.8.1/lib/mail/network/delivery_methods/smtp.rb:100:in `deliver!' from /opt/gitlab/embedded/lib/ruby/gems/3.1.0/gems/mail-2.8.1/lib/mail/message.rb:2145:in `do_delivery' from /opt/gitlab/embedded/lib/ruby/gems/3.1.0/gems/mail-2.8.1/lib/mail/message.rb:253:in `block in deliver' from /opt/gitlab/embedded/lib/ruby/gems/3.1.0/gems/actionmailer-7.0.8.4/lib/action_mailer/base.rb:588:in `block in deliver_mail' from /opt/gitlab/embedded/lib/ruby/gems/3.1.0/gems/activesupport-7.0.8.4/lib/active_support/notifications.rb:206:in `block in instrument' ... 20 levels... I am able to receive SMTP emails using the same account from Authelia (without extra port forwardings). Both Authelia and GitLab are in the same docker network.

I don't have an answer for it but I'm also interested in the same thing. I'm aware the GitLab-Ce runner orchestrator creates orphan images for cache, unity version and base image. That's totally fine. However, there seems to be some extra space 'lost' somewhere and I'm afraid this will increase over time.

BIOS Update was enough. I have 62.7 / 64 GB available now which I consider perfectly normal and similar to my previous setup. :)

I will let you know tonight when parity rebuild is finished. Thanks already for the confirmation.

I know it's not my thread but I'll chime in anyway. At least you've got 16GB Of my 64GB of RAM I get a whopping... 1.8GB of usable RAM. From what I read in other topics, 'half the RAM' being available can be attributed to using DELL RAID cards (e.g. the H310 I use), which can be mitigated by blocking the SMBus pins. That's something I'll try once parity sync is through. However, I use 4 sticks á 16GB and I get 1/8th of a single stick available, so something very strange is going on. 4 Sticks being dead is very unlikely, but I'll test them also after parity. I've also added my diagnostics for good measure, where it mentions This. 41 --- WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 63456MB of RAM. bentobox-diagnostics-20230622-1239.zip Things I'll try but currently haven't: - update Asus Prime Z390-A BIOS (it's somewhat old) - block SMBus pins on IT'd H310 - check for bad slots / dimms

Nice, wasn't aware it was stored in a different base folder. The plugins and plugin errors were all stored elsewhere and I couldn't find it. Thanks a ton!

Heya! I'm having an issue with it where the app in Community APps is stuck on 'pending' (and has been for 2 weeks now, despite two restarts). I had issues with the original container (wouldn't update after upgrading Unraid OS) and deleted the original plugin. After uninstalling I wanted to install it on Community Apps again but it's stuck and I'm sadly lost at how I can resolve this.

Heya! I just discovered that tModLoader got deprecated with this recent update of it. Big pity. I literally waited two years for that update since it's the 1.4 compatible stable 🤣 fml I've found some guides on how to set up the Steam tModLoader in a linux environment, but I'm not a pro when it comes to dockers themselves. Would the master branch of the regular Terraria docker be a good enough starting point for me to attempt building a custom docker from with tMod added or is another branch more suitable for that endeavour?

It's running on a Xeon E5-1620 from what feels like 200 years ago But indeed, after retrying with that x86 forced param it does seem to run stable now, though I'm positive I tried that before (hence why the parameter already existed buy I had changed it to false after it didn't help). Perhaps it was a combination of things, such as re-verifying files. Either way, I just wanted to report back to mention that it does, indeed, run stable.