Helmonder

Members
  • Posts

    2815
  • Joined

  • Last visited

Everything posted by Helmonder

  1. @limetech Did this, same result (see below for my journey here but syslog with this "safe mode" herewith also attached..) Kind of baffled.. I recopied the 6.8.3 files to the stick and rebooted: all working again.. There is something in my existing flash drive config that breaks this... and Safe Mode does not solve it... Let me know what you want me to test, not a problem whatsoever ! syslog_notok
  2. Ok now I am totally puzzled.. I just reimaged my flashdrive with the imaging tool, I put 6.9 on it and just booted with that.. Made no changes to it.. So then there is no boot error (I even tried a couple of times, eveyr time the system boots) I also get the blue screen asking for how to boot (GUI / No Gui / etc), I then started with the regular unraid, that boots, I even get network (so that card now seems to be working), but when logging on to the system I can enter with "root" only (no password is asked) and my file system is not looking the way it should... I was able to grab the syslog (syslog_sat.bad), maybe somebody can give me a pointer here ? No idea where to start now.. syslog_sat.bad Just to be sure I also copied my copy op the upgraded usb stick (so in 6.9) over it and rebooted. That rebooted but the network is gone again (so back where we started). Next reboot I did was in SAFE mode (so new stick with 6.9, contents of 6.9 copied over, but booted in safe mode). This results in the same situation, no network. syslog is attached as syslog_notok. syslog_notok
  3. Ok this is weird... booting seems to not start at all with a "boot error" message... When I recreate my usb stick and copy 6.8.3 over it, then it works again... Tried several times... I will now recreate my usb stick (with the image tool) and copy over the 6.9 files... curious if that works.. This does appear to be something totally different then the networking that this started out with..
  4. This is the diagnostics with the reboot after removing /extra, so still on 6.8.3. Now rebooting with 6.9.. I'll get back in an hour with the results !
  5. @Squid Thanks for pointing that out.... I wasn't even aware I still had that.. I will remove those first as I do not need them anymore and reboot within 6.8.3. Just to be sure. Hope that helps the issue since then its my fault ! @limetech I remade my USB by creating it anew with the usb drive creator and then copying over the contents of my existing.. (with that boot/extra stuff removed). Maybe I need to make a fresh usb in all and only copy the config files that are needed for the basic array.. Have been using unraid for a great while so maybe there is more old sh*t in there.. After that I will try again and post syslog
  6. Just tried to do it again while having a bond active on my br0 that also had the native ports of my motherboards in it... that resulted in a "boot error" I think I'l wait for the next version
  7. The upgrade from 6.8.3 60 6.9 failed in my case. The update itself succeeded, reboot worked but the system did not become active on the network. No GUI, no share, no telnet. - I was able to IPMI into the system and get on console; - The system could ping its own IP address from console but not the default gateway. GUI mode also did not work from console; "page not found"; - Network setup appeared good, correct default gateway and such (ROUTE -N) - The port was shown as "linkdown" (IP ROUTE SHOW); - I have attached a diagnostics file (note: this is for the current situation, so with 6.8.3). - I also attach a syslog that I was able to capture on the flashdrive for the 6.9 config. Hopefully that will give someone some insight. - I reverted to 6.8.3 by restoring the flashdrive from the backup, that seems to have worked 100%. I am suspecting the issue lies with my ethernet controller: IOMMU group 12:[15b3:6750] 03:00.0 Ethernet controller: Mellanox Technologies MT26448 [ConnectX EN 10GigE, PCIe 2.0 5GT/s] (rev b0) Also: Tower kernel: emhttpd[17268]: segfault at 0 ip 00001489487cff36 sp 0000148943dfde80 error 4 in libc-2.30.so[1489487ab000+16b000] A segfault in emhttpd would also cause the GUI to be not reachable but I figure that would make the GUI unreachable but not telnet/shares.. So probably emhttpd crashed because of the closed eth0 ? tower-diagnostics-20210304-1414.zip syslog.bad
  8. This is where the mistake is... the default route is set as 192.168.10.6 via eth2. That is my internal and not externally connected network. The default route should be 192.168.1.250 (my router) via eth0 (my uplink) I added the correct route, but now I have two.. pressing the wastebin icon on the wrong one does not work.. I removed the extra route via console: route del default gw 192.168.10.6 eth2 Its gone in settings now... But this is the way it was earlier... I -think- this will reset itself after a reboot again.. Which is also logical since this was done in the non persistent memory.. Where does unraid store its route information in boot/config ?
  9. Nope... looks like when doing a softreboot it works, but after a hard reboot it does not..
  10. That is what I have... still it borks when I reboot...
  11. Did that... GUI did not load though... I ended up being able to get it loaded by changing the routes on console though... So I am up and running but my setup is still somehow flawed, this will happen again on a reboot and I want to avoid that..
  12. Hi ! After a reboot my server was not reachable over the network anymore. Server is reachable over IPMI and I can use the local console The server itself is running fine I can just not reach it. The issue arose when I activated a 10GB Mellanox card for my two urnaids to talk to each other. After the reboot I guess the server thinks that the 10GB mellanox connection should be primary because it is faster. I did set a higher metric on it though. I have copied back old network.cfg and network-rules.cfg files from a backup, that seems to have worked. Do not really get it though, They have not been changed since the backup (cards were allready in).. I have added diagnostics.. Can someone help me in checking what is wrong with my networking config ? My setup is as follows: ETH0/BR0 is a bridged interface consisting of eth0 (which is a 10GB Mellanox to my network). At some pointed I wanted a cabled 1GB in eth1 as backup in this bridge, that interface is disabled, do not really remember what I did there. This interface is 192.168.1.5 ETH1 is a regular 1GB network port directly on my mainboard of the server, it is inactive. ETH2 is a 10GB Mellanox direct connection to my other server, it is 192.168.10.5 and only talks to 192.168.10.6. This connection is only used for the two servers to talk to each other and this works fine. ETH3 is the second interface of the Mellanox card, empty and not used. tower-diagnostics-20210116-1125.zip
  13. The CPU is actually not something that is on the map... At least for now.. The reason I am going for the other motherboard is because it is bigger and adds some more ports, this will give me some free room to add a graphics card.. I have a GV-N710D5SL-2GL lying around that can be added in.. I basically have not need for any upgrade as my server has never given me troubles, I want to play around with the MacOS VM and that really needs a GPU..
  14. Well... That was stupid... Appears everything is running just fine but the scanning that syncthing does took longer then I anticipated... Its humming along quite nicely and I see network speeds topping 400 Mb/s at the moment :-)
  15. Hi.. I have some issues getting Syncthing to work with my secundary network... I would appreciate if if someone could look if I am doing something wrong: EDIT: Guess I was just TO anxious... It took a while for the system to complete scanning... Its running 300 Mb/s between the boxes now :-)
  16. Hi, I currently have two unraid servers, one primary, one backup. Both servers have Mellanox 10GB cards in them. The main server uses this connection to connect to my network-switch and this works fine (my desktop is also connected at 10GB and that gives me cool speeds between desktop and server. I have added a similar card to my backupserver but my network switch only has two SFP+ ports so I am trying to do the following: Directly connect backup and primary unraid server with an SFP DAC between two systems. The backup system is only used to receive SYNCTHING backups so if speeds between these servers are optimized this is fine and I do not need to upgrade my switch. The backup is btw also connected with a regular 1GB RJ45 connection and the servers works fine (also syncthing over this connection works fine). My regular (perfectly working) addresses are: Primary: 192.168.1.5 Backup: 192.168.1.6 Both servers have secundary addresses on the Mellanox: Primary: 192.168.10.5 (default gateway 192.168.10.6) Backup: 192.168.10.6 (default gateway 192.168.10.5) I have setup syncthing as dockers, the dockers are bridged so share the IP address of the server out of my regular pool: Within the Syncthing dockers I have setup connections towards the Mellanox addresses: Primary is connecting to 192.168.10.6 Backup is connecting to 192.168.10.5 Now for my issue: The syncthing containers appear to be connecting fine but the transfers speeds are zero to a few kb... So something is wrong.. I see no obvious errors in the logs: Primary Logfile filtered on eth2 (which is the port for 192.168.10.5) Dec 28 08:49:07 Tower kernel: 8021q: adding VLAN 0 to HW filter on device eth2 Dec 28 08:49:09 Tower kernel: mlx4_en: eth2: Link Up Dec 28 08:54:08 Tower ool www[14025]: /usr/local/emhttp/plugins/dynamix/scripts/netconfig 'eth2' Dec 28 08:54:08 Tower rc.inet1: ip -4 addr flush dev eth2 Dec 28 08:54:08 Tower rc.inet1: ip link set eth2 down Dec 28 08:54:08 Tower kernel: mlx4_en: eth2: Close port called Dec 28 08:54:08 Tower kernel: mlx4_en: eth2: Link Down Dec 28 08:54:09 Tower rc.inet1: ip -4 addr add 192.168.10.5/255.255.255.0 dev eth2 Dec 28 08:54:09 Tower rc.inet1: ip link set eth2 up Dec 28 08:54:09 Tower kernel: mlx4_en: eth2: Steering Mode 1 Dec 28 08:54:09 Tower kernel: 8021q: adding VLAN 0 to HW filter on device eth2 Dec 28 08:54:09 Tower rc.inet1: ip -4 route add default via 192.168.1.250 dev eth2 Dec 28 08:54:09 Tower rc.inet1: ip -4 route add default via 192.168.1.250 dev eth2 Dec 28 08:54:12 Tower kernel: mlx4_en: eth2: Link Up Dec 28 08:54:12 Tower kernel: mlx4_en: eth2: Link Down Dec 28 08:54:12 Tower kernel: mlx4_en: eth2: Link Up Dec 28 08:54:58 Tower kernel: mlx4_en: eth2: Close port called Dec 28 08:54:58 Tower kernel: mlx4_en: eth2: Link Down Dec 28 08:55:00 Tower kernel: mlx4_en: eth2: Steering Mode 1 Dec 28 08:55:00 Tower kernel: 8021q: adding VLAN 0 to HW filter on device eth2 Dec 28 08:55:02 Tower kernel: mlx4_en: eth2: Link Up Dec 28 08:55:24 Tower kernel: docker0: port 2(veth274c512) entered blocking state Dec 28 08:55:24 Tower kernel: docker0: port 2(veth274c512) entered disabled state Dec 28 08:55:24 Tower kernel: device veth274c512 entered promiscuous mode Dec 28 08:55:24 Tower kernel: IPv6: ADDRCONF(NETDEV_UP): veth274c512: link is not ready Dec 28 08:55:24 Tower kernel: docker0: port 2(veth274c512) entered blocking state Dec 28 08:55:24 Tower kernel: docker0: port 2(veth274c512) entered forwarding state Dec 28 08:55:24 Tower kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth274c512: link becomes ready Dec 28 08:56:53 Tower kernel: mlx4_en: eth2: Link Down Dec 28 08:56:53 Tower kernel: mlx4_en: eth2: Link Up Dec 28 08:58:54 Tower kernel: mlx4_en: eth2: Link Down Dec 28 08:58:56 Tower kernel: mlx4_en: eth2: Link Up Dec 28 09:58:00 Tower kernel: docker0: port 2(veth274c512) entered disabled state Dec 28 09:58:00 Tower kernel: docker0: port 2(veth274c512) entered disabled state Dec 28 09:58:00 Tower kernel: device veth274c512 left promiscuous mode Dec 28 09:58:00 Tower kernel: docker0: port 2(veth274c512) entered disabled state Dec 28 09:59:23 Tower ool www[21642]: /usr/local/emhttp/plugins/dynamix/scripts/netconfig 'eth2' Dec 28 09:59:23 Tower rc.inet1: ip -4 addr flush dev eth2 Dec 28 09:59:23 Tower rc.inet1: ip link set eth2 down Dec 28 09:59:23 Tower kernel: mlx4_en: eth2: Close port called Dec 28 09:59:23 Tower kernel: mlx4_en: eth2: Link Down Dec 28 09:59:23 Tower rc.inet1: ip -4 addr add 192.168.10.5/255.255.255.0 dev eth2 Dec 28 09:59:23 Tower rc.inet1: ip link set eth2 up Dec 28 09:59:23 Tower kernel: mlx4_en: eth2: Steering Mode 1 Dec 28 09:59:23 Tower kernel: 8021q: adding VLAN 0 to HW filter on device eth2 Dec 28 09:59:23 Tower rc.inet1: ip -4 route add default via 192.168.10.6 dev eth2 Dec 28 09:59:26 Tower kernel: mlx4_en: eth2: Link Up Dec 28 10:00:50 Tower kernel: mlx4_en: eth2: Link Down Dec 28 10:00:52 Tower kernel: mlx4_en: eth2: Link Up Secundary logfile filtered on eth3 (which is the port for 192.168.10.6: Dec 28 08:49:09 Vault kernel: mlx4_en: eth3: Link Up Dec 28 08:54:08 Vault kernel: mlx4_en: eth3: Link Down Dec 28 08:54:12 Vault kernel: mlx4_en: eth3: Link Up Dec 28 08:54:58 Vault kernel: mlx4_en: eth3: Link Down Dec 28 08:55:02 Vault kernel: mlx4_en: eth3: Link Up Dec 28 08:56:45 Vault kernel: mlx4_en: eth3: Steering Mode 1 Dec 28 08:56:45 Vault kernel: 8021q: adding VLAN 0 to HW filter on device eth3 Dec 28 08:56:46 Vault avahi-daemon[7894]: Joining mDNS multicast group on interface eth3.IPv6 with address fe80::202:c9ff:fe52:e976. Dec 28 08:56:46 Vault avahi-daemon[7894]: New relevant interface eth3.IPv6 for mDNS. Dec 28 08:56:46 Vault avahi-daemon[7894]: Registering new address record for fe80::202:c9ff:fe52:e976 on eth3.*. Dec 28 08:56:53 Vault kernel: mlx4_en: eth3: Link Down Dec 28 08:56:53 Vault kernel: mlx4_en: eth3: Link Up Dec 28 08:58:54 Vault ool www[5867]: /usr/local/emhttp/plugins/dynamix/scripts/netconfig 'eth3' Dec 28 08:58:54 Vault rc.inet1: ip -4 addr flush dev eth3 Dec 28 08:58:54 Vault rc.inet1: ip link set eth3 down Dec 28 08:58:54 Vault kernel: mlx4_en: eth3: Close port called Dec 28 08:58:54 Vault avahi-daemon[7894]: Interface eth3.IPv6 no longer relevant for mDNS. Dec 28 08:58:54 Vault avahi-daemon[7894]: Leaving mDNS multicast group on interface eth3.IPv6 with address fe80::202:c9ff:fe52:e976. Dec 28 08:58:54 Vault kernel: mlx4_en: eth3: Link Down Dec 28 08:58:54 Vault avahi-daemon[7894]: Withdrawing address record for fe80::202:c9ff:fe52:e976 on eth3. Dec 28 08:58:54 Vault rc.inet1: ip -4 addr add 192.168.10.6/255.255.255.0 dev eth3 Dec 28 08:58:54 Vault rc.inet1: ip link set eth3 up Dec 28 08:58:54 Vault kernel: mlx4_en: eth3: Steering Mode 1 Dec 28 08:58:54 Vault avahi-daemon[7894]: Joining mDNS multicast group on interface eth3.IPv4 with address 192.168.10.6. Dec 28 08:58:54 Vault kernel: 8021q: adding VLAN 0 to HW filter on device eth3 Dec 28 08:58:54 Vault avahi-daemon[7894]: New relevant interface eth3.IPv4 for mDNS. Dec 28 08:58:54 Vault avahi-daemon[7894]: Registering new address record for 192.168.10.6 on eth3.IPv4. Dec 28 08:58:54 Vault rc.inet1: ip -4 route add default via 192.168.1.250 dev eth3 Dec 28 08:58:54 Vault rc.inet1: ip -4 route add default via 192.168.1.250 dev eth3 Dec 28 08:58:56 Vault kernel: mlx4_en: eth3: Link Up Dec 28 09:59:23 Vault kernel: mlx4_en: eth3: Link Down Dec 28 09:59:26 Vault kernel: mlx4_en: eth3: Link Up Dec 28 10:00:50 Vault ool www[21074]: /usr/local/emhttp/plugins/dynamix/scripts/netconfig 'eth3' Dec 28 10:00:50 Vault rc.inet1: ip -4 addr flush dev eth3 Dec 28 10:00:50 Vault avahi-daemon[7894]: Withdrawing address record for 192.168.10.6 on eth3. Dec 28 10:00:50 Vault avahi-daemon[7894]: Leaving mDNS multicast group on interface eth3.IPv4 with address 192.168.10.6. Dec 28 10:00:50 Vault avahi-daemon[7894]: Interface eth3.IPv4 no longer relevant for mDNS. Dec 28 10:00:50 Vault rc.inet1: ip link set eth3 down Dec 28 10:00:50 Vault kernel: mlx4_en: eth3: Close port called Dec 28 10:00:50 Vault kernel: mlx4_en: eth3: Link Down Dec 28 10:00:50 Vault rc.inet1: ip -4 addr add 192.168.10.6/255.255.255.0 dev eth3 Dec 28 10:00:50 Vault rc.inet1: ip link set eth3 up Dec 28 10:00:50 Vault kernel: mlx4_en: eth3: Steering Mode 1 Dec 28 10:00:50 Vault avahi-daemon[7894]: Joining mDNS multicast group on interface eth3.IPv4 with address 192.168.10.6. Dec 28 10:00:50 Vault kernel: 8021q: adding VLAN 0 to HW filter on device eth3 Dec 28 10:00:50 Vault avahi-daemon[7894]: New relevant interface eth3.IPv4 for mDNS. Dec 28 10:00:50 Vault avahi-daemon[7894]: Registering new address record for 192.168.10.6 on eth3.IPv4. Dec 28 10:00:50 Vault rc.inet1: ip -4 route add default via 192.168.10.5 dev eth3 Dec 28 10:00:52 Vault kernel: mlx4_en: eth3: Link Up Dec 28 10:00:52 Vault kernel: mlx4_en: eth3: Link Down Dec 28 10:00:53 Vault kernel: mlx4_en: eth3: Link Up I see nothing obvious going wrong here... The syncthing log on the primary server: [services.d] starting services [services.d] done. [start] 10:11:20 INFO: syncthing v1.12.0 "Fermium Flea" (go1.15.6 linux-amd64) root@deea883fede0 2020-12-16 22:43:19 UTC [noupgrade] [start] 10:11:20 INFO: Using large-database tuning [NYD47] 10:11:20 INFO: My ID: NYD476I-JIDSNKM-GBFSVHP-F6SBLHR-XVQZM7N-F6IQYAK-TCXMNSC-P2N3IAJ [NYD47] 10:11:20 INFO: Single thread SHA256 performance is 420 MB/s using minio/sha256-simd (361 MB/s using crypto/sha256). [NYD47] 10:11:21 INFO: Hashing performance is 361.92 MB/s [NYD47] 10:11:21 INFO: Overall send rate is unlimited, receive rate is unlimited [NYD47] 10:11:21 INFO: Using discovery mechanism: IPv4 local broadcast discovery on port 21027 [NYD47] 10:11:21 INFO: Using discovery mechanism: IPv6 local multicast discovery on address [ff12::8384]:21027 [NYD47] 10:11:21 INFO: QUIC listener ([::]:22000) starting [NYD47] 10:11:21 INFO: TCP listener ([::]:22000) starting [NYD47] 10:11:21 INFO: Ready to synchronize "Tower-data" (rtecd-abbex) (sendonly) [NYD47] 10:11:21 INFO: GUI and API listening on [::]:8384 [NYD47] 10:11:21 INFO: Access the GUI via the following URL: http://127.0.0.1:8384/ [NYD47] 10:11:21 INFO: My name is "Tower" [NYD47] 10:11:21 INFO: Device 7CCSKMK-DCMAXVG-2XBD7HK-22XF4MR-2WKU36O-DJ3QZ52-CW5JEZV-JJHMKAN is "Vault" at [tcp://192.168.10.6:22000] [NYD47] 10:11:21 INFO: Established secure connection to 7CCSKMK-DCMAXVG-2XBD7HK-22XF4MR-2WKU36O-DJ3QZ52-CW5JEZV-JJHMKAN at 172.17.0.4:50586-192.168.10.6:22000/tcp-client/TLS1.3-TLS_AES_128_GCM_SHA256 [NYD47] 10:11:21 INFO: Device 7CCSKMK-DCMAXVG-2XBD7HK-22XF4MR-2WKU36O-DJ3QZ52-CW5JEZV-JJHMKAN client is "syncthing v1.12.0" named "Vault" at 172.17.0.4:50586-192.168.10.6:22000/tcp-client/TLS1.3-TLS_AES_128_GCM_SHA256 [NYD47] 10:41:22 INFO: Sent usage report (version 3) The syncthing log on the backup server: [services.d] starting services [services.d] done. [start] 10:11:15 INFO: syncthing v1.12.0 "Fermium Flea" (go1.15.6 linux-amd64) root@deea883fede0 2020-12-16 22:43:19 UTC [noupgrade] [start] 10:11:15 INFO: Using large-database tuning [7CCSK] 10:11:15 INFO: My ID: 7CCSKMK-DCMAXVG-2XBD7HK-22XF4MR-2WKU36O-DJ3QZ52-CW5JEZV-JJHMKAN [7CCSK] 10:11:16 INFO: Single thread SHA256 performance is 305 MB/s using minio/sha256-simd (206 MB/s using crypto/sha256). [7CCSK] 10:11:17 INFO: Hashing performance is 261.37 MB/s [7CCSK] 10:11:17 INFO: Overall send rate is unlimited, receive rate is unlimited [7CCSK] 10:11:17 INFO: Using discovery mechanism: IPv4 local broadcast discovery on port 21027 [7CCSK] 10:11:17 INFO: Using discovery mechanism: IPv6 local multicast discovery on address [ff12::8384]:21027 [7CCSK] 10:11:17 INFO: TCP listener ([::]:22000) starting [7CCSK] 10:11:17 INFO: QUIC listener ([::]:22000) starting [7CCSK] 10:11:17 INFO: GUI and API listening on [::]:8384 [7CCSK] 10:11:17 INFO: Access the GUI via the following URL: http://127.0.0.1:8384/ [7CCSK] 10:11:17 INFO: My name is "Vault" [7CCSK] 10:11:17 INFO: Device NYD476I-JIDSNKM-GBFSVHP-F6SBLHR-XVQZM7N-F6IQYAK-TCXMNSC-P2N3IAJ is "Tower" at [tcp://192.168.10.5:22000] [7CCSK] 10:11:17 INFO: Ready to synchronize "Tower-data" (rtecd-abbex) (receiveonly) [7CCSK] 10:11:21 INFO: Established secure connection to NYD476I-JIDSNKM-GBFSVHP-F6SBLHR-XVQZM7N-F6IQYAK-TCXMNSC-P2N3IAJ at 172.17.0.2:22000-192.168.10.5:50586/tcp-server/TLS1.3-TLS_AES_128_GCM_SHA256 [7CCSK] 10:11:21 INFO: Device NYD476I-JIDSNKM-GBFSVHP-F6SBLHR-XVQZM7N-F6IQYAK-TCXMNSC-P2N3IAJ client is "syncthing v1.12.0" named "Tower" at 172.17.0.2:22000-192.168.10.5:50586/tcp-server/TLS1.3-TLS_AES_128_GCM_SHA256 [7CCSK] 10:41:18 INFO: Sent usage report (version 2) Would really appreciate some help... I will cross-post in the syncthing forum to.. Since I do not really know where the error lies..
  17. Hi ! At the moment I am using a SuperMicro X11SSM-F Motherboard with an Intelo Xeon E3-1230 V6. The board is performing find but I am missing PCI connectors... Really want to add a video card an I have maxed out the ways I can do this, therefor I am looking for an ATX board instead of a Micro-atx board (really never should have gone for this in the past.. Enough room in the case.. My CPU is still fine as is my memory (ECC) so I do not want to change those, I also like to stick with SuperMicro since the brand has served me well for many many years. Although, if I get gready.. I could change the CPU to a Core i9 9900K ... Which would be allmost 100% improvement in performance.. I see the following options, price wise they are also pretty similar. Anybody had any negative or positive experiences with any of these ? X11SCA, Intel C246, Intel I210AT/Intel I219LM Intel X11SAE, Intel C235, Intel I219LM/Intel I210AT X11SAE-F, Intel C236, Intel I219LM/Intel I210AT X11SCA-W, Intel C246, Intel, Intel I210AT/Intel I219LM X11SCA-F, Intel C246, Intel I210AT/Intel I219LM The -W variant has bluetooth and wireless onboard which I will not use and therefor I think better to not have... The less in there, the less that can create issues.. Main difference I then see is the chipset for Network they are all the same, only primary and secundary sometimes the other way around. For the system chipset the choice appears to be between C236 and C246.. I do not see any negative comments on the C246 with a quick search, there are some with the C236 That brings down the choices to: X11SCA, Intel C246, Intel I210AT/Intel I219LM or X11SCA-F, Intel C246, Intel I210AT/Intel I219LM Only difference I see is that the X11SCA-F has a VGA port which I like to have for some reason (old geezer I guess).. Therefor the X11SCA-F would be my choice. According to the excellent thread by I will be loosing my PCI x4 slot when using an m2 drive but that is no issue I think.. @Tybio Do you think this board will work for me or would you advise something else ?
  18. Thanks. I found one for a reasonable price and bought it... Have to find a way to double-connect my monitor now though.. Forgot abaout that :-) I gave the VM 4 of my 8 cores, cannot say its "quick' though.. but still fine fo find out how macos works..
  19. Any advice on what GPU to add to unraid to make it work a bit more smooth ? Not to expensive.. Will not use it for anything but this... I am running on a Supermicro X11SSM-F Version 1.01 with an Intel® Xeon® CPU E3-1230 v6 @ 3.50GHz
  20. Works perfectly ! WOW ! Now I can check this out before going for an M1 🙂
  21. Did anyone succeed in logging in to the appstore ? Or is there another way to get apps in there ? I miss my office..
  22. Wauw.... that works really well ! I am guessing that signing in with my apple ID is not a good idea ?
  23. I would also do a cache, but for what is was originally meant for: for cache..
  24. My log is flooded with an enormous amount of the below messages.. I am running a parity rebuild due to a drive change so I cannot reboot.. System seems to be performing without issues and rebuild is still continuing.. Nov 1 05:01:30 Tower nginx: 2020/11/01 05:01:30 [error] 9926#9926: nchan: Out of shared memory while allocating message of size 9602. Increase nchan_max_reserved_memory. Nov 1 05:01:30 Tower nginx: 2020/11/01 05:01:30 [error] 9926#9926: *1001740 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/disks?buffer_length=1 HTTP/1.1", host: "localhost" Nov 1 05:01:30 Tower nginx: 2020/11/01 05:01:30 [error] 9926#9926: MEMSTORE:00: can't create shared message for channel /disks I guess I will wait it out ? tower-diagnostics-20201101-0917.zip
  25. I run a daily backup with the plugin for docker backup.. actually works fine.. for the rest I use the cache for -cache- and that does not mean I care a lot if I loose something.. I think the cache pools are most valuable for situation where they are not really used for cache... But for "fast storage"..