Leaderboard

Delete the file smart-one.cfg and re-apply the settings.

Yes SimonF the normal console was functional.

Reverting back to 6.8.3 If you have a cache disk/pool it will be necessary to either: restore the flash backup you created before upgrading (you did create a backup, right?), or on your flash, copy 'config/disk.cfg.bak' to 'config/disk.cfg' (restore 6.8.3 cache assignment), or manually re-assign storage devices assigned to cache back to cache This is because to support multiple pools, code detects the upgrade to 6.9.0 and moves the 'cache' device settings out of 'config/disk.cfg' and into 'config/pools/cache.cfg'. If you downgrade back to 6.8.3 these settings need to be restored.

@limetech is it possible to revert/disable these changes so we can look to see if its kernel/driver specific. emhttpd: detect out-of-band device spin-up I have reverted to 6.9.1 for now. For info I have replaced doron's Smartctl wrapper with r5215 of smartctl and its working fine in 6.9.1. and 6.9.2 for both SAS and SATA. Could it be updated for 6.10 or next 6.9 release? root@Tower:/usr/sbin# ls smart* smartctl* smartctl.doron* smartctl.real* smartd* root@Tower:/usr/sbin# smartctl smartctl 7.3 2021-04-07 r5215 [x86_64-linux-5.10.21-Unraid] (CircleCI) Copyright (C) 2002-21, Bruce Allen, Christian Franke, www.smartmontools.org ERROR: smartctl requires a device name as the final command-line argument. Use smartctl -h to get a usage summary root@Tower:/usr/sbin# smartctl -n standby /dev/sde smartctl 7.3 2021-04-07 r5215 [x86_64-linux-5.10.21-Unraid] (CircleCI) Copyright (C) 2002-21, Bruce Allen, Christian Franke, www.smartmontools.org Device is in ACTIVE or IDLE mode root@Tower:/usr/sbin# smartctl -n standby /dev/sdf smartctl 7.3 2021-04-07 r5215 [x86_64-linux-5.10.21-Unraid] (CircleCI) Copyright (C) 2002-21, Bruce Allen, Christian Franke, www.smartmontools.org Device is in STANDBY BY COMMAND mode, exit(2) root@Tower:/usr/sbin#

@limetech, @jonp Maybe this thread should be moved by a forum admin in the "General support" section. I initially posted it as a prerelease bug report as I discovered the issue when I installed the UPS and my server was on 6.9.0 beta30, but it's obviously Unraid version agnostic. Moreover, it's very likely an apcupsd package and/or UPS firmware issue with USB connection, as others report the same under various distros in the apcupsd general mailing list. Despite, as it is the built-in Unraid solution to communicate with UPSes, I think it would make sense to have this tested workaround visible for those who'd encounter the same problems but will very likely not find this thread buried in the prerelease bug reports section... Thanks in advance for considering this move for the community.

