-
My bad, blew away array config
Thanks. I kicked that off an hour ago and if definitely has some problems with my drive changes. Rebuild it is.
-
My bad, blew away array config
Thanks, that brought everything back up. Those instructions to lack one step though. Between 5 and 6 there should be a step saying to unassign the unmountable drives and assign then to the parity slots. I moved both, moved my data drives up in the slots, and checked the box to not redo parity as i knew it was current and did not need to be rebuilt. This also gives me a better understanding of how the New Config works. It keeps what you checks and clears what is marked as unassigned.
-
My bad, blew away array config
Thanks. I'll see if I can get this recovered.
-
My bad, blew away array config
I found this is the logs from an array restart earlier this morning. I'm guessing this is my array and how it is setup? Is disk0 Parity1 and disk 29 the Parity 2? The 2 12 TB drives were data disks 1-3 , and 4 other 14TB drives were data 4-7. 1 12TB was not assigned, it was the old parity drive. Oct 9 10:26:28 Tower kernel: mdcmd (1): import 0 sdc 64 13672382412 0 WDC_WD140EDGZ-11B1PA0_9MHGJE3T Oct 9 10:26:28 Tower kernel: md: import disk0: (sdc) WDC_WD140EDGZ-11B1PA0_9MHGJE3T size: 13672382412 Oct 9 10:26:28 Tower kernel: mdcmd (2): import 1 sdg 64 11718885324 0 WDC_WD120EMAZ-11BLFA0_8CK9VZRF Oct 9 10:26:28 Tower kernel: md: import disk1: (sdg) WDC_WD120EMAZ-11BLFA0_8CK9VZRF size: 11718885324 Oct 9 10:26:28 Tower kernel: mdcmd (3): import 2 sde 64 11718885324 0 WDC_WD120EMFZ-11A6JA0_Z2GWUJ5T Oct 9 10:26:28 Tower kernel: md: import disk2: (sde) WDC_WD120EMFZ-11A6JA0_Z2GWUJ5T size: 11718885324 Oct 9 10:26:28 Tower kernel: mdcmd (4): import 3 sdf 64 11718885324 0 WDC_WD120EMFZ-11A6JA0_9RGUGEAC Oct 9 10:26:28 Tower kernel: md: import disk3: (sdf) WDC_WD120EMFZ-11A6JA0_9RGUGEAC size: 11718885324 Oct 9 10:26:28 Tower kernel: mdcmd (5): import 4 sdh 64 13672382412 0 WDC_WUH721414ALE604_Z2HS9SET Oct 9 10:26:28 Tower kernel: md: import disk4: (sdh) WDC_WUH721414ALE604_Z2HS9SET size: 13672382412 Oct 9 10:26:28 Tower kernel: mdcmd (6): import 5 sdi 64 13672382412 0 WDC_WUH721414ALE604_Z2GLS0MT Oct 9 10:26:28 Tower kernel: md: import disk5: (sdi) WDC_WUH721414ALE604_Z2GLS0MT size: 13672382412 Oct 9 10:26:28 Tower kernel: mdcmd (7): import 6 sdj 64 13672382412 0 WDC_WUH721414ALE604_Z2J2UDBT Oct 9 10:26:28 Tower kernel: md: import disk6: (sdj) WDC_WUH721414ALE604_Z2J2UDBT size: 13672382412 Oct 9 10:26:28 Tower kernel: mdcmd (8): import 7 sdk 64 13672382412 0 WDC_WUH721414ALE604_9JHDTB9T Oct 9 10:26:28 Tower kernel: md: import disk7: (sdk) WDC_WUH721414ALE604_9JHDTB9T size: 13672382412 Oct 9 10:26:28 Tower kernel: mdcmd (9): import 8 Oct 9 10:26:28 Tower kernel: mdcmd (10): import 9 Oct 9 10:26:28 Tower kernel: mdcmd (11): import 10 Oct 9 10:26:28 Tower kernel: mdcmd (12): import 11 Oct 9 10:26:28 Tower kernel: mdcmd (13): import 12 Oct 9 10:26:28 Tower kernel: mdcmd (14): import 13 Oct 9 10:26:28 Tower kernel: mdcmd (15): import 14 Oct 9 10:26:28 Tower kernel: mdcmd (16): import 15 Oct 9 10:26:28 Tower kernel: mdcmd (17): import 16 Oct 9 10:26:28 Tower kernel: mdcmd (18): import 17 Oct 9 10:26:28 Tower kernel: mdcmd (19): import 18 Oct 9 10:26:28 Tower kernel: mdcmd (20): import 19 Oct 9 10:26:28 Tower kernel: mdcmd (21): import 20 Oct 9 10:26:28 Tower kernel: mdcmd (22): import 21 Oct 9 10:26:28 Tower kernel: mdcmd (23): import 22 Oct 9 10:26:28 Tower kernel: mdcmd (24): import 23 Oct 9 10:26:28 Tower kernel: mdcmd (25): import 24 Oct 9 10:26:28 Tower kernel: mdcmd (26): import 25 Oct 9 10:26:28 Tower kernel: mdcmd (27): import 26 Oct 9 10:26:28 Tower kernel: mdcmd (28): import 27 Oct 9 10:26:28 Tower kernel: mdcmd (29): import 28 Oct 9 10:26:28 Tower kernel: mdcmd (30): import 29 sdb 64 13672382412 0 WDC_WD140EDGZ-11B1PA0_9MHAHKBJ Oct 9 10:26:28 Tower kernel: md: import disk29: (sdb) WDC_WD140EDGZ-11B1PA0_9MHAHKBJ size: 13672382412
-
My bad, blew away array config
Here's the current diagnostics tower-diagnostics-20241009-1202.zip
-
My bad, blew away array config
I hit the wrong button with New Config and wiped out my array except the pools. It should have been no issue as I had a screenshot of the config, but then Windows blue screened when I used my KVM to get my second monitor. It rebooted my laptop and now my array settings are cleared minus the cache pool that I actually checked to retain. I have been in the process of shuffling drives. I wiped out a couple of really large backup shares and I removing the 12 TB drives and keeping the much newer 14 tb drives. 2x 14TB drives were Parity, most of the data was already on the 14TB drives, one of which I was planning to swap in for an empty 12tb drive. I'm confident the parity is correct, everything was just checked a couple days ago when I swapped the 12 and 14 TB parity drives. How do I identify which drives are parity and which are data so I can slot them correctly and fire up the array?
-
[SUPPORT] AlexRed's Template Repository
It's definitely using one of my shares rather than a folder inside the docker. I'll have to look into docker directories. I've seen them mentioned a few times but the docker image has been around for many years with this Unraid system and I have yet to change it.
-
[SUPPORT] AMP (Application Management Panel) - CorneliousJD Repo
I've been using auto-m4b bit and it works well enough, but I notice is it is one the biggest containers in docker.img. Any idea how this can be reduced? Name Container Writable Log auto-m4b 5.67 GB 4.51 GB 20.9 MB AMP 5.42 GB 759 MB 120 kB calibre 2.26 GB 327 kB 4.31 kB calibre-web 1.50 GB 746 MB 56.8 kB binhex-prowlarr 1.44 GB 219 MB 129 kB qbittorrent-vpn 1.34 GB 1.16 MB 7.58 MB Krusader 1.11 GB 3.12 MB 67.5 kB unifi-controller 756 MB 340 kB 36.0 kB audiobookshelf 626 MB 0 B 2.95 kB Foundry 422 MB 216 MB 65.6 kB plex 340 MB 46.8 kB 4.41 kB nzbget 208 MB 27.9 MB 24.3 MB tautulli 204 MB 2.66 kB 2.55 MB sonarr 195 MB 23.7 kB 149 kB Kitana 179 MB 619 kB 24.6 kB Tailscale 73.8 MB 209 B 792 kB Total size 21.7 GB 6.48 GB 56.8 MB
-
[SUPPORT] AlexRed's Template Repository
I've been using auto-m4b bit and it works well enough, but I notice is it is the biggest container in docker.img. Any idea how this can easily be reduced? Name Container Writable Log auto-m4b 5.67 GB 4.51 GB 20.9 MB AMP 5.42 GB 759 MB 120 kB calibre 2.26 GB 327 kB 4.31 kB calibre-web 1.50 GB 746 MB 56.8 kB binhex-prowlarr 1.44 GB 219 MB 129 kB qbittorrent-vpn 1.34 GB 1.16 MB 7.58 MB Krusader 1.11 GB 3.12 MB 67.5 kB unifi-controller 756 MB 340 kB 36.0 kB audiobookshelf 626 MB 0 B 2.95 kB Foundry 422 MB 216 MB 65.6 kB plex 340 MB 46.8 kB 4.41 kB nzbget 208 MB 27.9 MB 24.3 MB tautulli 204 MB 2.66 kB 2.55 MB sonarr 195 MB 23.7 kB 149 kB Kitana 179 MB 619 kB 24.6 kB Tailscale 73.8 MB 209 B 792 kB Total size 21.7 GB 6.48 GB 56.8 MB
-
Server Losing Network Connection
Update: No changes have been made to hardware or settings, but this morning I checked on the server and it was not pingable. I still had the monitor up and I was able to log in. I could not ping anything which is weird but networking was all there and the port was up. Here's the updated syslog. syslog-192.168.42.15.log
-
Server Losing Network Connection
Yesterday Plex had two scanning processes lock up and would not continue for hours. I tried stopping the container but it would not stop. I decided to restart unRAID so I killed the Plex process and closed the open files. The array would not stop and kept retrying. Eventually I restarted, everything came up OK. I just checked a few minutes ago and it appears the server rebooted on it's own about an hour and 45 minutes ago. Previously the server had been rebooting on it's own for about a week but then stopped. I attached the syslog. syslog-192.168.42.15.log
-
Server Losing Network Connection
Can do.
-
quietas started following Server Losing Network Connection
-
Server Losing Network Connection
Recently my unRAID system has been dropping off the network and I am not sure why. Hard reboot does work, but powering it off and then running through parity check every couple of days is not good. This morning it was offline after being up for the last 3 days no problems. I can't ping the IP, manually assigned, outside of DHCP range. The web page, shares, and all dockers are offline. I checked the server monitor (normally headless) I have plugged in I see a normal login prompt. I tried root and my password but it does not login. I hard reset the server and it came right up. Parity is running again. The hardware is a previous gaming system from a couple upgrades ago and it's been running unRAID for years now. I'm suspecting hardware, but how do I track down the failure with unRAID? I attached the diagnostics from after the reboot. Also after reboot I could log into the CLI. Any ideas for what to look at? tower-diagnostics-20230320-1103.zip
-
DNS resolution has stopped working
I found this post from a couple years back. It talked about avahi and how to disable it. I did not have a /boot/config/share.cfg so I made one and added shareAvahiEnabled="no" as the only thing in it. This seems to work once I rebooted the server. https://forums.unraid.net/topic/91825-dns-servers-not-retained-in-resolvconf-on-unraid-reboot/ Is this correct and will it break anything in the long run other than not using Apples Bonjour/Avahi stuff that I don't use anyway? If anyone is looking at this in the future, this is what I did. nano /boot/config/share.cfg shareAvahiEnabled="no" <ctrl-x> <enter>
-
DNS resolution has stopped working
On a side note, I see lots of posts with similar issues but no solutions. Why people? I hate it when people post a problem and don't come back to post what worked in the end.
quietas
Members
-
Joined
-
Last visited