kode54

Bumping this old topic to get it some more attention. Especially since a branch with Nexenta ZFS based TRIM support is waiting to be accepted into the main line. I for one would love to see ZFS support replace BTRFS use. Create n-drive zpool based on the current cache drive setup, and create specialized and quota limited ZFS datasets for the Docker and libvirt configuration mount points. Yes, Docker supports ZFS. And from what I've seen, one only wants to stick with BTRFS on a system they're ready to nuke at a moment's notice.

Proposing the inclusion of the atop package from Slackbuilds, for moments where it may be useful to monitor which resources may be maxing out in a system. It will handily display color coded load percentages for memory and disks, and blink a status line red if it's being maxed out. May be useful in tracking down overburdening issues some people are experiencing.

Does this need fstrim to be run on it daily? E: This may be relevant: https://github.com/zfsonlinux/zfs/pull/3656 E2: I have successfully built this using the vbatts/slackware container as a basis, with the following packages from Slackware64 14.1: attr-2.4.46-x86_64-1.txz autoconf-2.69-noarch-1.txz automake-1.11.5-noarch-1.txz bc-1.06.95-x86_64-2.txz ca-certificates-20160104-noarch-1.txz curl-7.31.0-x86_64-1.txz cyrus-sasl-2.1.23-x86_64-5.txz gcc-4.8.2-x86_64-1.txz gcc-g++-4.8.2-x86_64-1.txz git-1.8.4-x86_64-1.txz glibc-2.17-x86_64-7.txz kernel-headers-3.10.17-x86-3.txz less-451-x86_64-1.txz libmpc-0.8.2-x86_64-2.txz libtool-2.4.2-x86_64-2.txz m4-1.4.17-x86_64-1.txz make-3.82-x86_64-4.txz perl-5.18.1-x86_64-1.txz zlib-1.2.8-x86_64-1.txz And the following from Slackware64 14.2, due to a bug in how the Git package was built: cyrus-sasl-2.1.26-x86_64-1.txz Begin by preparing a kernel directory, which involves fetching a matching kernel's source package, applying all patches from unRAID's /usr/src, and copying any new files. Then make oldconfig and make to build it, and you'll have a tree for the Slackbuild packages for spl-solaris and zfs-on-linux. You'll also need to follow the comment I posted at the bottom of the train at that pull request, since it outlines an spl commit that's not in master yet, to rebase the ntrim branch against. Otherwise, rebase the zfs tree against upstream/master, which is github.com/zfsonlinux/zfs.git. Then: LINUXROOT=/root/linux-whatever ./spl-solaris.SlackBuild Then the zfs-on-linux.SlackBuild needs to be modified to pass a --with-spl=/tmp/SBo/spl-your-version. E3: Now running spl:master and zfs:ntrim on unRAID 6.3.0-rc6. Fine so far, but benches slightly slower. Strange. Alternative to echoing stuff to /sys config variables is to create a full zfs.conf of settings to apply, depending on which types of devices you'll be pooling, and copying that to /etc/modprobe.d before modprobe zfs.

E: Please move this to CA Application auto update topic. The new version creates this crontab entry: Missing the leading slash there. Results in a notice to my email: Subj: cron for user root /usr/local/emhttp/plugins/ca.update.applications/scripts/updateApplica tions.php >dev/null 2>&1 Message: /bin/sh: dev/null: No such file or directory

And how do you plan to reduce? Remove one of the DIMMs, crippling it to single channel? Or actually swap both out for 2x2GB? You are aware that it will be using all of the memory available to it as cache, right?

Possible addition to this script: Enabling Hibernate / suspend-to-disk inside respective VMs, then using virsh dompmsuspend <domain> disk to save for the backup. This does, of course, assume your VMs are in a position to be suspended, and if they are not configured to suspend, they will likely shut down anyway.

At least until it dies of bit rot, which it may do faster when it has the power removed for an extended period.

It has to do with how the plugin is scripted to detect the emhttp docroot: <!-- DOCROOT script. --> <FILE Name="/tmp/&name;/docroot" Mode="0770"> <INLINE> #!/bin/bash DOCROOT=`grep -Po '^chdir = \K.*' /etc/php-fpm.d/www.conf` if [ -z ${DOCROOT} ];then DOCROOT="/usr/local/emhttp" fi echo ${DOCROOT} </INLINE> </FILE>

I currently have all of those features disabled in my VM, because I am using Nvidia drivers with a GTX 960 in passthrough, which will disable the card with a code 43 if it detects any of them.

virt-manager isn't included by default, but I assume you already had that tap configured on your system. And I guess the developer already updated their libvirt-python package reference. Glad I could help, though.

Setting it up in Sierra is not terribly difficult. For now, the only hurdle is the libvirt-python version used. 1) brew tap jeffreywildman/virt-manager 2) brew edit virt-manager, search for "2.1.0", which should locate the libvirt-python link. Replace version number with "2.4.0", and replace the sha256 sum with "aa087cca41f50296306baa13366948339b875fd722fc4b92a484484cd881120c". 3) brew install virt-manager virt-viewer. 4) Due to outstanding issue #62 with jeffreywildman/virt-manager, remember to supply --no-fork switch when invoking virt-manager from the Terminal. E1: Something I just remembered. KVM+Qemu does support saving snapshots, but if you have any hardware passthrough, it doesn't support saving snapshots of a running VM.

Maybe leave it as an alternative and make the two mutually exclusive? Also, since one requires removing the other, it may make sense that switching off a package also removepkg:s it from the current running instance, since it would otherwise require a reboot or manual removepkg to get rid of it.

16GB, and what's with all the non-power-of-two denominations?

