Rysz

The base distribution and its packages are updated as part of the regular Unraid OS updating process, nothing the user needs to take extra care of there.

What Python are you using and from where did you install it?
The NerdTools/NerdPack packages are broken on 7.0, so I'd recommend using instead:
 

This is a common firmware-related problem with the APC BX series and `apcupsd` (Unraid's UPS Settings).
 
The only solution at the moment is to use the NUT plugin with the `preview (latest build)` backend configured...
... and these additional settings added to the end (on line 9 or later) of `UPS.CONF` using the GUI configuration editor:
pollonly lbrb_log_delay_sec = 3 lbrb_log_delay_without_calibrating The backend itself can be changed inside `NUT Settings` and requires a plugin reinstallation or system reboot after the change.
 
See for more information:
https://sourceforge.net/p/apcupsd/mailman/message/58740970/
https://github.com/networkupstools/nut/issues/2347
 

Thanks a lot, I proposed the change upstream.

You can just put the USB into a new system, Unraid doesn't care about the hardware (except for HDDs).

My bad, I just saw your version - the array is optional starting from Unraid 7.0 beta2: https://unraid.net/blog/unraid-7-beta-2
 
 

This is merely a diagnostic message from the "Live Memory Tester" plugin that checks for a running process of itself before installing.
It doesn't mean anything is wrong and it shouldn't appear in the system logs, merely on the boot screen (as that's extremely verbose by default).
 

Hello!
 
The way I understood your question, ideally you would rebuild one of the 4TB disks onto the new 20TB disk:
https://docs.unraid.net/legacy/FAQ/replacing-a-data-drive/
 
Then you'd shrink the array either doing a new configuration (rebuilding parity) or the more complicated shrink array procedure (preserving parity):
https://docs.unraid.net/legacy/FAQ/shrink-array/ (shrinking the array meaning removing the obsolete 4TB drive)
 
But honestly I'd keep the obsolete 4TB drive in the array and replace it with a larger drive down the road, as that doesn't expose you to the vulnerability of having to rebuild your parity (during which your other drives would not be protected) or having to follow the complicated shrink array procedure. For me personally the little amount of energy saved would not be worth that risk or effort, I'd just keep that disk spun down and replace it with a larger disk in the future. 🙂 
 

Not all UPS support this and it also depends on the implementation in the UPS driver itself.
If it does not work for you with the in-built "UPS Settings" (apcupsd), you can also try with the NUT plugin.

There's some seemingly memory related kernel errors in the logfiles.
Please run a memory test using either "Live Memory Tester" or memtest86 and report back.
 

You lost everything on that disk, a reformat is never part of a recovery (there's like 50 warnings about this).
By reformatting you updated the parity in a way that says disk 5 is supposed to be empty, not being able to rebuild.

I'd seriously advise against this as it closes one very unlikely problem to just open up another much more likely problem:
This makes sshd vulnerable to a denial of service (the exhaustion of all MaxStartups connections), but it makes it safe from this vulnerability. A denial of service attack is much easier to perform than the discovered exploit and much more likely to randomly happen to any range of IPs.
 
The SSH vulnerability has only been proven on 32-bit systems and under lab conditions with extensive efforts (several hours invested) so far. While it is assumed to be possible to exploit 64-bit systems as well, it seems to take considerable effort and at that point you really have to ask yourself if you are that much of a target for someone to invest such efforts to break into your Unraid system with a zero-day exploit. There's probably tons of companies out there vulnerable to this exploit right now and you think they're going to go for your Unraid server instead, to steal... what?
 
Unraid is designed for ease of use and not maximum operational security, so you shouldn't be exposing any services on your Unraid server directly to the internet. Forget SSH, reverse proxies... this should be non-negotiable - period. Users, on this subforum in particular, seem to be under the false impression that there's a point where they've taken enough steps to make Unraid safe to be exposed to the internet, this is a dangerous assumption made under a very false sense of security. A system running everything as root and not receiving in-place, zero-day security updates will never be 100% safe. Unraid is a file-server and a local network appliance aimed at providing you convenience at an acceptable degree of security (for use in your LAN - not WAN). Use it for what it can do.
 
Use a VPN to access your Unraid services from remote (if you must) and 99.99% you will not have to care about such things ever.
Put services you must directly expose inside VMs on operating systems that are designed for it, don't invest your efforts in the wrong place.
This is my personal opinion and not that of Lime Technology or any of the official Unraid staff members and/or creators.
 

I'm afraid your UPS doesn't seem to be supported at all, it cannot find or communicate with the device. NUT's hardware compatibility list also doesn't list that specific UPS as supported, so unfortunately it seems we're unlucky in this case.  You can try with Unraid's "UPS Settings" (which use a different program: APCUPSD) if maybe the device will be detected there - but I'm not very hopeful. 😞 
 

AP9827 is the most common cable and used by almost all APC UPS for USB - I'm pretty sure you have that one if it came with the UPS. But everything in this thread is guesswork at best, what we know for sure so far is that you tried it with two different cables (one of which is known to work with another UPS) on three different computers/OSes. That alone very strongly points to a fault with the UPS itself - I'm sorry I can't be of more help there.
 

Das kommt vom NUT Plugin, du hast vermutlich den "NUT Monitor Debug Level" auf "Level 2" (oder höher) eingestellt.
Stelle also bitte in den NUT Einstellungen "UPS Driver Debug Level" und "NUT Monitor Debug Level" beides auf "Default" ein.
 
Denn je höher der "Debug Level" umso mehr Nachrichten scheinen im Log auf (für Diagnostikzwecke), daher kommt das Problem. 🙂
 

Eaton Geräte haben üblicherweise einen Punkt bei ~20%, wo die USV ein LOWBATT (Niedrige Batterieladung) Event an den UNRAID Server sendet, welches immer (unabhängig von und zusätzlich zur Konfiguration) einen sanften Shutdown auslöst. Gerade wenn die Batterie älter ist, ist "Runtime Left" aber kein so zuverlässiges Kriterium mehr, weil es passieren kann, dass die Batterieladung schneller unter diese 20% fällt als die USV Runtime Left (welche vom "Normalzustand" der Batterie ausgeht) konfiguriert wäre. Bei älteren Batterien würde ich daher eher in Richtung des "Time on Battery before Shutdown" gehen und diesen großzügig und unter Berücksichtigung des Alters der Batterie setzen. Bei einer alten Batterie auf ca 1-2 Minuten max., wenn das Netz in unseren Breiten nicht nach 1-2 Minuten wieder da ist, ist es meist ohnehin länger im Ausfall als die USV es überbrücken könnte. Alternativ könnte man auch "Battery Level" als Kriterium nehmen, dann aber eben mit einem Wert über den 20%, damit es eine Wirkung hat.
 
Wenn die Batterie neuwertig ist, würde ich auch eher ein Kommunikationsproblem mit dem APC Daemon vermuten. Ich würde dir daher auch generell das NUT Plugin empfehlen, welches mehr Einstellungen und Diagnosemöglichkeiten bietet sowie mit Eaton sehr gut funktioniert (NUT wurde einige Zeit von Eaton selbst mitentwickelt).
 

I'm guessing it's because battery.charge.low is set or reported at 100% for some reason.
This'll basically shutdown your system if the battery drops just by 1% (likely to happen during testing).
You can configure this directly on your UPS or UPS software (what charge it considers as "low battery")
 
If this value is reported wrong from the UPS (say it's set to 30% on your UPS, but NUT still shows 100%)
You can override the value by putting into your ups.conf on line 15: override.battery.charge.low = 30
NUT should correctly report the battery.charge.low value then and act according to this value instead.
 
But make sure to attempt to set this value on your UPS first - this is something that should be set on UPS.
Only if it's set on UPS correctly and still reported wrong by NUT you should override the value via configuration: