nicr4wks

Members
  • Posts

    31
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

nicr4wks's Achievements

Newbie

Newbie (1/14)

2

Reputation

  1. Just to close this off, removing the drives from the backplane and hooking up with sas > sata breakout cable has fixed the issue.
  2. Good catch, I only focused on the disk that dropped 🤦‍♂️ It seems to be all of the disks in the same cage chucking up that error, I might remove the backplane and hook up a sas breakout cable for testing.
  3. The differences are explained here: https://www.home-assistant.io/faq/ha-vs-hassio/ You should really create your own thread on the HA forums or HA reddit.
  4. .xz is a compressed file. use tar on unraid or 7zip/winrar on windows.
  5. @comet424 the version you have installed does not include the addons. https://community.home-assistant.io/t/hassio-on-unraid/59959 https://www.juanmtech.com/get-started-with-node-red-and-home-assistant/ https://www.home-assistant.io/integrations/mqtt/
  6. There are literally hundreds of home assistant videos for dummies, what you want to do is not a standard setup and is going to require some thinking of your own. You can run HASSOS in a VM on unraid, this will get Home Assistant up and running for you. You can install NodeRED on to Home Assistant to create drag and drop automations. Setup MQTT on Home Assistant, then look for MQTT clients for your pi clients that can control the gpio pins. Use the Home Assistant dashboard to create clickable on/off switches.
  7. Hi All, I've recently migrated from 12 x 1tb disks to 4 x 8tb. Also moved to a completely new hardware configuration (from a HP z620 machine to a HP ml350p g8). Was running great for the first couple of weeks but now I'm getting disks going offline 'contents emulated' with what I think might be controller issues. Dec 20 00:04:58 Tower kernel: mpt2sas_cm0: log_info(0x31110d01): originator(PL), code(0x11), sub_code(0x0d01) Dec 20 00:04:58 Tower kernel: mpt2sas_cm0: log_info(0x31110101): originator(PL), code(0x11), sub_code(0x0101) ### [PREVIOUS LINE REPEATED 3 TIMES] ### Dec 20 00:04:58 Tower kernel: sd 1:0:2:0: [sdd] tag#371 UNKNOWN(0x2003) Result: hostbyte=0x0b driverbyte=0x00 Dec 20 00:04:58 Tower kernel: sd 1:0:2:0: [sdd] tag#371 CDB: opcode=0x8a 8a 00 00 00 00 03 43 5d 63 18 00 00 04 00 00 00 Dec 20 00:04:58 Tower kernel: print_req_error: I/O error, dev sdd, sector 14015095576 Dec 20 00:04:58 Tower kernel: md: disk0 write error, sector=14015095512 I have a 4 bay drive cage connected via mini-sas to a HP expander card, which is linked to a 9210-8i in IT mode. I also have an 8 bay SFF cage connected to the same expander (sdb-sdk disks are unassigned). I've removed all array disks and re-installed them to different slots, I've also re-seated power and sas cables, this same drive cage and sas cable were working fine on my last hardware configuration. The issue does not follow the disk and it does not stick with the same drive bay on the cage. Prior to swapping the drives around I was getting the same error on ST8000DM004-2CX188_ZCT3CWNF (sdc) sd 1:0:1:0 AFTER swapping the disks the errors are now on ST8000DM004-2CX188_ZCT3BKZH (sdd) sd 1:0:2:0 Before swapping the disks I ran an extended SMART test on ST8000DM004-2CX188_ZCT3CWNF which came back OK. Anyone know what could be causing this? Thanks. tower-diagnostics-20201220-1204.zip
  8. Bugger! QB was looking good for a minute there, i will load in over 1k just by moving away from Transmission, which has been my client of choice for the last 10 years and it's been perfect, especially the remote client but it's becoming more and more of a nightmare to deal with. As torrents are becoming larger I've been getting pita issues (50gb blurays or 500gb mame sets) Transmission will completely lock up when disk operations take place on these large torrents. Even downloading at speeds over 150mbit causes random hangs. Transmission does everything under the 1 worker thread so if it's waiting for a file to verify, move on a disk or receiving too quick the gui will stop responding and other torrents will stall until that task has completed. It's been an issue for over 12 years https://trac.transmissionbt.com/ticket/1753 I guess I'll start investigating rtorrent instead.
  9. Thanks, I've just installed the docker for the first time and after changing the web-ui port it would come up with the unauthorized error, this let me log in.
  10. Has anyone else noticed resource issues with large torrents in 3.00? Loading up a big torrent (latest MAME CHD in this instance) causes transmission to use 100% CPU which lags web/remote interface and also causes download speeds to drop (getting 40mbit). Roll back to 2.94 (linuxserver/transmission:2.94-r3-ls53) load up the same torrent and CPU sits around 40%, UI stays responsive and speeds use my full 250mbit.
  11. I've heard nothing, can you SSH in to your server and run top would be interesting to see if yours has the same stuck shfs process. Also tried downgrading to 6.8.2 where problem is still present.
  12. Thanks for taking a look. It's running on a HP Z600 workstation, the motherboard is identified as "Hewlett-Packard 158A Version 0.00" I have 1 device passed through to a VM which is a "RealtekCorp. RTL2838 DVB-T (0bda:2838)" connected via USB. I should also mention that when the issue occurs I have tried stopping ALL VM's and dockers and this does not change any of the symptoms at all. I'll physically remove the realtek USB device and keep the VM off over the next week for testing, I'll also note that this hardware configuration has not changed and run flawless for the last 4 years. I do not believe network performance plays any part in this, I mentioned in the original post that when SMB is not responding/running slow I can use SCP over the same network from the same client computer to directly access the disks at full speed. It seems like whatever the shfs process is stuck doing is the cause of the performance issue.
  13. Hi All. I've been trying to track down this intermittent issue for the last couple of weeks. ** EDIT - as of an hour ago restarting unraid no longer fixes the issue, samba is constantly slow/inaccessible ** ** Double edit - after running for 5hrs server has recovered and operational again ** It becomes apparent as samba shares from unraid will become incredibly slow, browsing folders takes ~10 seconds to load each directory and transfers to/from the server crawl to <5KB/s from each client. While the transfer issues are present I have noted this process consumes 100% of 1 core and sits like that for hours: /usr/local/sbin/shfs /mnt/user -disks 4094 -o noatime,allow_other -o remember=0 To get the server to resume normal operation it needs to be restarted which can be done via the GUI fine. Other parts of unraid continue to work without issue, VM's are at full speed, Docker responsive, WebGUI loads fine. I can even access disks via SCP at full speed, it's just samba that dies. In previous threads shfs problems seem to stem from reiserfs disks of which I have none, also no cache drive. Any ideas? Unraid: 6.8.3 CPU: Intel® Xeon® CPU E5-1620 @ 3.60GHz Memory: 56 GiB DDR3 Multi-bit ECC Network: eth0: 1000 Mbps, full duplex, mtu 1500 tower-diagnostics-20200617-1109.zip
  14. https://forums.lime-technology.com/topic/46550-debian-84-vm-uhhuh-nmi-received-for-unknown-reason-20-on-cpu/?page=2 Have a read through the second page here.