Can we get netcat-openbsd in this kit any time in the future? Both it and its dependency, libbsd, have SlackBuilds scripts available, and I've verified that the latest built from Slack 14.2 runs on unRAID 6.3-rc3. This version of netcat is needed for things like connecting to Unix sockets, which is required to support virt-manager and other libvirt tools connecting using the qemu+ssh protocol, which connects to an ssh session and pipes traffic to the specified Unix socket using netcat. SlackBuilds.org https://slackbuilds.org/repository/14.2/network/netcat-openbsd/ https://slackbuilds.org/repository/14.2/libraries/libbsd/ You will need to remove the default nc package before it will let you build netcat-openbsd.

It also appears that you are configuring libvirtd to be an unauthenticated listener on all interfaces. The less usual approach I am used to seeing is to install netcat-openbsd, which requires a different Slack package than the one provided in NerdPack, and configure the virt-manager connection from a command line: virt-manager -c qemu+ssh://root@tower/system?socket=/var/run/libvirt/libvirt-sock Once this has been run, assuming the server has a version of the Netcat command supporting the -U switch to connect to Unix sockets, it should be able to pass through to libvirtd. Once this has been added to virt-manager, it should persist across restarts. Furthermore, there is also a Homebrew tap on Github for virt-manager and virt-viewer, and it only requires a two line modification to the virt-manager.rb (brew edit virt-manager) to import a newer version of libvirt-python to bypass a compile time error which occurs on Sierra systems. Also, due to another bug with Sierra, this virt-manager will require the --no-fork switch to prevent a startup crash, but can still be launched into the background by appending an ampersand (&) to the command line. E 1: Okay, here's what you need for a more secure connection path that doesn't require a libvirtd.conf edit: You'll need libbsd and netcat-openbsd. You'll need a Slackware 14.2 install or the live DVD to build them. 1) Download the SlackBuilds and source packages for the above from the root account. 2) Unpack libbsd.tar.gz. 3) cd to libbsd. 4) ln -s ../libbsd-0.8.3.tar.gz ./ 5) ./libbsd.SlackBuild Now you'll have a libbsd package in /tmp/. 1) installpkg /tmp/libbsd*.tar.gz 2) cd back to root, or .. from the above steps. 3) Unpack netcat-openbsd.tar.gz. 4) cd to netcat-openbsd. 5) ln -s ../netcat-openbsd_* ./ 6) removepkg nc 7) ./netcat-openbsd.SlackBuild Now you'll also have a netcat-openbsd package in /tmp/. Transfer both of these packages to a share on unRAID: 1) scp /tmp/*.tar.gz root@<tower ip>:/mnt/user/<share>/ Now you may install them from unRAID SSH or Telnet: 1) cd <wherever you copied them> 2) If you have NerdPack GNU netcat installed, disable it in the NerdPack UI, which doesn't actually remove it, then run removepkg nc. 3) installpkg libbsd*.tar.gz 4) installpkg netcat-openbsd*.tar.gz

What about QED? That supports snapshots as well, and I've at least "heard" there may be better performance from QED versus QCow2, but it needs testing.

You'd have to be nuts to use a shingled drive in an array like this. Figure 20GB of the drive is dedicated write cache. Every time sustained writes fill that up, the drive locks in a busy cycle until it flushes the cache in a slow stream of read-modify-write cycles to the shingled storage area. Or you could wait for someone to invent a desktop file system and operating system that can handle this at the host level. Probably won't happen any time in the next decade for consumer or prosumer accessible software. Just because you can do it, doesn't mean that you necessarily should.

Some of this may be useful for me, I'm going to install 10.6 or 10.7 in a VM. The problem is, both of those require this DSDT patch from 2014, which didn't make it into the 2.5 stable line, according to the Git branch for the 2.5 series. So, I guess I'm going to be installing 6.3 sooner than its stable release, after all. (Without that patch, I find that both Q35 and PIIX KP with the dreaded HPET error, and I can't seem to make it boot at all with a strictly uniprocessor setup.)

GT 610 is a rebranded 5xx series card, so it will require Seabios, as I pointed out in another topic.

You could have installed the "realpath" package: sudo apt-get install realpath Or, I suppose the script could be written to implement it on its own instead of assuming it comes with the system: http://unix.stackexchange.com/questions/101080/realpath-command-not-found

Still waiting on that record engine update.

I noticed the problem a bit late. There's an untagged MPEG 4 video file (music video) in the root of the music folder. It would have been helpful if the tool actually told me more about the non-matching file, such as its file name. About the point where it found its first incorrect result from MusicBrainz (someone didn't spell correct their Japanese romanizations. "Yoshi's Cookey"?) I gave up on using it and decided to use Picard from a desktop instead. E: I decided to give it a go anyway. It seems to work for the most part, but it's failing to identify some things. For instance, it identifies all my DVD-A rips as similar to the CD versions of those albums, with no way to tag them as the DVD parts of those releases.

I use CA, but I also read the forum, and didn't think to check CA for the particular container I found missing from this topic. It didn't matter for the sake of running that app anyway, as I currently prefer to run it on a VPS.

If I do that, I see all of the subdirectories which contain my music. I have a structure already, but I am trying to see if Beets can help with organizing it. For the most part, I have: /mnt/user/Music/<artist>/<album>/<files> /mnt/user/Music/Various Artists/<album>/<files> There are a few directories where I'm not sure I want any renaming or moving to happen.

I would not be surprised to find that your host CPU is just too fast for it. Also, an entire 512MB of RAM? I would not think of putting much more than 32MB or 64MB in a Windows 98 SE machine.