SSD

Moderators
  • Content count

    7718
  • Joined

  • Last visited

  • Days Won

    12

SSD last won the day on February 2

SSD had the most liked content!

Community Reputation

258 Very Good

1 Follower

About SSD

  • Rank
    unRAID Revolutionary

Converted

  • Gender
    Male
  • Location
    USA
  • Personal Text
    ASRock E3C224-4L/A+, SM C2SEE/B, Asus P5B VM DO/C
  1. [Support] Linuxserver.io - Plex Media Server

    I had reserved 25% more space for the metadata, and copied the old to the new and it fit (as expected). But seems Plex wanted to do some database update and it immediately ran out of space. Turns out BTRFS was taking about 25% more space to store than XFS! So it used up all of the excess and the upgrade failed. Going back to XFS for the metadata. I am keeping in a loopback file to avoid the huge file count and associated headaches on the cache drive.
  2. [Support] Linuxserver.io - Plex Media Server

    Was just posting. I ran out of space. Fixed and now the Plex docker is up! Thanks!!
  3. [Support] Linuxserver.io - Plex Media Server

    Need a little help. I am trying to move my Plex installation from serverA to serverB. I copied over the appdata folder to the new server. Installed the my_plex template. Tweaked the mappings a little to match new server. And started the docker. But the WebUI refuses to connect. And in the log it continues to say "Starting Plex Media Server." over and over - updating every 15 seconds or so. See detailed log below. Any help appreciated. How do I debug this to understand what might be going wrong. The server name is different and the IP address is different, everything else is same. Thanks! ------------------------------------- _ () | | ___ _ __ | | / __| | | / \ | | \__ \ | | | () | |_| |___/ |_| \__/ Brought to you by linuxserver.io We gratefully accept donations at: https://www.linuxserver.io/donations/ ------------------------------------- GID/UID ------------------------------------- User uid: 99 User gid: 100 ------------------------------------- [cont-init.d] 10-adduser: exited 0. [cont-init.d] 30-dbus: executing... [cont-init.d] 30-dbus: exited 0. [cont-init.d] 40-chown-files: executing... [cont-init.d] 40-chown-files: exited 0. [cont-init.d] 50-plex-update: executing... ##################################################### # Login via the webui at http://<ip>:32400/web # # and restart the docker, because there was no # # preference file found, possibly first startup. # ##################################################### [cont-init.d] 50-plex-update: exited 0. [cont-init.d] done. [services.d] starting services Starting dbus-daemon Starting Plex Media Server. dbus[271]: [system] org.freedesktop.DBus.Error.AccessDenied: Failed to set fd limit to 65536: Operation not permitted [services.d] done. Starting Plex Media Server. Starting Avahi daemon Found user 'avahi' (UID 106) and group 'avahi' (GID 107). Successfully dropped root privileges. avahi-daemon 0.6.32-rc starting up. No service file found in /etc/avahi/services. *** WARNING: Detected another IPv4 mDNS stack running on this host. This makes mDNS unreliable and is thus not recommended. *** *** WARNING: Detected another IPv6 mDNS stack running on this host. This makes mDNS unreliable and is thus not recommended. *** Joining mDNS multicast group on interface vnet0.IPv6 with address fe80::fc54:ff:fec8:a4c0. New relevant interface vnet0.IPv6 for mDNS. Joining mDNS multicast group on interface virbr0.IPv4 with address 192.168.122.1. New relevant interface virbr0.IPv4 for mDNS. Joining mDNS multicast group on interface docker0.IPv4 with address 172.17.0.1. New relevant interface docker0.IPv4 for mDNS. Joining mDNS multicast group on interface br0.IPv6 with address fe80::7804:13ff:fec6:9dc6. New relevant interface br0.IPv6 for mDNS. Joining mDNS multicast group on interface br0.IPv4 with address 192.168.1.252. New relevant interface br0.IPv4 for mDNS. Joining mDNS multicast group on interface bond0.IPv6 with address fe80::7285:c2ff:fe54:d3c3. New relevant interface bond0.IPv6 for mDNS. Network interface enumeration completed. Registering new address record for fe80::fc54:ff:fec8:a4c0 on vnet0.*. Registering new address record for 192.168.122.1 on virbr0.IPv4. Registering new address record for 172.17.0.1 on docker0.IPv4. Registering new address record for fe80::7804:13ff:fec6:9dc6 on br0.*. Registering new address record for 192.168.1.252 on br0.IPv4. Registering new address record for fe80::7285:c2ff:fe54:d3c3 on bond0.*. Server startup complete. Host name is merlin.local. Local service cookie is 3021989262. Starting Plex Media Server. Starting Plex Media Server. Starting Plex Media Server. Starting Plex Media Server. Starting Plex Media Server. Starting Plex Media Server. Starting Plex Media Server. Starting Plex Media Server. Starting Plex Media Server. Starting Plex Media Server. Starting Plex Media Server. Starting Plex Media Server. Starting Plex Media Server. Starting Plex Media Server. Starting Plex Media Server. Starting Plex Media Server. Starting Plex Media Server. Starting Plex Media Server. Starting Plex Media Server. Starting Plex Media Server. Starting Plex Media Server. Starting Plex Media Server. Got SIGTERM, quitting. Leaving mDNS multicast group on interface vnet0.IPv6 with address fe80::fc54:ff:fec8:a4c0. Leaving mDNS multicast group on interface virbr0.IPv4 with address 192.168.122.1. Leaving mDNS multicast group on interface docker0.IPv4 with address 172.17.0.1. Leaving mDNS multicast group on interface br0.IPv6 with address fe80::7804:13ff:fec6:9dc6. Leaving mDNS multicast group on interface br0.IPv4 with address 192.168.1.252. Leaving mDNS multicast group on interface bond0.IPv6 with address fe80::7285:c2ff:fe54:d3c3. avahi-daemon 0.6.32-rc exiting. [cont-finish.d] executing container finish scripts... [cont-finish.d] done. [s6-finish] syncing disks. [s6-finish] sending all processes the TERM signal. [s6-finish] sending all processes the KILL signal and exiting.
  4. Sorry - you don't pass through IOMMU groups. The IOMMU groups determine if the passthrough will work. Related to your GPU pass through, I have not experienced the issue you mention with white pixels. It may be something with the video card drivers (I'd make sure running latest Nvidia drivers). Could also have to do with USB passthrough I suppose. If drivers are up to date I would ignore it for now. Once everything is passed through, and if it continues, then focus on that. Sorry don't know what you mean by "group" 15 and 27 have same ID numbers. If you follow the tutorial above, post the results of the queries, including the one that shows "RESET" statuses, and I'll have a look and may be be able to understand what you are talking about. You really need USB devices to be installed for it to be useful. You also need to remove the "vfio-pci.ids=" from the syslinux.cfg file before running the commands.
  5. File system is readonly

    You can always reformat an array disk. The format is nothing but data to unRAID, and parity will be reflected. The easiest way is to stop the array, and change the filesystem on that drive to RFS or BTRFS. Then start the array. it will appear unformatted, and you can format it to the new FS. Then you can stop the array again, change the filesystem back to XFS, and start the array again. The disk will again show unformatted, and you can format it to XFS. You now have a freshly formatted XFS disk.
  6. Major overhaul - Advice sought

    I'll be more direct. DO NOT buy a controller based on the Marvell chipset for use with unRAID. May appear to work, but there have just been too many disks that get dropped offline because of these controllers, especially with VMs. For about $50 you can get an LSI 9201-8i, which give 8 internal ports with no flashing. There are a plethora of similar controllers (e.g., LSI 9211-8i, Dell H310, IBM M1015) that can be flashed into IT mode that are equally good. But don't get a Marvell card.
  7. There is a free tool called "TeamViewer that you can install in Windows on your home network. And you can install the Teamviewer client on a variety of devices (even phone and tablet). Once installed, you can access your Windows workstation from a computer on the internet. Obviously you want a strong password, but it is hardened for Internet use and won't be hacked (or at least the risk is very low). Once connected you are remote controlling the workstation, which would let you access your files as though you were sitting at home. It also has upload/download features depending on the client you are using. Is this what you are looking to do?
  8. VM's Hosted on SSD - TRIM?

    I saw this thread for first time today. I have a question about changing the controller to virtio-scsi. 1 - How is this different than making the disk img into a sparse file? I've seen instructions on re-sparsifying an .img file posted. 2 - If basically the same result, which is better method? 3 - If there is plenty of free space on the SSD, is there any big benefit of releasing the blocks to trim? 4 - I have had problems with sparse files confusing standard commands (even cp and 7zip), and abandoned using them. Is this strongly recommended? Or just an option if your SSD size is tight. @Marv - I am seeing same thing. Below is my defrag schedule. The C: drive is a .img located on an NVMe showing solid state The D: drive is a .img file located on a hard disk (unassigned device) showing hard disk. The Recovery and bottom one (volume faa...) - I have no idea what they are used for, but they are also showing solid state. So there seems some info is being communicated from KVM on the nature of the underlying media containing the IMG. This is unexpected but pretty cool. I wonder if you moved the .IMG file to a hard disk and tried to use it, if it would show it was now on a hard disk?? Assuming yes.
  9. The BR10i is limited to 2T and smaller drives. But I know of no reason why the motherboard would not see it. You are sure the board is good? It works in the other MB.
  10. I have to work on the "seamless" part. They are on 2 different servers and IP addresses are different. But it is enough that I know how and can assist my wife to get to her content! Important that Plex DVR can continue to record livetv - anything missed cannot be recovered!
  11. You might consider a second license at some point in the future. Many of us that put our eggs in the unRAID basket decide to stand up a backup server. Until recently my backup server has been data backup only. But now I am setting things up so that i can switch my Dockers and VM over to my backup server if even the primary should have issues and I need to take it down. A backup key could be repurposed to use on the PROD server if needed.
  12. Yep - i said basically same thing earlier in the thread, but you said it better. Up until six months to a year ago, I would have said I could live forever on the version d'jour. Now I do not feel that way. 6 months? probably. A year? maybe. 2 years? probably not. But this scenario seems very very unlikely. Tom is showing no signs of slowing. A sale seems more likely. And if he does get hit by a bus, he has already said that information about the proprietary parts of unRAID would be released to enable what @wayner mentions above. Related to the USB stick - understand that Tom uses this to protect his asset from piracy. And it works very well from what I have seen. And debating that the USB is an unreliable device, the way unRAID uses it, is not supported by the facts. In fact quite the opposite. The USB dependency is not going to change any time soon. I don't think comparing it to a USB stick used in the car is valid. You have condensation, large temperature variations, vibrations/jarring, in and out of your pocket, and continuous use. I would not expect such a device to do very well in the long term. But many here have unRAID keys that are 2, 5, even 10 years old that work fine. They are very lightly used and in a very steady operating environment. The biggest risk is physical damage, like snapping it off while walking past. Which is why the more compact sticks are recommended. My advice - don't sweat it.
  13. Hardware Upgrade Question

    See my post above. For basic NAS you are right. But for VMs and maybe some Dockers, there will be changes required.
  14. Hardware Upgrade Question

    This is true unless you are doing VMs or limiting Dockers to specific cores. There are two basic issues. One is that the # of cores and/or core pairings may be different. And for passthrough of hardware, the IOMMU groups and hardware addresses are difference. It is a good idea for VMs to recreate that VM template on the new motherboard, pointing to the existing vdisk file. Go back to the video or instructions you originally used and go through the process on the new motherboard. And to remove core limitations on your Dockers in the old motherboard configuration, and then rethink those in light of the new CPU once you move them over.
  15. Where does the data come from on the dashboard? If seems a more accurate source.

Copyright © 2005-2017 Lime Technology, Inc. unRAIDĀ® is a registered trademark of Lime Technology, Inc.