devros

Members
  • Content Count

    67
  • Joined

  • Last visited

Community Reputation

8 Neutral

About devros

  • Rank
    Newbie

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

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

  1. 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.
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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...
  7. 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.
  8. 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?
  9. 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?
  10. Now I'm a little curious to see how AFP performs
  11. For anyone still having issues with the UNMS container, see the issue I created. https://github.com/Nico640/docker-unms/issues/22#issuecomment-578910768 Basically you have to specify the cache specifically for the config directory, even if you have the appdata share set to always use the cache
  12. I'll try in the next day or two when I have the time.