[I just spent 3 hours documenting the step by step work I'd been doing on this for logging in this thread. I have the same UPS and the same errors and the same problems. I don't use unRAID though but I'm sure it's nothing to do with unRaid. I've spent several nights attacking this problem from a low level USB /HID driver problem. Then, 5 minutes ago, I tried something different. And it fixed it. What... the... No guarantees, but here's what I did: # usb_modeswitch -v 0x051d -p 0x0003 --reset-usb (Check lsusb output to find out your vendor and product IDs) That's it. apctest works. apcaccess now reports ALL data.] Background: UPS: APC smc1500-2UC (same as the smc1500 but rack-mount. ) bios: 1.41, modbus enabled via front panel. ubuntu 20.04 apcupsd 3.14.14 apcupsd.conf: UPSCABLE usb UPSTYPE modbus DEVICE Unplug the usb cable then plug it back in. lsusb reports the device with the incremented port: root@sophie:/etc/apcupsd# lsusb Bus 001 Device 022: ID 051d:0003 American Power Conversion UPS dmesg shows: [Sun Jan 17 21:31:31 2021] usb 1-6.4: USB disconnect, device number 21 [Sun Jan 17 21:31:36 2021] usb 1-6.4: new full-speed USB device number 22 using xhci_hcd [Sun Jan 17 21:31:36 2021] usb 1-6.4: New USB device found, idVendor=051d, idProduct=0003, bcdDevice= 0.01 [Sun Jan 17 21:31:36 2021] usb 1-6.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [Sun Jan 17 21:31:36 2021] usb 1-6.4: Product: Smart-UPS_1500 FW:UPS 04.1 / ID=1018 [Sun Jan 17 21:31:36 2021] usb 1-6.4: Manufacturer: American Power Conversion [Sun Jan 17 21:31:36 2021] usb 1-6.4: SerialNumber: 3S2012X12122 [Sun Jan 17 21:31:36 2021] hid-generic 0003:051D:0003.001C: hiddev1,hidraw5: USB HID v1.11 Device [American Power Conversion Smart-UPS_1500 FW:UPS 04.1 / ID=1018] on usb-0000:00:14.0-6.4/input0 Making sure that apcupsd is not running, I can run apctest but get the following: root@sophie:/etc/apcupsd# apctest 2021-01-17 21:15:44 apctest 3.14.14 (31 May 2016) debian Checking configuration ... sharenet.type = Network & ShareUPS Disabled cable.type = USB Cable mode.type = MODBUS UPS Driver Setting up the port ... 0.837 apcupsd: ModbusUsbComm.cpp:142 ModbusRx: TIMEOUT Doing prep_device() ... 4.091 apcupsd: ModbusUsbComm.cpp:142 ModbusRx: TIMEOUT You are using a MODBUS cable type, so I'm entering MODBUS test mode Hello, this is the apcupsd Cable Test program. This part of apctest is for testing MODBUS UPSes. Getting UPS capabilities...SUCCESS Please select the function you want to perform. 1) Test kill UPS power 2) Perform self-test 3) Read last self-test result 4) View/Change battery date 5) View manufacturing date 10) Perform battery calibration 11) Test alarm Q) Quit Note that it glitches during initialisation but gets there in the end. Trying a safe function (Perform self-test) works, as does 'Read last self-test result'. However, the moment I exit apctest, the following appears in dmesg: [Sun Jan 17 21:17:27 2021] usb 1-6.4: reset full-speed USB device number 21 using xhci_hcd Ok, fine. apctest resets the device. However, if I try to re-run apctest immediately, the following occurs: root@sophie:/etc/apcupsd# apctest 2021-01-17 21:18:31 apctest 3.14.14 (31 May 2016) debian Checking configuration ... sharenet.type = Network & ShareUPS Disabled cable.type = USB Cable mode.type = MODBUS UPS Driver Setting up the port ... 0.289 apcupsd: ModbusUsbComm.cpp:258 WaitIdle: interrupt_read failed: Success 0.849 apcupsd: ModbusUsbComm.cpp:142 ModbusRx: TIMEOUT 1.402 apcupsd: ModbusUsbComm.cpp:142 ModbusRx: TIMEOUT 1.602 apcupsd: ModbusComm.cpp:201 SendAndWait: Wrong size (exp=7, rx=21) 1.674 apcupsd: ModbusComm.cpp:201 SendAndWait: Wrong size (exp=7, rx=21) 1.962 apcupsd: ModbusComm.cpp:201 SendAndWait: Wrong size (exp=21, rx=7) 2.033 apcupsd: ModbusComm.cpp:201 SendAndWait: Wrong size (exp=21, rx=7) ... followed by many, many more glitchy lines, and eventually the menu. Exiting apctest and trying to start up the apcupsd daemon causes the following to start appearing in the syslogs: [Sun Jan 17 21:19:28 2021] usb 1-6.4: reset full-speed USB device number 21 using xhci_hcd [Sun Jan 17 21:19:55 2021] usb 1-6.4: reset full-speed USB device number 21 using xhci_hcd [Sun Jan 17 21:19:57 2021] usb 1-6.4: reset full-speed USB device number 21 using xhci_hcd [Sun Jan 17 21:24:08 2021] usb 1-6.4: reset full-speed USB device number 21 using xhci_hcd [Sun Jan 17 21:25:09 2021] usb 1-6.4: reset full-speed USB device number 21 using xhci_hcd Which I assume is happening as a consequence of something "not quite right". Here's the (wrong) output of apcaccess when things aren't working: root@sophie:/etc/apcupsd# systemctl start apcupsd root@sophie:/etc/apcupsd# apcaccess APC : 001,018,0436 DATE : 2021-01-17 21:19:46 -0800 HOSTNAME : sophie VERSION : 3.14.14 (31 May 2016) debian UPSNAME : sophieUPS CABLE : USB Cable DRIVER : MODBUS UPS Driver UPSMODE : Stand Alone STARTTIME: 2021-01-17 21:19:43 -0800 STATUS : MBATTCHG : 5 Percent MINTIMEL : 3 Minutes MAXTIME : 0 Seconds NUMXFERS : 0 TONBATT : 0 Seconds CUMONBATT: 0 Seconds XOFFBATT : N/A STATFLAG : 0x05000000 END APC : 2021-01-17 21:19:46 -0800 And even when things are sort of working, here's the output of apcacess that still isn't any good: WIthout going into the 3 day jungle safari that has been my digging into learning the apcupcd code and how usb devices work when plugged into linux, suffice to say that I learned much about things I will never have a use for, but eventually worked out that I wanted to be able to disconnect and reconnect the usb device "at will", in the hopes of using the failed workaround documented by @Gnomuz. This led me through HID space and the frustrations of identifying the device path when something is plugged in. But then I discovered that 'mod_switch' has a reset parameter, and you only need to provide it with the Vendor and product IDs reported by 'lsusb'. Thus, the still-unbelievable simplicity of this: root@sophie:/etc/apcupsd# usb_modeswitch -v 0x051d -p 0x0003 --reset-usb Look for default devices ... Found devices in default mode (1) Access device 022 on bus 001 Get the current device configuration ... Current configuration number is 1 Use interface number 0 with class 3 Warning: no switching method given. See documentation Reset USB device . Device was reset -> Run lsusb to note any changes. Bye! Followed pessimistically by root@sophie:/etc/apcupsd# apctest 2021-01-17 22:38:48 apctest 3.14.14 (31 May 2016) debian Checking configuration ... sharenet.type = Network & ShareUPS Disabled cable.type = USB Cable mode.type = MODBUS UPS Driver Setting up the port ... Doing prep_device() ... You are using a MODBUS cable type, so I'm entering MODBUS test mode Hello, this is the apcupsd Cable Test program. This part of apctest is for testing MODBUS UPSes. Getting UPS capabilities...SUCCESS Please select the function you want to perform. 1) Test kill UPS power 2) Perform self-test 3) Read last self-test result 4) View/Change battery date 5) View manufacturing date 10) Perform battery calibration 11) Test alarm Q) Quit Select function number: q Where I noticed that I didn't get any of the glitch messages at all. I then repeatedly ran apctest over and over expecting errors, and got none. Anywhere. Still not believing anything, I started up apcupsd: root@sophie:/etc/apcupsd# systemctl start apcupsd and of course immediately tried the penultimate test, apcaccess. Which now reported this [you're gonna love this]: root@sophie:/etc/apcupsd# apcaccess APC : 001,038,0879 DATE : 2021-01-17 22:39:52 -0800 HOSTNAME : sophie VERSION : 3.14.14 (31 May 2016) debian UPSNAME : SophieUPS CABLE : USB Cable DRIVER : MODBUS UPS Driver UPSMODE : Stand Alone STARTTIME: 2021-01-17 22:39:45 -0800 STATUS : ONLINE LINEV : 118.4 Volts LOADPCT : 34.9 Percent LOADAPNT : 22.6 Percent BCHARGE : 98.4 Percent TIMELEFT : 28.0 Minutes MBATTCHG : 5 Percent MINTIMEL : 3 Minutes MAXTIME : 0 Seconds OUTPUTV : 118.4 Volts DWAKE : 0 Seconds DSHUTD : 180 Seconds ITEMP : 22.6 C BATTV : 26.0 Volts LINEFREQ : 60.0 Hz OUTCURNT : 2.75 Amps NUMXFERS : 0 TONBATT : 0 Seconds CUMONBATT: 0 Seconds XOFFBATT : N/A SELFTEST : OK STATFLAG : 0x05000008 MANDATE : 2020-03-17 SERIALNO : 3S2012X12122 BATTDATE : 2020-04-14 NOMOUTV : 120 Volts NOMPOWER : 900 Watts NOMAPNT : 1440 VA FIRMWARE : UPS 04.1 / 00.5 END APC : 2021-01-17 22:40:46 -0800 It's all there, and more. My current best guess is that something isn't being initialized properly, or reset properly, within the apcupsd / apctest code. But running usb_modeswitch resets it properly/fully. That'll do me.