devros

It's been a bad year for boot drives for me. My 2nd one this year now seems to be on the way out. Unfortunately my SM motherboard doesn't have any USB 2 ports. For now I can shut the server down, pull the USB drive, repair it on my Mac and my unraid server will boot again, but it's now getting to the point it will only last for a few days before linux kicks it offline. dmesg is filled with: [349517.230113] sd 0:0:0:0: [sda] tag#0 access beyond end of device [349517.230115] blk_update_request: I/O error, dev sda, sector 625365 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0 [349517.230123] sd 0:0:0:0: [sda] tag#0 access beyond end of device [349517.230124] blk_update_request: I/O error, dev sda, sector 625366 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0 [349517.230132] sd 0:0:0:0: [sda] tag#0 access beyond end of device [349517.230133] blk_update_request: I/O error, dev sda, sector 625367 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0 [349517.230141] sd 0:0:0:0: [sda] tag#0 access beyond end of device [349517.230143] blk_update_request: I/O error, dev sda, sector 625368 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0 [349517.230151] sd 0:0:0:0: [sda] tag#0 access beyond end of device [349517.230152] blk_update_request: I/O error, dev sda, sector 625369 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0 [349517.230160] sd 0:0:0:0: [sda] tag#0 access beyond end of device [349517.230167] sd 0:0:0:0: [sda] tag#0 access beyond end of device same thing happened to me in June so I can't automatically do a license transfer to a new thumb drive. I know the main bit of advice here is to use a USB2 port, but since I have none, does using a small USB2 hub plugged into a USB3 port make any sense? Also, based on the dmesg errors, I think I'm running out of runway before this totally dies. Is it possible to have the system allow me to do another USB change within a year. I have the full pro License. thanks, dev

Just installed 1.6a. Same issues. Using SG for primary display does not help

There is a 1.6 BIOS out now. Anyone tried it?

I recently did the upgrade to 1.5 and can report basically the same things @dumurluk had with 1.5. Lots of CMOS resets that afternoon :( Over the past few years I've ordered millions of dollars of SM server gear for our company's colos. I think I'm just going to forward this thread to our rep and tell them to escalate till it's fixed.

ok, phew. forgot I had auto backups on. reverted to 6.0.45, moved the old folder in appdata, fired it up and uploaded the right backup and all is well now. Think I'll stick with 6.0.45 for now

reverted to backup from a few days ago and same issue. Reverted the docker image back to one from a month ago and got: UniFi Controller startup failed We do not support upgrading from 6.1.71. Hoping I don't have to go to my appdata folder backup as I've made some changes since that was last Sunday

I just updated the docker to the latest version. Running 6.1.71. If I log in locally, there are no adopted devices. If I go in through the cloud it shows the site online with the right number of devices, clients, etc, but when I click launch, it connects and there is nothing there. If I relaunch the controller, I'll get alerts that all of my devices have reconnected, but nothing there in the GUI. anything obvious I might be missing? Thanks, -dev

wipefs -a /dev/sdx

Despite doing all the things in the post referenced above, my iKVM still cuts out when the OS takes over. It worked great for me on the previous builds. debating about trying 1.3

Two things I always do when repurposing a drive(not that it applies to this situation) is: 1) Remove all partitions 2) wipefs -a /dev/sdX I wish I'd known about that last one much earlier. Would have saved me a lot of grief with removing MD superblocks, ZFS metadata, etc...

See my previous post about the UNMS issue

Looking like the Plex server is going to survive the night without me having to pause. I was originally just going to remove a drive, but then realized I had a larger one that was already pre-cleared around, so figured I would just try to kill two birds with one reboot.

Two questions here. 1) if I'm running the command "dd bs=1M if=/dev/zero of=/dev/md1 status=progress" in screen so I can zero the drive and then remove it from the array without losing parity, is reason I couldn't just suspend the process this evening when the server is going to be under high use and then resume it much later tonight? Based on what it's doing I think that should be ok. 2) if I have a new, bigger drive that I have already pre-cleared could I just change the drive assignment and preserve parity?

I'm running the clear array drive script in a screen right now. In the evening, my server is under a pretty heavy load. Is there any issue in just doing a ctrl-z to pause the process and then resume it later? 2nd question. I have a cleared a drive and rather than remove it, want to replace it with a bigger drive that has already been pre-cleared, can I do that all in one step while preserving parity?