natiz

I can't get Fan Control to work on Dell PowerEdge T420. On the Fan Control tab, a popup appears: But there's no Configure button (Fan control is indeed stopped). Note that I am able to control the fan manually using the ipmitool (installed via NerdTools), eg `ipmitool raw 0x30 0x30 0x01 0x00` and `ipmitool raw 0x30 0x30 0x02 0xff 0x20` to set it to 20%.

Thanks for the info, @BRiT. I found a workaround, updated to the TBS OS build, and used mksquashfs to append the missing fw file (dvb-demod-m88rs6000.fw) to bzfirmware and it worked!

Is there a guide on how to compile the kernel? I am looking to add the https://github.com/LibreELEC/dvb-firmware/blob/master/firmware/dvb-demod-m88rs6000.fw package to TBS version. I currently use the TBS CrazyCat build, but it seems its not updated anymore. This would allow me to use TBS6281SE for DVB-C and DVBSKy S952 V3 for DVB-S.

@CHBMB do you think dvb-demod-m88rs6000.fw can be added to the TBS OS build? if not can you please provide instructions how/where to run the build scripts to compile my own version of the kernel?

@alturismo I tried LibreELEC, but then my TBS card doesn't even show up 😕 I have 2 cards, TBS6281SE for DVB-C and DVBSKy S952 V3 for DVB-S. I rolled back to TBS Crazycat for now, this is how it looks: I think its because only dvb-fe-cx24117.fw is included in the TBS (OpenSource) build, see here: https://github.com/linuxserver/Unraid-DVB/blob/master/build_scripts/tbs-os-module.sh#L46-L55

I upgraded from TBS (CrazyCat) 6.7.2 build to the TBS (Open Source) 6.8.2 build and I'm having issues. It seems that dvb-demod-m88rs6000.fw is missing. It does seem to exist in their github repo: https://github.com/LibreELEC/dvb-firmware/blob/master/firmware/dvb-demod-m88rs6000.fw Can I install it manually? why is it missing?

Thanks saarg, I couldn't find anything in the thread. Can anyone else confirm?

What happened to the TBS (CrazyCat) builds? I only see TBS (OpenSource) on the dropdown. I am currently with the TBS (CrazyCat) DVB-S(2) & DVB-T(2) build v6.5.2 of unraid, wanting to upgrade to the latest.

Anyone? This is the error I get: EDIT: The CrazyCat seems to do the trick, although the devices are still ordered wried, but I guess its fine as long as it works

