Squid

Is the problem because U2_1 and U2_2 get disabled if you use M2_2 and M2_3?

With the change you made in the BIOS, post a new set of diagnostics

Standard mounting size for the log is 128M, so your log is currently using 3% of that. Everything else (flash, RAM, docker) should be self explanatory - the size taken up vs the size installed

The mce happened during processor initialization (happens on certain hardware combinations, probably related to firmware update) and can be safely ignored if there are no other issues with your system

Is this with an iGPU or an addon card? If only to rule it out, can you run a MemTest from the boot menu. It appears that you're booting via UEFI mode. To run MemTest you'll have to temporarily switch to Legacy boot (or create a new stick via https://www.memtest86.com/)

@bonienl

I believe it's because of some necessary updates it had to do, but you would have to ask @dlandon in the UD thread.

Seconds. And this is primarily a legacy setting since 6.9+ also include this setting for Docker (defaults to 10 seconds) If the container doesn't stop gracefully when being asked to within 10 seconds, then docker itself kills the processes off.

Like I said, deleting the txz's is the test for why your snmpwalk command fails for those users with the issues. Hard for me to try and replicate since my network is up and running at plugin install. Maybe 127.0.0.1 since it doesn't require /etc/hosts to be populated yet (if that is what the issue actually is)

Post your diagnostics. Unlikely that your chain of events caused data loss

The only place it's going to fail to install would be in this section: echo "" echo "+==============================================================================" echo "| Testing SNMP by listing mounts, /boot should be present" echo "+==============================================================================" echo "" printf "snmpwalk -v 2c localhost -c public hrFSMountPoint\n" results=$(snmpwalk -v 2c localhost -c public hrFSMountPoint 2>&1) || printf "snmpwalk failure" if [[ "$results" =~ "/boot" ]] then echo "SNMP appears to be working. Output:" echo "$results" else echo "Couldn't find /boot mount point. SNMP output:" echo "$results" exit 1 fi and that is because of the exit 1 My surmise is that for those users where it fails is because the network is not up and initialized yet, so localhost doesn't actually exist. A plugin cannot make the assumption that the network actually exists or is initialized at plugin installation time, because it really depends upon the hardware, networking gear etc. For those users who have problems with this a reinstall, the simple way to determine if it's because of networking being down is to simply delete all the .txz's from /boot/config/plugins/snmp but ensure the folder and the .plg still exists in /config/plugins. On a reboot if I'm right it'll fail to download the .txz's

You should post the diagnostics Actual drive failures are exceedingly rare. Usually its because of loose sata cabling

You're being spammed by ACPI errors. I would start by looking at updating the BIOS (you're 2 revs behind)

It is telling you exactly the problem folder You have a folder named "appdata" within /mnt You're referencing that within a docker container as /mnt/appdata instead of /mnt/user/appdata

I didn't notice all that. You'll need to fix the underlying cache drive issues first

You got that backwards. The "2" is the newer version and supports 6G whereas the original only supports 3G

Those VMs are referencing /mnt/disks/WDC_WDS... but UD is now mounting that drive at /mnt/disks/21146.... Hence the error (which is 100% correct) Easiest to probably change the mount point being used by UD for that drive to match

Just redo the docker image https://forums.unraid.net/topic/57181-docker-faq/?do=findComment&comment=564309

Interesting. The SAS2LP is recommended to NOT use, but the SASLP is listed as being OK. Maybe at the time of the update the original version was OK.

Does setting the drives to never spin down change the frequency of stuttering? Many (most?) controllers wind up pausing all I/O streams if a drive winds up having to spin up for another reason.

Then let me re-word that. Replace the GF

Your flash drive is either defective and needs to be transferred or has dropped offline -> try a different port A reboot is necessary to fix these errors The drive is fine IMO. Just watch the reallocated sectors. If they keep increasing, then replace the drive

It's a one-time update to how images are handled introduced 6.9.x. Once the image is downloaded it never re-downloads it again unless you change the URL

The only difference between the version from Muwahhidun and how @ich777 originally published OpenVPN was the environment variables. Everything else was identical. Shouldn't be any issue to move over to the actually maintained version from Ich777 But now that I see that the container from dperson looks to be abandoned, I'm going to deprecate it.

Delete /config/ssh and /config/ssl on the flash drive and reboot