Jump to content

dgs2001

Members
  • Content Count

    14
  • Joined

  • Last visited

Community Reputation

3 Neutral

About dgs2001

  • Rank
    Member
  1. Hi All, Whilst setting up a pfsense VM I am getting stuck. Once the install is done the VM will not start, it reports the following error - Looking at the log I can see the following- I have had a poke around using my limited skills and discovered the following - The hardware in question is an Intel quad port nic card which is passed through IOMMU (vfio-pci.ids=8086:10bc) as so - Can somebody please explain how I would pass to the VM? or even pass the option rom file which I have? Thanks
  2. Hi Djoss, Thankls for the clarification, I have this sorted now. I was looking in the 'Preferences' menu instead of the encoder list. I have now selected the encoder as 'nvenc' and confirm all is working and can be seen with the watch nvidia-smi command in terminal. Happy to report that enoding with nvenc on a quattro p2000 is roughly 10 times faster than using ten cores/threads of the 2 xeon cpu's I have so thanks for the great work you do
  3. Hi @Djoss Thanks for the container. Im a novice so sorry for the question if its simple! How can i tell whether handbrake is using my GPU? I can see if emby is transcoding by using watch nvidia-smi or from the emby settings page. The Unraid dashboard shows the cpu cores pinned to Handbrake maxing out whenever it is in use, and this makes me wonder if it is using the P2000 card? Thanks for your help. Hardware - Unraid Nvidia 6.7.2 2 x Xeon E5 2690 32GB Ram Dell T620 server
  4. I'm a newbie too but here are a few things I had to check when I set this up a couple of months ago.! Have you set up your google domain records to point back to your static IP address? I used cloudflare as per the excellent spaceinvader tutorial and all works fine with dns validation. Check that you have set the top level domain name in the letsencrypt container settings. i.e. if your domain is 'example.domain' and you are creating a certificate for the subdomain 'my.example.domain' then the docker container setting for domain name would be 'example.domain' Also make sure your router/firewall is forwarding traffic, so from your router/firewall port 443 should be forwarded to your local unraid server ip address port 1443 or whatever port number you specified in the docker container settings under 'https' Hope that helps
  5. I myself used one of these for our office and had no issues reflashing the bios https://www.ebay.co.uk/itm/New-LSI-Internal-SAS-SATA-9211-8i-6Gbps-8-Ports-HBA-PCI-E-RAID-Controller-Card/131829448255?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649 it now sits in a dell t30 server tower running unraid which has been solid since going online some three or so months ago. Having run it as a mirror to an existing freenas setup for the last 6 weeks we are now comfortable and due to decomission & repurpose the freenas hardware.
  6. Confirmed this bug is still present despite latest updates to CA plugin. Suggested fix in update to 6.8 as here
  7. Thanks for the response. Its all a little odd really, probably a server/hardware issue initially which somehow corrupted the letsencrypt instance. Either that or somebody was trying to hack me! All is working as expected again now so thanks for the excellent docker container, along with several other of yours I use
  8. Ok, did some more digging, deleted the "dhparams.pem" file in the /letsencrypt/nginx folder and letsencrypt has now restarted successfully and regenerated a new dhparams.pem file I would like to try and understand what had happened though? any insight or pointers would be most appreciated. Thanks
  9. Hi All, Ive been a convert to Unraid for around 8 months and so far its all been good. One of my first adventures has been into the excelent docker containers from LinuxServerIO (Thanks) I had a fully working Letsencrypt until some point this weekend when something strange happened. The server suddenly reported the cache drive as "read only". A reboot seemed to sort this and i thought all had gone back to normal. However this morning I have encountered errors with the Letsencrypt docker. Trying to fix this I deleted the container and the image, also deleting the appdata folder then a complete re-install. I now have the following error - nginx: [emerg] PEM_read_bio_DHparams("/config/nginx/dhparams.pem") failed (SSL: error:0909006C:PEM routines:get_name:no start line:Expecting: DH PARAMETERS) Putting this into google I found a thread which suggested running this command openssl dhparam -out /etc/nginx/ssl/dhparam.pem 2048 however running this gets the following error Can't open /etc/nginx/ssl/dhparam.pem for writing, No such file or directory 22358693844800:error:02001002:system library:fopen:No such file or directory:crypto/bio/bss_file.c:72:fopen('/etc/nginx/ssl/dhparam.pem','w') 22358693844800:error:2006D080:BIO routines:BIO_new_file:no such file:crypto/bio/bss_file.c:79: Now I am out of my depth and would appreciate some assistance please Thanks
  10. Further investigation and information. Having cleared and rm'ed some exited docker stuff including letsencrypt. rebooted my machine and my router all is working again. Its just a bit odd and I am not experienced enough to track it down !! All is working ok again now though. So next I will set up letsencrypt again.
  11. Ok, I managed to use 'docker container stop' (letsencrypt) & 'docker conatainer rm' (letsencrypt) commands to remove letsencrypt. using powerdown -r brings the server back on line but the network then port shuts down almost immediatly after a reboot. Thanks
  12. Hi All, I have been getting to grips with unraid over the last 6 weeks ready to move my small office NAS (freenas) to unraid. So far I have been impressed with the features and all is going well. I have installed the linuxserver letsencrypt docker with a domain i hold and had it working nicely. Whilst experimenting with emby over reverse proxy I was having buffering and source too slow issues, searched various forums and decided it may be nginx settings. Long story short I messed it all up! Now as soon as the letsencrypt docker is stopped my network connection drops out. In my haste I set letsencrypt not to autostart however I now have no network on startup! Unraid is given an IP and I have access via local monitor and keyboard, can somebody help me delete the docker network "proxynet" and change the preserve user networks setting back to no. Hopefully this will get the lan connection working again, then I can delete the letsencrypt docker and start again with it. This is taken from the syslog using 'diagnose' yesterday when I stopped the letsencrypt docker and the lan connection first dissapeared. Jul 22 07:04:17 Tower emhttpd: /usr/local/emhttp/plugins/user.scripts/startBackground.php "/tmp/user.scripts/tmpScripts/icon_banner downloader/script" > /dev/null 2>&1/usr/local/emhttp/plugins/user.scripts/startBackground.php "/tmp/user.scripts/tmpScripts/icon sync/script" > /dev/null 2>&1 Jul 22 07:04:17 Tower emhttpd: Starting services... Jul 22 07:04:17 Tower emhttpd: shcmd (73): /etc/rc.d/rc.samba restart Jul 22 07:04:19 Tower root: Starting Samba: /usr/sbin/nmbd -D Jul 22 07:04:19 Tower root: /usr/sbin/smbd -D Jul 22 07:04:20 Tower root: /usr/sbin/winbindd -D Jul 22 07:04:20 Tower emhttpd: shcmd (87): /usr/local/sbin/mount_image '/mnt/user/system/docker/docker.img' /var/lib/docker 60 Jul 22 07:04:20 Tower kernel: BTRFS: device fsid 1ed80cc5-a7e8-4824-b7ab-8e2ff56306d9 devid 1 transid 51698 /dev/loop2 Jul 22 07:04:20 Tower kernel: BTRFS info (device loop2): disk space caching is enabled Jul 22 07:04:20 Tower kernel: BTRFS info (device loop2): has skinny extents Jul 22 07:04:20 Tower root: Resize '/var/lib/docker' of 'max' Jul 22 07:04:20 Tower kernel: BTRFS info (device loop2): new size for /dev/loop2 is 64424509440 Jul 22 07:04:20 Tower emhttpd: shcmd (89): /etc/rc.d/rc.docker start Jul 22 07:04:20 Tower root: starting dockerd ... Jul 22 07:04:25 Tower avahi-daemon[9252]: Joining mDNS multicast group on interface br-95ebd7ff9352.IPv4 with address 172.18.0.1. Jul 22 07:04:25 Tower avahi-daemon[9252]: New relevant interface br-95ebd7ff9352.IPv4 for mDNS. Jul 22 07:04:25 Tower avahi-daemon[9252]: Registering new address record for 172.18.0.1 on br-95ebd7ff9352.IPv4. Jul 22 07:04:25 Tower kernel: IPv6: ADDRCONF(NETDEV_UP): br-95ebd7ff9352: link is not ready Jul 22 07:04:25 Tower avahi-daemon[9252]: Joining mDNS multicast group on interface docker0.IPv4 with address 172.17.0.1. Jul 22 07:04:25 Tower avahi-daemon[9252]: New relevant interface docker0.IPv4 for mDNS. Jul 22 07:04:25 Tower avahi-daemon[9252]: Registering new address record for 172.17.0.1 on docker0.IPv4. Jul 22 07:04:25 Tower kernel: IPv6: ADDRCONF(NETDEV_UP): docker0: link is not ready Jul 22 07:04:28 Tower emhttpd: shcmd (103): /usr/local/sbin/mount_image '/mnt/user/system/libvirt/libvirt.img' /etc/libvirt 1 Jul 22 07:04:28 Tower kernel: BTRFS: device fsid 1e633490-d181-400a-abbc-041d0b3affc8 devid 1 transid 172 /dev/loop3 Jul 22 07:04:28 Tower kernel: BTRFS info (device loop3): disk space caching is enabled Jul 22 07:04:28 Tower kernel: BTRFS info (device loop3): has skinny extents Jul 22 07:04:28 Tower root: Resize '/etc/libvirt' of 'max' Jul 22 07:04:28 Tower kernel: BTRFS info (device loop3): new size for /dev/loop3 is 1073741824 Jul 22 07:04:28 Tower emhttpd: shcmd (105): /etc/rc.d/rc.libvirt start Jul 22 07:04:28 Tower root: Starting virtlockd... Jul 22 07:04:28 Tower root: Starting virtlogd... Jul 22 07:04:28 Tower root: Starting libvirtd... Jul 22 07:04:28 Tower kernel: br-95ebd7ff9352: port 1(vethc991769) entered blocking state Jul 22 07:04:28 Tower kernel: br-95ebd7ff9352: port 1(vethc991769) entered disabled state Jul 22 07:04:28 Tower kernel: device vethc991769 entered promiscuous mode Jul 22 07:04:28 Tower kernel: IPv6: ADDRCONF(NETDEV_UP): vethc991769: link is not ready Jul 22 07:04:28 Tower kernel: br-95ebd7ff9352: port 1(vethc991769) entered blocking state Jul 22 07:04:28 Tower kernel: br-95ebd7ff9352: port 1(vethc991769) entered forwarding state Jul 22 07:04:28 Tower kernel: br-95ebd7ff9352: port 1(vethc991769) entered disabled state Jul 22 07:04:28 Tower kernel: tun: Universal TUN/TAP device driver, 1.6 Jul 22 07:04:28 Tower emhttpd: nothing to sync Jul 22 07:04:28 Tower unassigned.devices: Mounting 'Auto Mount' Remote Shares... Jul 22 07:04:29 Tower kernel: eth0: renamed from vethf9ec863 Jul 22 07:04:29 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethc991769: link becomes ready Jul 22 07:04:29 Tower kernel: br-95ebd7ff9352: port 1(vethc991769) entered blocking state Jul 22 07:04:29 Tower kernel: br-95ebd7ff9352: port 1(vethc991769) entered forwarding state Jul 22 07:04:29 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): br-95ebd7ff9352: link becomes ready Jul 22 07:04:29 Tower kernel: L1TF CPU bug present and SMT on, data leak possible. See CVE-2018-3646 and https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html for details. Jul 22 07:04:29 Tower rc.docker: binhex-nzbget: started succesfully! Jul 22 07:04:30 Tower kernel: br-95ebd7ff9352: port 2(veth6514043) entered blocking state Jul 22 07:04:30 Tower kernel: br-95ebd7ff9352: port 2(veth6514043) entered disabled state Jul 22 07:04:30 Tower kernel: device veth6514043 entered promiscuous mode Jul 22 07:04:30 Tower kernel: IPv6: ADDRCONF(NETDEV_UP): veth6514043: link is not ready Jul 22 07:04:30 Tower kernel: br-95ebd7ff9352: port 2(veth6514043) entered blocking state Jul 22 07:04:30 Tower kernel: br-95ebd7ff9352: port 2(veth6514043) entered forwarding state Jul 22 07:04:30 Tower kernel: br-95ebd7ff9352: port 2(veth6514043) entered disabled state Jul 22 07:04:30 Tower kernel: virbr0: port 1(virbr0-nic) entered blocking state Jul 22 07:04:30 Tower kernel: virbr0: port 1(virbr0-nic) entered disabled state Jul 22 07:04:30 Tower kernel: device virbr0-nic entered promiscuous mode Jul 22 07:04:30 Tower dhcpcd[2202]: virbr0: new hardware address: a6:c4:35:8a:9c:bc Jul 22 07:04:30 Tower dhcpcd[2202]: virbr0: new hardware address: 52:54:00:14:4a:8a Jul 22 07:04:30 Tower kernel: virbr0: port 1(virbr0-nic) entered blocking state Jul 22 07:04:30 Tower kernel: virbr0: port 1(virbr0-nic) entered listening state Jul 22 07:04:30 Tower avahi-daemon[9252]: Joining mDNS multicast group on interface virbr0.IPv4 with address 192.168.122.1. Jul 22 07:04:30 Tower avahi-daemon[9252]: New relevant interface virbr0.IPv4 for mDNS. Jul 22 07:04:30 Tower avahi-daemon[9252]: Registering new address record for 192.168.122.1 on virbr0.IPv4. Jul 22 07:04:30 Tower dnsmasq[13965]: started, version 2.80 cachesize 150 Jul 22 07:04:30 Tower dnsmasq[13965]: compile time options: IPv6 GNU-getopt no-DBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth no-DNSSEC loop-detect inotify dumpfile Jul 22 07:04:30 Tower dnsmasq-dhcp[13965]: DHCP, IP range 192.168.122.2 -- 192.168.122.254, lease time 1h Jul 22 07:04:30 Tower dnsmasq-dhcp[13965]: DHCP, sockets bound exclusively to interface virbr0 Jul 22 07:04:30 Tower dnsmasq[13965]: reading /etc/resolv.conf Jul 22 07:04:30 Tower dnsmasq[13965]: using nameserver 192.168.1.254#53 Jul 22 07:04:30 Tower dnsmasq[13965]: read /etc/hosts - 2 addresses Jul 22 07:04:30 Tower dnsmasq[13965]: read /var/lib/libvirt/dnsmasq/default.addnhosts - 0 addresses Jul 22 07:04:30 Tower dnsmasq-dhcp[13965]: read /var/lib/libvirt/dnsmasq/default.hostsfile Jul 22 07:04:30 Tower kernel: virbr0: port 1(virbr0-nic) entered disabled state Jul 22 07:04:30 Tower avahi-daemon[9252]: Joining mDNS multicast group on interface vethc991769.IPv6 with address fe80::e845:afff:fe07:e752. Jul 22 07:04:30 Tower avahi-daemon[9252]: New relevant interface vethc991769.IPv6 for mDNS. Jul 22 07:04:30 Tower avahi-daemon[9252]: Registering new address record for fe80::e845:afff:fe07:e752 on vethc991769.*. Jul 22 07:04:31 Tower avahi-daemon[9252]: Joining mDNS multicast group on interface br-95ebd7ff9352.IPv6 with address fe80::42:b9ff:fedd:3946. Jul 22 07:04:31 Tower avahi-daemon[9252]: New relevant interface br-95ebd7ff9352.IPv6 for mDNS. Jul 22 07:04:31 Tower avahi-daemon[9252]: Registering new address record for fe80::42:b9ff:fedd:3946 on br-95ebd7ff9352.*. Jul 22 07:04:31 Tower kernel: eth0: renamed from vethc22957e Jul 22 07:04:31 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth6514043: link becomes ready Jul 22 07:04:31 Tower kernel: br-95ebd7ff9352: port 2(veth6514043) entered blocking state Jul 22 07:04:31 Tower kernel: br-95ebd7ff9352: port 2(veth6514043) entered forwarding state Jul 22 07:04:31 Tower rc.docker: binhex-radarr: started succesfully! Jul 22 07:04:32 Tower kernel: br-95ebd7ff9352: port 3(veth1ba5caa) entered blocking state Jul 22 07:04:32 Tower kernel: br-95ebd7ff9352: port 3(veth1ba5caa) entered disabled state Jul 22 07:04:32 Tower kernel: device veth1ba5caa entered promiscuous mode Jul 22 07:04:32 Tower kernel: IPv6: ADDRCONF(NETDEV_UP): veth1ba5caa: link is not ready Jul 22 07:04:32 Tower kernel: br-95ebd7ff9352: port 3(veth1ba5caa) entered blocking state Jul 22 07:04:32 Tower kernel: br-95ebd7ff9352: port 3(veth1ba5caa) entered forwarding state Jul 22 07:04:32 Tower kernel: br-95ebd7ff9352: port 3(veth1ba5caa) entered disabled state Jul 22 07:04:32 Tower avahi-daemon[9252]: Joining mDNS multicast group on interface veth6514043.IPv6 with address fe80::2cc4:60ff:fe5d:2319. Jul 22 07:04:32 Tower avahi-daemon[9252]: New relevant interface veth6514043.IPv6 for mDNS. Jul 22 07:04:32 Tower avahi-daemon[9252]: Registering new address record for fe80::2cc4:60ff:fe5d:2319 on veth6514043.*. Jul 22 07:04:33 Tower kernel: eth0: renamed from vethb374d01 Jul 22 07:04:33 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth1ba5caa: link becomes ready Jul 22 07:04:33 Tower kernel: br-95ebd7ff9352: port 3(veth1ba5caa) entered blocking state Jul 22 07:04:33 Tower kernel: br-95ebd7ff9352: port 3(veth1ba5caa) entered forwarding state Jul 22 07:04:33 Tower rc.docker: binhex-sonarr: started succesfully! Jul 22 07:04:33 Tower kernel: docker0: port 1(vethddeb7cc) entered blocking state Jul 22 07:04:33 Tower kernel: docker0: port 1(vethddeb7cc) entered disabled state Jul 22 07:04:33 Tower kernel: device vethddeb7cc entered promiscuous mode Jul 22 07:04:33 Tower kernel: IPv6: ADDRCONF(NETDEV_UP): vethddeb7cc: link is not ready Jul 22 07:04:33 Tower kernel: docker0: port 1(vethddeb7cc) entered blocking state Jul 22 07:04:33 Tower kernel: docker0: port 1(vethddeb7cc) entered forwarding state Jul 22 07:04:33 Tower kernel: docker0: port 1(vethddeb7cc) entered disabled state Jul 22 07:04:34 Tower avahi-daemon[9252]: Joining mDNS multicast group on interface veth1ba5caa.IPv6 with address fe80::4c33:fff:fe59:e45e. Jul 22 07:04:34 Tower avahi-daemon[9252]: New relevant interface veth1ba5caa.IPv6 for mDNS. Jul 22 07:04:34 Tower avahi-daemon[9252]: Registering new address record for fe80::4c33:fff:fe59:e45e on veth1ba5caa.*. Jul 22 07:04:34 Tower kernel: eth0: renamed from vetheed020f Jul 22 07:04:34 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethddeb7cc: link becomes ready Jul 22 07:04:34 Tower kernel: docker0: port 1(vethddeb7cc) entered blocking state Jul 22 07:04:34 Tower kernel: docker0: port 1(vethddeb7cc) entered forwarding state Jul 22 07:04:34 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): docker0: link becomes ready Jul 22 07:04:35 Tower rc.docker: duckdns: started succesfully! Jul 22 07:04:35 Tower kernel: br-95ebd7ff9352: port 4(veth06ba377) entered blocking state Jul 22 07:04:35 Tower kernel: br-95ebd7ff9352: port 4(veth06ba377) entered disabled state Jul 22 07:04:35 Tower kernel: device veth06ba377 entered promiscuous mode Jul 22 07:04:35 Tower kernel: IPv6: ADDRCONF(NETDEV_UP): veth06ba377: link is not ready Jul 22 07:04:35 Tower kernel: br-95ebd7ff9352: port 4(veth06ba377) entered blocking state Jul 22 07:04:35 Tower kernel: br-95ebd7ff9352: port 4(veth06ba377) entered forwarding state Jul 22 07:04:35 Tower kernel: br-95ebd7ff9352: port 4(veth06ba377) entered disabled state Jul 22 07:04:36 Tower avahi-daemon[9252]: Joining mDNS multicast group on interface vethddeb7cc.IPv6 with address fe80::8498:e8ff:fe68:16b9. Jul 22 07:04:36 Tower avahi-daemon[9252]: New relevant interface vethddeb7cc.IPv6 for mDNS. Jul 22 07:04:36 Tower avahi-daemon[9252]: Registering new address record for fe80::8498:e8ff:fe68:16b9 on vethddeb7cc.*. Jul 22 07:04:36 Tower avahi-daemon[9252]: Joining mDNS multicast group on interface docker0.IPv6 with address fe80::42:18ff:fe6e:8c0d. Jul 22 07:04:36 Tower avahi-daemon[9252]: New relevant interface docker0.IPv6 for mDNS. Jul 22 07:04:36 Tower avahi-daemon[9252]: Registering new address record for fe80::42:18ff:fe6e:8c0d on docker0.*. Jul 22 07:04:36 Tower kernel: eth0: renamed from vethd498063 Jul 22 07:04:36 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth06ba377: link becomes ready Jul 22 07:04:36 Tower kernel: br-95ebd7ff9352: port 4(veth06ba377) entered blocking state Jul 22 07:04:36 Tower kernel: br-95ebd7ff9352: port 4(veth06ba377) entered forwarding state Jul 22 07:04:36 Tower rc.docker: letsencrypt: started succesfully! Jul 22 07:04:38 Tower avahi-daemon[9252]: Joining mDNS multicast group on interface veth06ba377.IPv6 with address fe80::a02c:52ff:fec4:f861. Jul 22 07:04:38 Tower avahi-daemon[9252]: New relevant interface veth06ba377.IPv6 for mDNS. Jul 22 07:04:38 Tower avahi-daemon[9252]: Registering new address record for fe80::a02c:52ff:fec4:f861 on veth06ba377.*. Jul 22 07:09:11 Tower ntpd[2258]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized Jul 22 07:13:00 Tower root: Fix Common Problems Version 2019.06.30a Jul 22 07:13:04 Tower root: Fix Common Problems: Warning: Share appdata set to cache-only, but files / folders exist on the array Jul 22 07:13:04 Tower root: Fix Common Problems: Warning: Scheduled Parity Checks are not enabled Jul 22 07:15:55 Tower kernel: igb 0000:06:00.0 eth0: igb: eth0 NIC Link is Down Jul 22 07:15:55 Tower kernel: br0: port 1(eth0) entered disabled state Jul 22 07:15:56 Tower dhcpcd[2202]: br0: carrier lost Jul 22 07:15:56 Tower avahi-daemon[9252]: Withdrawing address record for 192.168.1.150 on br0. Jul 22 07:15:56 Tower avahi-daemon[9252]: Leaving mDNS multicast group on interface br0.IPv4 with address 192.168.1.150. Jul 22 07:15:56 Tower avahi-daemon[9252]: Interface br0.IPv4 no longer relevant for mDNS. Jul 22 07:15:56 Tower dhcpcd[2202]: br0: deleting route to 192.168.1.0/24 Jul 22 07:15:56 Tower dhcpcd[2202]: br0: deleting default route via 192.168.1.254 Jul 22 07:15:56 Tower dnsmasq[13965]: no servers found in /etc/resolv.conf, will retry Jul 22 07:15:57 Tower ntpd[2258]: Deleting interface #3 br0, 2a00:23c3:2101:5800:92b1:1cff:fe4e:58a#123, interface stats: received=73, sent=75, dropped=0, active_time=760 secs Jul 22 07:15:57 Tower ntpd[2258]: 2001:4860:4806:c:: local addr 2a00:23c3:2101:5800:92b1:1cff:fe4e:58a -> <null> Jul 22 07:15:57 Tower ntpd[2258]: 2001:4860:4806:8:: local addr 2a00:23c3:2101:5800:92b1:1cff:fe4e:58a -> <null> Jul 22 07:15:57 Tower ntpd[2258]: 2001:4860:4806:4:: local addr 2a00:23c3:2101:5800:92b1:1cff:fe4e:58a -> <null> Jul 22 07:15:57 Tower ntpd[2258]: 2001:4860:4806:: local addr 2a00:23c3:2101:5800:92b1:1cff:fe4e:58a -> <null> Jul 22 07:15:57 Tower ntpd[2258]: Deleting interface #4 br0, fdaa:bbcc:ddee:0:92b1:1cff:fe4e:58a#123, interface stats: received=0, sent=0, dropped=0, active_time=760 secs Jul 22 07:15:57 Tower ntpd[2258]: Deleting interface #5 br0, fe80::4445:ebff:feca:e838%12#123, interface stats: received=0, sent=0, dropped=0, active_time=760 secs Jul 22 07:15:57 Tower ntpd[2258]: Deleting interface #6 br0, 192.168.1.150#123, interface stats: received=0, sent=0, dropped=0, active_time=750 secs Thanks
  13. Hi, No the PERC H710 is Raid only so I have swapped it for a LSI 9211 8i. Glad to report my problem was a school boy error..... I had not inserted the drives into the caddies correctly !! ................. Feeling rather stupid now ! Thank you for trying to help.
  14. *** UPDATE *** Always check the obvious, I'm embarrassed to confirm I had not mounted the drives in the caddies properly so they were not making connection to the back plane. Must of had my eyes shut................. *** *** Hi All, First up, apologies if this is covered somewhere in the 65 pages of this thread! I have aquired a dell T620 server. It had a PERC H710 raid card which I have removed and replaced with an LSI 9211 8i card flashed reportedly successfully to FW 20.00.07.00 and bios 07.39.02.00 According to syslog Unraid can see the controller and all appears ok, it reports as in IT mode. Into the controller I have two SAS leads plugged into a Dell M05TM 8 x LFF Backplane. Into the drive bays I have two different WD Red Hard drives one 3TB and one 6TB drives but neither drive is showing up within Unraid Unassigned devices nor in the bios anywhere. I have tried all 8 slots with both drives but they just dont show up. Has anybody had experience of backplanes failing? or can anybody give me some further pointers as I am trying not to spend much cash on getting my unraid box moved into new hardware. Thanks