JDK

Yeah all this was part of the troubleshooting phase. Voltage is hard to say whether i ever got that right or not because there are no specific parameters to hit. The point really was that none of this should be necessary just like it isn't with Intel, or many other linux distros running on AMD. I get there is nuance, edge cases, etc. and a smarter more motivated nerd than myself might have gotten to the bottom of things, but i couldnt justify the additional time that was needed for my specific AMD platform.

So whats the deal with AMD support for unraid? Back in 2021 i decided that my older Xeon setup sourced from ebay was no longer up to snuff. it was very reliable, but it was starting to show its age and a real power hog. I treated myself to a brand new AMD system built around the 24T 5900X which would give me modern hardware for the services i want to run reliably and perform well, as well have room to space for my hobby homelab. Everything went smooth and it was great. In March/April of 2025 i started seeing random crashes and reboots on a regular basis. it started slow like maybe once a week with complete reboots i would log in and see that its doing unexpected parity check. then in the following days i noticed services would be unavailable and i wouldnt be able to terminal in because the server is frozen. the logs never showed anything of value (i'd tail syslog to cache drive so it wouldnt be lost on reboot). 2-3wks went by where the server was down more than up, mostly because i have a demanding full time job and this shit is supposed to be a hobby for me, not a second job... I started reading how so many people had issues with AMD, but then also so many had no problems, including myself for the last several years. So I memtested ram for days, eventually replaced ram, motherboards, flash drives, hard drives (lol, i know, desperate), everything...except the CPU. i wasnt prepared to spend money to just replace for the same 4yr old CPU especially if there was any truth to an AMD curse. I did test the CPU (and the original build components) on a windows install and no problems whatsoever. but, nothing helped my unraid install. i was about to take the whole clusterfuck out back behind the barn when as if by magic things started staying up. one hour became a day became a week and before you knew it i was months removed from the nightmare. Then this past Thursday i notice ads while browsing and wouldnt you know it the server is down. instant flashbacks, but okay, this isnt server grade hardware so isolated problems every few months are acceptable i guess. Except it immediately showed those same symptoms from before. it would stay up for 10-15mins before crashing or randomly rebooting. sometimes getting stuck during the linux boot process. By Saturday morning i still couldnt resolve it and fed up i decided to pay my way out of the headache and just bought intel parts. by noon on Saturday i had it up and running on the intel parts as if nothing had ever happened. i realize the irony that this was the same experience i had when migrating from Xeon to the AMD system so i guess time will tell, but i have not seen anywhere near the amount of problems reported for people running unraid on intel systems. so whats going on, am i just unlucky and jaded or is there some unspoken truth to unraid not playing as well with AMD as Intel? love to hear some thoughts here. The AMD system i am currently writing this post from, but with a windows install. if all goes well here for the next few days i will simply sell these parts with a disclaimer in order to try recoup some of the migration cost.

I wasn't able to come back to this right away... I deleted /boot/config/rsyslog.cfg and rebooted, but issue still shows on fix common problems. /boot/config/rsyslog.cfg was recreated but is now a blank file vs having the obvious settings before. what is responsible for writing the content of /etc/rsyslog.conf because i would guess that is the problem.

thanks will try that and report back. im 88% through preclearing a new disk.

i have done that, and possibly every other combination possible on the form. result is the same. it looks like the config i posted above is some sort of a default template...is there some area where this might be configured?

it is, yes. i just connected via ssh to pull a tail on that log. root@SERVER:~# tail -f /boot/logs/syslog.log Apr 9 08:13:06 SERVER root: Fix Common Problems: Warning: unraid.patch.plg Not Compatible with Unraid version 7.1.0-beta.1 Apr 9 08:13:08 SERVER sshd-session[141710]: Connection from 192.168.0.100 port 50543 on 192.168.0.5 port 22 rdomain "" Apr 9 08:13:08 SERVER sshd-session[141710]: Postponed keyboard-interactive for root from 192.168.0.100 port 50543 ssh2 [preauth] Apr 9 08:13:12 SERVER sshd-session[141710]: Postponed keyboard-interactive/pam for root from 192.168.0.100 port 50543 ssh2 [preauth] Apr 9 08:13:12 SERVER sshd-session[141710]: Accepted keyboard-interactive/pam for root from 192.168.0.100 port 50543 ssh2 Apr 9 08:13:12 SERVER sshd-session[141710]: pam_unix(sshd:session): session opened for user root(uid=0) by (uid=0) Apr 9 08:13:12 SERVER sshd-session[141710]: User child is on pid 142329 Apr 9 08:13:12 SERVER sshd-session[142329]: Starting session: shell on pts/1 for root from 192.168.0.100 port 50543 id 0 Apr 9 08:13:12 SERVER root: Fix Common Problems: Warning: Syslog mirrored to flash Apr 9 08:13:12 SERVER emhttpd: read SMART /dev/sdi

Now that i have my server running stable again, i am coming back to this and cannot figure this out. i have syslog server completely disabled at this point, but still fix common problems reports that syslog is being mirrored to flash. here's what rsyslog.conf looks like after i save the above config. # /etc/rsyslog.conf Configuration file for rsyslog. # # For more information see # /usr/doc/rsyslog-@VERSION@/html/rsyslog_conf.html $template flash, "/boot/logs/syslog.log" ################# #### MODULES #### ################# $ModLoad imuxsock # provides support for local system logging $ModLoad imklog # provides kernel logging support (previously done by rklogd) # limetech - we don't need no stinkin' MARKS #$ModLoad immark # provides --MARK-- message capability # ######### Receiving Messages from Remote Hosts ########## # TCP Syslog Server: # provides TCP syslog reception and GSS-API (if compiled to support it) #$ModLoad imtcp # load module #$InputTCPServerRun 514 # start up TCP listener at port 514 # UDP Syslog Server: # limetech - let's enable this #$ModLoad imudp # provides UDP syslog reception $UDPServerAddress 127.0.0.1 # localhost only $UDPServerRun 514 # start a UDP syslog server at standard port 514 ########################### #### GLOBAL DIRECTIVES #### ########################### # # Use traditional timestamp format. # To enable high precision timestamps, comment out the following line. # $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat # # Use traditional Slackware console log level # $klogConsoleLogLevel 3 # # Set the default permissions for all log files. # $FileOwner root $FileGroup root $FileCreateMode 0640 $DirCreateMode 0755 $Umask 0022 # # Include all config files in /etc/rsyslog.d/ $RuleSet local $RuleSet RSYSLOG_DefaultRuleset $RuleSet RSYSLOG_DefaultRuleset $RuleSet RSYSLOG_DefaultRuleset $RuleSet RSYSLOG_DefaultRuleset $RuleSet RSYSLOG_DefaultRuleset $RuleSet RSYSLOG_DefaultRuleset $RuleSet RSYSLOG_DefaultRuleset $RuleSet RSYSLOG_DefaultRuleset # limetech - ok # $IncludeConfig /etc/rsyslog.d/*.conf ############### #### RULES #### ############### # limetech - everything goes to syslog. $RuleSet RSYSLOG_DefaultRuleset *.debug -/var/log/syslog # Uncomment this to see kernel messages on the console. #kern.* /dev/console # Log anything 'info' or higher, but lower than 'warn'. # Exclude authpriv, cron, mail, and news. These are logged elsewhere. #*.info;*.!warn;\ # authpriv.none;cron.none;mail.none;news.none -/var/log/messages # Log anything 'warn' or higher. # Exclude authpriv, cron, mail, and news. These are logged elsewhere. #*.warn;\ # authpriv.none;cron.none;mail.none;news.none -/var/log/syslog # Debugging information is logged here. #*.=debug -/var/log/debug # Private authentication message logging: #authpriv.* -/var/log/secure # Cron related logs: #cron.* -/var/log/cron # Mail related logs: #mail.* -/var/log/maillog # Emergency level messages go to all users: *.emerg :omusrmsg:* # This log is for news and uucp errors: #uucp,news.crit -/var/log/spooler # Uncomment these if you'd like INN to keep logs on everything. # You won't need this if you don't run INN (the InterNetNews daemon). #news.=crit -/var/log/news/news.crit #news.=err -/var/log/news/news.err #news.notice -/var/log/news/news.notice # ########## Remote Logging (we use TCP for reliable delivery) ########## # An on-disk queue is created for this action. If the remote host is # down, messages are spooled to disk and sent when it is up again. #$WorkDirectory /rsyslog/spool # where to place spool files #$ActionQueueFileName uniqName # unique name prefix for spool files #$ActionQueueMaxDiskSpace 1g # 1gb space limit (use as much as possible) #$ActionQueueSaveOnShutdown on # save messages to disk on shutdown #$ActionQueueType LinkedList # run asynchronously #$ActionResumeRetryCount -1 # infinite retries if host is down # remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional #*.* @localhost:514 $DefaultRuleset local $DefaultRuleset RSYSLOG_DefaultRuleset $DefaultRuleset RSYSLOG_DefaultRuleset $DefaultRuleset RSYSLOG_DefaultRuleset $DefaultRuleset RSYSLOG_DefaultRuleset $DefaultRuleset RSYSLOG_DefaultRuleset $DefaultRuleset RSYSLOG_DefaultRuleset $DefaultRuleset RSYSLOG_DefaultRuleset $DefaultRuleset RSYSLOG_DefaultRuleset $DefaultRuleset RSYSLOG_DefaultRuleset *.* ?flash

thanks i feel like i resolved my issue now by adding a voltage offset. i had c-states disabled from the very beginning.

did you end up resolving your issue and if so did it involve any voltage adjustments? i have the same CPU suffering random crashes (confirmed is due to CPU).

back in business, baby! thanks you guys are great. disk mounts and im able to browse content. server-diagnostics-20250403-1828.zip

Thank you. Here's the output from that. the result states "File system corruption detected." with the button reading "Fix" now. i want to click it but going to make sure i ask so i dont lose anything. diagnostics below. Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ALERT: The filesystem has valuable metadata changes in a log which is being ignored because the -n option was used. Expect spurious inconsistencies which may be resolved by first mounting the filesystem to replay the log. - scan filesystem freespace and inode maps... sb_fdblocks 251623534, counted 239557133 - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 Bad mtime nsec 2111207260 on inode 128, would reset to zero - agno = 1 - agno = 2 - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 Bad mtime nsec 2111207260 on inode 128, would reset to zero - agno = 2 - agno = 3 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. server-diagnostics-20250403-1817.zip

been struggling the last few days troubleshooting random crashes. with all the power cycles and troubleshooting i guess at some point i started the array without disk4 in it. so the next time i included it in the array and started it would try to rebuild the disk, but before that could happen the server would crash. i eventually moved the disks and flash over to other set of hardware and was able to complete the rebuild there, but now showing the disk as Unmountable: wrong or no file system. if i do format this disk will it rebuild from parity still after, or is the data on it lost now?

i settled on this running as user script on array startup. definitely getting better logs this way so went ahead and upgraded back to 7.0.1 and now just to wait and see. #!/bin/bash FILENAME="/mnt/user/syslog/syslog-$(date +%s)_tail.log" tail -f -n +1 /var/log/syslog > $FILENAME i went back to these settings on syslog server until i can figure out the crashing which is a primary concern for me.

yeah it exists and is writeable. i would have expected syslog to have a ton more information... while no idea why, syslog server is probably just messed up on my side for some reason. in the meantime i resorted to a more brutish tactic of just copying the syslog every few minutes via user scripts. a constant tail would probably be better so i will mess with that a bit still. FILENAME="/mnt/user/syslog/syslog-$(date +%s).log" cp /var/log/syslog $FILENAME server died again sine my previous post. i cannot tell what time, because even the mirror to flash didnt provide anything different form the sparse log i had in the share i set up. with that, im probably going to upgrade back to 7.0.1 if it happens again as it would be evidence that its not the version causing issues. i did run a full pass of memtest, but that came back clean.

it doesn't behave differently. here are the changes (set IP and also enabled mirror to flash) i made and checked immediately after save. root@SERVER:~# rsyslogd -N1 rsyslogd: version 8.2102.0, config validation run (level 1), master config /etc/rsyslog.conf rsyslogd: Could not find template 1 'remote' - action disabled [v8.2102.0 try https://www.rsyslog.com/e/3003 ] rsyslogd: error during parsing file /etc/rsyslog.conf, on or before line 132: errors occured in file '/etc/rsyslog.conf' around line 132 [v8.2102.0 try https://www.rsyslog.com/e/2207 ] i have to go and add the template for remote manually and restart the process. once i have this in place, it does log to the share, but seemingly nowhere near all the events that get mirrored to flash. so i will leave flash mirroring on for now so i have a chance to catch the issue when the server crashes again. PS. this is clearly not an issue in 7.0.1; i rolled back to 7.0.0 and still have the same experience. server crash issue also not resolved by rollback as i had another crash this morning.