Quick question about which build to install - I have both a DVBSky S952, and TBS 6281SE. Until today I worked only with the DVBSky one with the LibreELEC build. Now that I want to use both, I first tried TBS (Open Source) 6.4.0.rc9f but then 2 issues had ocurred: 1) The DVBSky had failed on: "Direct firmware load for dvb-demod-m88rs6000.fw failed with error -2" (haven't tried the TBS one) 2) The order of the adapters was off (1 DVBSky, 2 TBS, 3 DVBSky, 4 TBS) With #2 I can live, but #1 makes me believe I am not using the right build - which one should I be using?

yep, working again - thanks!

+1 for the 6.3.5 / DVBSky issue mentioned above

Well, I feel a bit ashamed I tried removing/changing as you suggested, and then I started triple-checking my router is forwarding as it should As it turns out, I'm using a VERY old firmware version of DD-WRT (DD-WRT v24-sp2 (12/24/13) std). After some reading, there seem to be a known issue around NAT loopback/port forwarding which was fixed in later versions There's a workaround available but I decided to upgrade to the latest firmware, which seem to resolve the issue. All is working as expected - thanks @CHBMB

After reading a bit on certbot I think I understand better - the script runs certbot in standalone mode - it itself listens on 443 to perform the verification. I did some troubleshooting (built the image w/o the starter script, nginx turned off) from the container itself: certbot certonly --verbose --non-interactive --renew-by-default --standalone --preferred-challenges tls-sni --rsa-key-size 4096 --email "[email protected]" --agree-tos -d "x.mydomain.com" Same error, only this time, I ran watch on curl https://localhost, and after a few seconds, got this: After that certbot finished and from then it was connection refused (which is fine).. btw, here's my docker run cmd (Router routes both 443 and 80 to 443 and 81): docker run -d --name="letsencrypt" --net="bridge" --privileged="true" -e HOST_OS="unRAID" -e "EMAIL"="[email protected]" -e "URL"="mydomain.com" -e "SUBDOMAINS"="x," -e "ONLY_SUBDOMAINS"="true" -e "DHLEVEL"="2048" -e "PUID"="99" -e "PGID"="100" -p 81:80/tcp -p 443:443/tcp -v "/mnt/user/appdata/letsencrypt":"/config":rw linuxserver/letsencrypt

Yes its resolved and answered. I do think its trying to connect, as the error clearly says: also, see this: https://tools.ietf.org/html/draft-ietf-acme-acme-01#section-7.3

I can't seem to get this one up and running - and can't seem to figure out how anyone else did it The thing is, letsencrypt tries to validate my domain before nginx is even up - and that fails since no one is listening on port 443 (no nginx) Since this occurs on the init script, which fails, s6 terminates everything bringing the container down - so nginx doesn't even come up. How did you guys set it up? An easy fix for me would running another container with just nginx - but that misses the point of having both on the same container Here are my logs:

Care to share some of your solution? (even a half-baked docker file would do) what are you using to update the GoDaddy's zone file?

UPDATE: turns out I am using a custom plugin (running a script when disks are mounted, /usr/local/emhttp/plugins/z_custom_scripts/event/disks_mounted) I moved it from there for now, and array seems to start quickly Will have to see how to get it working w/ the new version of unRAID. Thanks!

Yes (and yes, it was probably a bad call ), I don't use any other plugins, just some docker containers I don't use any other plugins, perhaps I should downgrade dynamix back? (any help on how-to would be much appreciated)

Hi, I used the plugin manager to upgrade from 6.0 to 6.1 latest, and upgrade dynamix to the latest version After the upgrade, I rebooted the server, and started the array, but then it got stuck 'mounting disks'.. emhttp is not responding, but I can see that all disks are actually mounted (data accessible in ssh) The last logline in syslog is: emhttp: shcmd (94): /usr/local/sbin/update_cron &> /dev/null Here is the full log: Feb 7 21:07:54 NAS emhttp: Start array... Feb 7 21:07:54 NAS kernel: mdcmd (36): start STOPPED Feb 7 21:07:54 NAS kernel: unraid: allocating 26820K for 1280 stripes (4 disks) Feb 7 21:07:54 NAS kernel: md1: running, size: 1953514552 blocks Feb 7 21:07:54 NAS kernel: md2: running, size: 1953514552 blocks Feb 7 21:07:54 NAS kernel: md3: running, size: 1953514552 blocks Feb 7 21:07:54 NAS emhttp: shcmd (74): udevadm settle Feb 7 21:07:54 NAS emhttp: Mounting disks... Feb 7 21:07:54 NAS emhttp: shcmd (75): /sbin/btrfs device scan |& logger Feb 7 21:07:54 NAS logger: Scanning for Btrfs filesystems Feb 7 21:07:54 NAS emhttp: shcmd (76): mkdir -p /mnt/disk1 Feb 7 21:07:54 NAS emhttp: shcmd (77): set -o pipefail ; mount -t reiserfs -o noatime,nodiratime /dev/md1 /mnt/disk1 |& logger Feb 7 21:07:54 NAS kernel: REISERFS (device md1): found reiserfs format "3.6" with standard journal Feb 7 21:07:54 NAS kernel: REISERFS (device md1): using ordered data mode Feb 7 21:07:54 NAS kernel: reiserfs: using flush barriers Feb 7 21:07:54 NAS kernel: REISERFS (device md1): journal params: device md1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Feb 7 21:07:54 NAS kernel: REISERFS (device md1): checking transaction log (md1) Feb 7 21:07:54 NAS kernel: REISERFS (device md1): Using r5 hash to sort names Feb 7 21:07:54 NAS emhttp: shcmd (78): set -o pipefail ; mount -t reiserfs -o remount,user_xattr,acl,noatime,nodiratime /dev/md1 /mnt/disk1 |& logger Feb 7 21:07:54 NAS emhttp: reiserfs: resizing /mnt/disk1 Feb 7 21:07:54 NAS emhttp: shcmd (79): mkdir -p /mnt/disk2 Feb 7 21:07:54 NAS emhttp: shcmd (80): set -o pipefail ; mount -t reiserfs -o noatime,nodiratime /dev/md2 /mnt/disk2 |& logger Feb 7 21:07:54 NAS kernel: REISERFS (device md2): found reiserfs format "3.6" with standard journal Feb 7 21:07:54 NAS kernel: REISERFS (device md2): using ordered data mode Feb 7 21:07:54 NAS kernel: reiserfs: using flush barriers Feb 7 21:07:54 NAS kernel: REISERFS (device md2): journal params: device md2, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Feb 7 21:07:54 NAS kernel: REISERFS (device md2): checking transaction log (md2) Feb 7 21:07:54 NAS kernel: REISERFS (device md2): Using r5 hash to sort names Feb 7 21:07:54 NAS emhttp: shcmd (81): set -o pipefail ; mount -t reiserfs -o remount,user_xattr,acl,noatime,nodiratime /dev/md2 /mnt/disk2 |& logger Feb 7 21:07:54 NAS emhttp: reiserfs: resizing /mnt/disk2 Feb 7 21:07:54 NAS emhttp: shcmd (82): mkdir -p /mnt/disk3 Feb 7 21:07:54 NAS emhttp: shcmd (83): set -o pipefail ; mount -t reiserfs -o noatime,nodiratime /dev/md3 /mnt/disk3 |& logger Feb 7 21:07:54 NAS kernel: REISERFS (device md3): found reiserfs format "3.6" with standard journal Feb 7 21:07:54 NAS kernel: REISERFS (device md3): using ordered data mode Feb 7 21:07:54 NAS kernel: reiserfs: using flush barriers Feb 7 21:07:54 NAS kernel: REISERFS (device md3): journal params: device md3, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Feb 7 21:07:54 NAS kernel: REISERFS (device md3): checking transaction log (md3) Feb 7 21:07:54 NAS kernel: REISERFS (device md3): Using r5 hash to sort names Feb 7 21:07:54 NAS emhttp: shcmd (84): set -o pipefail ; mount -t reiserfs -o remount,user_xattr,acl,noatime,nodiratime /dev/md3 /mnt/disk3 |& logger Feb 7 21:07:55 NAS emhttp: reiserfs: resizing /mnt/disk3 Feb 7 21:07:55 NAS emhttp: shcmd (85): mkdir -p /mnt/cache Feb 7 21:07:55 NAS emhttp: shcmd (86): set -o pipefail ; mount -t reiserfs -o noatime,nodiratime /dev/sdf1 /mnt/cache |& logger Feb 7 21:07:55 NAS kernel: REISERFS (device sdf1): found reiserfs format "3.6" with standard journal Feb 7 21:07:55 NAS kernel: REISERFS (device sdf1): using ordered data mode Feb 7 21:07:55 NAS kernel: reiserfs: using flush barriers Feb 7 21:07:55 NAS kernel: REISERFS (device sdf1): journal params: device sdf1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Feb 7 21:07:55 NAS kernel: REISERFS (device sdf1): checking transaction log (sdf1) Feb 7 21:07:55 NAS kernel: REISERFS (device sdf1): Using r5 hash to sort names Feb 7 21:07:55 NAS emhttp: shcmd (87): set -o pipefail ; mount -t reiserfs -o remount,user_xattr,acl,noatime,nodiratime /dev/sdf1 /mnt/cache |& logger Feb 7 21:07:55 NAS emhttp: shcmd (88): sync Feb 7 21:07:56 NAS emhttp: shcmd (89): mkdir /mnt/user0 Feb 7 21:07:56 NAS emhttp: shcmd (90): /usr/local/sbin/shfs /mnt/user0 -disks 14 -o noatime,big_writes,allow_other |& logger Feb 7 21:07:56 NAS emhttp: shcmd (91): mkdir /mnt/user Feb 7 21:07:56 NAS emhttp: shcmd (92): /usr/local/sbin/shfs /mnt/user -disks 15 5120000000 -o noatime,big_writes,allow_other -o remember=330 |& logger Feb 7 21:07:56 NAS emhttp: shcmd (93): cat - > /boot/config/plugins/dynamix/mover.cron <<< "# Generated mover schedule:#0120 4 * * * /usr/local/sbin/mover |& logger#012" Feb 7 21:07:56 NAS emhttp: shcmd (94): /usr/local/sbin/update_cron &> /dev/null Could it be that the dynamix upgrade is acting up? I thought it might be docker but I don't think its initialized yet? docker version Client version: 1.7.1 Client API version: 1.19 Go version (client): go1.4.2 Git commit (client): 786b29d4 OS/Arch (client): linux/amd64 Get http:///var/run/docker.sock/v1.19/version: dial unix /var/run/docker.sock: no such file or directory. Are you trying to connect to a TLS-enabled daemon without TLS? What am I doing wrong?

Every time :\ will give it a try

Any thoughts on that saarg?

I assumed that since I wasn't able to find ffmpeg anywhere (for eg /usr/bin/ffmpeg) that its simply not there, hence can't be used for pipe. (integrated in tvheadend, but isn't accessible?) I did however try many variations, here's one: Result: FYI if anyone wondered how to get a shell for a docker container: docker exec -ti Tvheadend-Unstable /bin/bash

saarg, is there a way for you to include ffmpeg in the container? that way we can use tvheadend's pipe capabilities

I was able to resolve this by formatting the flash to FAT16. http://lime-technology.com/forum/index.php?topic=38160.msg353473#msg353473