linenoise

Members
  • Posts

    16
  • Joined

  • Last visited

linenoise's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. OK I'll update again and re-run parity. For completeness I'll update with the results. I agree the new error doesn't look like it is related to the plugin.
  2. Ok I re-ran parity, and didn't recive that particular error but I got a whole slue of new errors. I am not sure it is related to the parity plugin or not., or something else entirely. The parity check failed. See below Date Duration Speed Status Errors Elapsed Time Increments Type 2021-09-17, 10:27:34 17 hr, 24 min, 38 sec 95.7 MB/s OK 243 Unknown Unavailable 2021-09-14, 06:59:15 15 hr, 37 min, 30 sec 106.7 MB/s OK 0 Unknown Unavailable 2021-09-12, 03:30:06 3 hr, 15 min Unavailable Canceled 0 Unknown Unavailable 2021-09-10, 16:00:38 36 sec Unavailable Canceled 0 Unknown Unavailable 2021-09-09, 10:43:29 16 sec Unavailable Canceled 0 Unknown Unavailable 2021-09-09, 10:28:10 11 sec Unavailable Canceled 0 Unknown Unavailable 2021-09-08, 12:56:46 11 sec Unavailable Canceled 0 Unknown Unavailable 2021-08-13, 23:03:52 15 hr, 6 min, 8 sec 73.6MB/s OK 0 15 hr, 6 min, 8 sec 1 automatic Correcting Parity Check 2021-08-06, 21:38:43 16 hr, 38 min, 37 sec 66.8MB/s OK 0 16 hr, 38 min, 37 sec 1 scheduled Correcting Parity Check 2021-08-05, 21:01:59 16 hr, 1 min, 52 sec 69.3MB/s OK 0 16 hr, 1 min, 52 sec 1 scheduled Correcting Parity Check 2021-08-04, 20:48:59 15 hr, 48 min, 52 sec 70.3MB/s OK 0 15 hr, 48 min, 52 sec 1 scheduled Correcting Parity Check 2021-08-02, 21:01:38 16 hr, 1 min, 32 sec 69.3MB/s OK 0 16 hr, 1 min, 32 sec 1 scheduled Correcting Parity Check 2021-07-10, 07:41:19 16 min, 19 sec Unavailable Canceled 0 Unknown Unavailable 2021-06-22, 20:01:12 1 min, 36 sec 41.7GB/s Canceled 0 1 min, 36 sec 1 automatic Correcting Parity Check 2021-06-22, 01:50:29 15 hr, 55 min, 22 sec 69.8MB/s OK 0 15 hr, 55 min, 22 sec 1 automatic Parity Sync/Data Rebuild 2021-06-17, 12:33:44 1 min, 37 sec Unavailable Canceled 0 Unknown Unavailable 2021-06-16, 17:42:02 4 min, 42 sec Unavailable Canceled 0 Unknown Unavailable 2021-06-16, 17:02:28 1 min, 5 sec Unavailable Canceled 0 Unknown Unavailable 2021-06-16, 09:14:02 2 min Unavailable Canceled 0 Unknown Unavailable 2021-06-14, 16:42:02 5 min, 19 sec Unavailable Canceled 0 Unknown Unavailable 2021-06-14, 15:33:59 3 min, 53 sec Unavailable Canceled 0 Unknown Unavailable 2021-06-13, 17:07:02 39 min, 10 sec 1.7GB/s Canceled 0 39 min, 10 sec 1 automatic Parity Sync/Data Rebuild 2021-06-13, 15:48:56 1 min, 57 sec Unavailable Canceled 0 Unknown Unavailable 2021-06-13, 15:46:52 15 sec Unavailable Canceled 0 Unknown Unavailable 2021-06-13, 14:42:02 5 min, 48 sec Unavailable Canceled 0 Unknown Unavailable 2021-06-13, 14:22:48 17 sec Unavailable Canceled 0 Unknown Unavailable 2021-06-13, 09:28:02 35 sec Unavailable Canceled 0 Unknown Unavailable 2021-06-01, 12:51:51 28 sec Unavailable Canceled 0 Unknown Unavailable 2021-05-28, 10:00:01 5 min, 8 sec 13.0GB/s Canceled 0 5 min, 8 sec 1 automatic Correcting Parity Check 2021-05-27, 00:21:01 2 hr, 1 min, 16 sec 549.9MB/s Canceled 0 8 day, 7 hr, 22 min 10 automatic Non-Correcting Parity Check 2021-05-15, 16:56:01 1 min, 18 sec 51.3GB/s OK 0 1 min, 18 sec 1 automatic Correcting Parity Check 2021-05-15, 16:56:02 40 sec Unavailable Canceled 0 Unknown Unavailable 2021-05-10, 14:48:49 13 sec Unavailable Canceled 0 Unknown Unavailable 2021-04-12, 22:33:37 8 sec Unavailable Canceled 0 Unknown Unavailable 2021-04-12, 00:21:02 6 hr, 42 min, 7 sec 165.8MB/s Canceled 0 24 day, 7 hr, 23 min, 32 sec 8 scheduled Non-Correcting Parity Check 2021-02-25, 21:37:49 8 sec Unavailable Canceled 0 Unknown Unavailable 2021-02-22, 09:44:33 1 day, 3 hr, 18 min, 31 sec 40.7MB/s OK 0 2 day, 18 hr, 39 min, 59 sec 53 Correcting 2021-02-14, 00:23:02 1 day, 2 hr, 38 min, 11 sec 41.7MB/s OK 0 1 day, 23 hr, 56 min, 5 sec 43 Correcting 2021-01-26, 23:40:15 13 hr, 39 min, 22 sec 81.4 MB/s OK 0 Unknown Unavailable 2021-01-26, 07:40:37 13 hr, 34 min, 53 sec 81.8 MB/s OK 0 Unknown Unavailable 2021-01-19, 08:13:49 8 min, 22 sec Unavailable Canceled 0 Unknown Unavailable 2021-01-18, 08:37:01 1 min, 46 sec Unavailable Canceled 0 Unknown Unavailable 2021-01-17, 07:09:34 14 hr, 29 min, 39 sec 76.7 MB/s OK 0 Unknown Unavailable 2021-01-09, 12:02:00 13 hr, 3 min, 57 sec 85.1 MB/s OK 0 Unknown Unavailable 2021-01-08, 20:09:18 1 min, 29 sec Unavailable Canceled 0 Unknown Unavailable 2021-01-08, 14:25:05 5 min, 22 sec Unavailable Canceled 0 Unknown Unavailable 2021-01-04, 22:10:49 11 sec Unavailable Canceled 0 Unknown Unavailable 2021-01-03, 23:15:11 1 min, 42 sec Unavailable Canceled 0 Unknown Unavailable 2021-01-01, 08:17:12 1 min, 55 sec Unavailable Canceled 0 Unknown Unavailable 2020-12-31, 16:21:18 15 min, 45 sec Unavailable Canceled 0 Unknown Unavailable 2020-12-22, 05:51:58 14 hr, 54 sec 79.3 MB/s OK 0 Unknown Unavailable 2020-12-18, 18:51:45 22 sec 181.9 GB/s Canceled 0 22 sec 1 Read 2020-12-10, 07:55:25 6 min, 32 sec 10.2 GB/s Canceled 0 6 min, 32 sec 1 Correcting 2020-12-08, 18:37:51 13 sec Unavailable Canceled 0 Unknown Unavailable 1 day, 3 hr, 19 min, 18 sec 2 OK Unknown Unavailable 2020-12-08, 08:19:15 5 hr, 4 min, 14 sec 219.2 MB/s OK 18856 Unknown Unavailable 2020-12-04, 13:18:34 16 sec 250.0 GB/s Canceled 0 16 sec 1 Non-Correcting 2020-12-04, 13:17:29 8 hr, 17 min, 28 sec 134.0 MB/s OK 0 8 hr, 17 min, 28 sec 1 Non-Correcting 2020-12-03, 13:05:22 2 min, 56 sec Unavailable Canceled 0 Unknown Unavailable 1 day, 22 hr, 50 min, 56 sec 1 OK Unknown Unavailable 2020-12-03, 05:35:47 2 hr, 20 min, 46 sec 473.7 MB/s OK 18856 Unknown Unavailable 2020-11-22, 20:12:34 38 sec 105.3 GB/s Canceled 0 38 sec 1 Non-Correcting 2020-11-22, 10:05:42 11 sec Unavailable Canceled 4 2020-11-10, 13:02:45 2 hr, 26 min, 26 sec 455.4 MB/s OK 0 2020-10-11, 22:24:48 13 hr, 35 min, 35 sec 81.8 MB/s OK 0 2020-09-30, 22:24:35 11 sec Unavailable Canceled 0 2020-09-30, 10:37:25 14 sec Unavailable Canceled 0 2020-09-28, 14:34:16 2 hr, 47 min, 19 sec Unavailable Canceled 0 2020-09-27, 13:43:27 14 hr, 17 min, 55 sec 77.7 MB/s OK 0 2020-09-22, 22:58:32 1 min, 13 sec Unavailable Canceled 0 2020-09-19, 21:37:22 13 hr, 36 min, 33 sec 81.7 MB/s OK 0 2020-09-15, 09:59:31 14 hr, 30 min, 44 sec 76.6 MB/s OK 0 2020-09-06, 13:32:06 13 hr, 56 min, 19 sec 79.7 MB/s OK 0 2020-08-23, 08:03:39 14 hr, 18 min, 36 sec 77.7 MB/s OK 0 2020-08-20, 14:29:46 6 hr, 13 min, 6 sec Unavailable Canceled 0 2020-08-13, 03:17:49 14 hr, 2 min, 40 sec 79.1 MB/s OK 0 2020-08-09, 00:04:00 13 hr, 26 min, 10 sec 82.7 MB/s OK 0 2020-08-04, 18:41:02 13 hr, 41 min, 1 sec 81.2 MB/s OK 0 2020-07-16, 16:26:43 8 hr, 16 min, 12 sec 134.4 MB/s OK 0 2020-07-16, 08:06:49 4 min, 40 sec Unavailable Canceled 0 2020-07-15, 18:52:55 4 hr, 6 min, 53 sec Unavailable Canceled 0 2020-07-05, 19:26:04 13 hr, 34 min, 4 sec 81.9 MB/s OK 0 2020-06-12, 18:00:48 13 hr, 41 min, 7 sec 81.2 MB/s OK 0 2020-06-07, 08:44:17 7 min, 28 sec Unavailable Canceled 0 2020-05-05, 11:05:06 16 hr, 22 min, 26 sec Unavailable Canceled 0 2020-04-07, 18:27:17 13 hr, 27 min, 16 sec 82.6 MB/s OK 0 2020-03-10, 04:20:40 7 hr, 2 min, 17 sec Unavailable Canceled 0 2020-03-05, 05:23:06 14 hr, 20 sec 79.3 MB/s OK 0 2020-02-18, 22:03:50 13 hr, 29 min, 8 sec 82.4 MB/s OK 0 2020-02-18, 02:07:25 13 hr, 37 min, 54 sec 81.5 MB/s OK 18 2020-02-06, 10:41:41 2 min, 42 sec Unavailable Canceled 0 2020-01-22, 19:21:23 43 sec Unavailable Canceled 0 2020-01-22, 19:10:23 10 hr, 5 min, 48 sec Unavailable Canceled 0 2020-01-21, 08:35:32 4 min, 44 sec Unavailable Canceled 0 2020-01-19, 22:59:17 2 min, 43 sec Unavailable Canceled 0 2020-01-04, 09:10:45 32 sec Unavailable Canceled 0 2020-01-04, 08:17:57 13 hr, 54 min, 33 sec 79.9 MB/s OK 0 2019-12-27, 01:23:41 15 hr, 8 min, 35 sec 73.4 MB/s OK 0 2019-12-18, 02:18:29 18 hr, 13 min, 31 sec 61.0 MB/s OK 0 2019-12-03, 19:11:08 14 hr, 11 min, 7 sec 78.3 MB/s OK 0 2019-10-17, 20:49:06 12 hr, 41 min 87.6 MB/s OK 0 2019-09-07, 23:42:31 13 hr, 55 min, 56 sec 79.8 MB/s OK 0 2019-08-06, 18:59:54 13 hr, 59 min, 53 sec 79.4 MB/s OK 0 2019-08-01, 02:48:55 14 hr, 1 min, 35 sec 79.2 MB/s OK 0 2019-07-28, 10:35:50 21 min, 49 sec Unavailable Canceled 0 2019-07-26, 22:43:39 14 hr, 38 min, 33 sec 75.9 MB/s OK 0 2019-05-22, 09:01:23 14 min, 18 sec 4.7 GB/s OK 0 2019-05-22, 06:01:23 14 min, 18 sec 4.7 GB/s OK 0 2019-05-06, 08:14:30 13 hr, 5 min, 37 sec 84.9 MB/s OK 0 2019-04-30, 18:36:20 13 hr, 36 min, 19 sec 81.7 MB/s OK 0 2019-04-23, 18:53:05 13 hr, 53 min, 4 sec 80.0 MB/s OK 0 2019-04-22, 07:33:55 21 hr, 26 min, 2 sec 51.8 MB/s OK 0 2019-04-16, 18:32:15 13 hr, 32 min, 14 sec 82.1 MB/s OK 0 2019-04-09, 18:43:08 13 hr, 43 min, 7 sec 81.0 MB/s OK 0 2019-04-05, 08:35:50 14 hr, 19 min, 44 sec 77.6 MB/s OK 82 2019-01-09, 06:28:39 12 hr, 58 min, 52 sec 85.6 MB/s OK 0 2018-12-28, 15:33:53 3 min, 33 sec Unavailable Canceled 0 2018-12-28, 15:30:03 20 hr, 16 min, 31 sec Unavailable Canceled 0 2018-12-27, 19:03:46 42 min, 6 sec Unavailable Canceled 0 2018-12-27, 18:16:24 22 sec Unavailable Canceled 0 2018-11-23, 06:40:28 13 hr, 29 min, 11 sec 82.4 MB/s OK 0 2018-11-06, 19:01:43 14 hr, 1 min, 42 sec 79.2 MB/s OK 0 2018-10-30, 21:18:43 16 hr, 18 min, 42 sec 68.1 MB/s OK 0 2018-10-23, 18:03:15 13 hr, 3 min, 14 sec 85.1 MB/s OK 0 2018-10-16, 06:41:12 31 min, 52 sec Unavailable Canceled 0 2018-10-16, 05:16:53 16 min, 52 sec Unavailable Canceled 0 Sorry the column headers don't align with he columns but looks like at the 17 hr mark there where over 200 errors. Forgive me I not really good at reading this log but I cant tell what the actual error is.
  3. I was on 2021.09.10 I just updated to 2021..09.14 and am re-running parity. I'll follow-up with how the parity goes. Thanks
  4. I am getting a similar error when I run parity check. I replaced my 4 Tb parity drive with a 6 Tb one, now every time I run a full parity check to validate the new parity drive it fails a few hours in. I also tried to reboot several times and restart. Here is the exact error I am getting. Looks like both have something to do with the parity.check.tuning Fatal error: Cannot redeclare _() (previously declared in /usr/local/emhttp/plugins/parity.check.tuning/Legacy.php:6) in /usr/local/emhttp/plugins/dynamix/include/Translations.php on line 19
  5. Just to document my steps for anyone else looking at this. Removed -n flag got this message. Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this. Ran with -L flag got this in return Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this. Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ALERT: The filesystem has valuable metadata changes in a log which is being destroyed because the -L option was used. - scan filesystem freespace and inode maps... sb_ifree 91730, counted 91613 sb_fdblocks 216766133, counted 218441001 - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 bad CRC for inode 797857 bad CRC for inode 797857, will rewrite cleared inode 797857 - agno = 1 - agno = 2 Metadata corruption detected at 0x459730, xfs_dir3_block block 0x3a8aa5b8/0x1000 bad directory block magic # 0x58444433 in block 0 for directory inode 1078977760 corrupt block 0 in directory inode 1078977760 will junk block no . entry for directory 1078977760 no .. entry for directory 1078977760 problem with directory contents in inode 1078977760 cleared inode 1078977760 correcting imap correcting imap correcting imap correcting imap correcting imap correcting imap -------- deleted receptive message ------ Will spin up without maintenance mode and see if this fixes the crashes. Hop the log file wasn't too important since I had it destroyed to continue with repair.
  6. I don't have a disk 15, so I am am guessing the cache drive. I put the array in maint mode and ran the xfs_repair found in Main > cache > check file system. The following is the output I got using the default settings with -n flag. Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ALERT: The filesystem has valuable metadata changes in a log which is being ignored because the -n option was used. Expect spurious inconsistencies which may be resolved by first mounting the filesystem to replay the log. - scan filesystem freespace and inode maps... sb_ifree 91730, counted 91613 sb_fdblocks 216766133, counted 218441001 - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 bad CRC for inode 797857 bad CRC for inode 797857, would rewrite would have cleared inode 797857 - agno = 1 - agno = 2 Metadata corruption detected at 0x459730, xfs_dir3_block block 0x3a8aa5b8/0x1000 bad directory block magic # 0x58444433 in block 0 for directory inode 1078977760 corrupt block 0 in directory inode 1078977760 would junk block no . entry for directory 1078977760 no .. entry for directory 1078977760 problem with directory contents in inode 1078977760 would have cleared inode 1078977760 imap claims in-use inode 1082884434 is free, would correct imap imap claims in-use inode 1082884435 is free, would correct imap imap claims in-use inode 1082884436 is free, would correct imap imap claims in-use inode 1082884437 is free, would correct imap imap claims in-use inode 1082884438 is free, would correct imap imap claims in-use inode 1082884439 is free, would correct imap imap claims in-use inode 1082884440 is free, would correct imap imap claims in-use inode 1082884441 is free, would correct imap .... I deleted a bunch of these lines which where just incrementing through inode picking up with an intresting bit imap claims in-use inode 1082924397 is free, would correct imap - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 1 - agno = 3 - agno = 2 - agno = 0 bad CRC for inode 797857, would rewrite would have cleared inode 797857 bad directory block magic # 0x58444433 in block 0 for directory inode 1078977760 corrupt block 0 in directory inode 1078977760 would junk block no . entry for directory 1078977760 no .. entry for directory 1078977760 problem with directory contents in inode 1078977760 would have cleared inode 1078977760 entry "tmp" in shortform directory 546483779 references free inode 1078977760 would have junked entry "tmp" in directory inode 546483779 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... entry "tmp" in shortform directory inode 546483779 points to free inode 1078977760 would junk entry - traversal finished ... - moving disconnected inodes to lost+found ... disconnected inode 1077444767, would move to lost+found disconnected inode 1077520792, would move to lost+found disconnected inode 1078977881, would move to lost+found disconnected inode 1082643091, would move to lost+found ... Ending with this disconnected inode 1082924396, would move to lost+found disconnected inode 1082924397, would move to lost+found Phase 7 - verify link counts... would have reset inode 546483779 nlinks from 3 to 2 No modify flag set, skipping filesystem flush and exiting.
  7. Here is the diag file. tower-diagnostics-20210125-1034.zip Thanks
  8. Ok this looks like it fixed the trace issue but now I have other errors, this might be due to curopt data caused by the lockups from the original issue. These are the error messages I'm getting. crash on Jan 18 2021 crash on Jan 19 2021 crash Jan 20 2021 Crash Jan 25 2021 I see the message to run XFS repair but not sure if 1. that is the main cause of the crashing 2. which drive to run it on. Looking at (dm-14) as the source, and looking at the XFS_repair at https://wiki.unraid.net/index.php/Check_Disk_Filesystems#xfs_repair I ran xfs_repair -v /dev/sg14 which I found in the /dev directory shown here. Not getting anykind of status, or indication it is doing anything, see screenshot below. I'll let it sit for a while. Thanks, Linenoise
  9. Yes, I have several dockers with custom IP address: I have: br0 = same subnet as unraid 10.0.0.x/24 Pi-hole br0 NginxProxyManager br0 Nextcloud br0 had shinobi on br0 which was on a separate vlan but disabled that a while ago and still got crashes. Pi-hole I had running for a few years without issue. Nextcloud and NginxProxyManager are the 2 I've installed recently around the time the crashes started. On a similar note, not sure if this indicates any issues or is just a bug with unraid, but when I use a custom IP address with dockers and try to change the host port, it seems to ignore the change and still use the default port. I will shutdown nextcloud docker and see if the network stabilizes. thanks
  10. This has been a reoccurring issue where Unraid crashes several times a week. The server is non responsive and the console has a crash report on the screen with the major error being a kernal panic, see pictures below. I took 2 pictures from two different crashes. I read through the posts here concerning other Kernel panic issues. Step I have tried so far: 1. did mem86 test (the latest one from the website not the one on unraid boot) no issue 2. check the memory speed. Actually the memory is rated for 2133 mHz but the auto select in bio down clocked to 1600. I tried to set to 2133 but wouldn't even boot. 3. all other overclocking is disabled just put everything to auto detect 4. brand new powersupply so i'm not suspecting anything strange there. Here are the syslogs, they are after 2 reboots so not sure how helpful they are. tower-syslog-20210112-2124.zip Thanks for your help Linenoise Hardware.xml
  11. Thanks Squid!!!! That fixed it perfectly. Hopefully this will also help with the dockers acting strangely and randomly crashing.
  12. Running unraid: 6.8.3 I've been playing around with loading and unloading different dockers when I started to have trouble with them. I rebooted unraid and now the docker service fails to start. I am getting a ton of USB errors in the logs. From the log Dec 6 11:58:47 Tower kernel: usb 7-2: device descriptor read/64, error -32 Dec 6 11:58:49 Tower kernel: usb 7-2: device not accepting address 54, error -32 I just replace the USB drive a few weeks ago that was giving me issues and everything work fine after. I purchased the SAMSUNG BAR Plus 32GB - 200MB/s USB 3.1 Flash Drive, based on spaceinvader One's video on recommended USB. I do have a Marvel Hard drive controller installed since I had to add some more drives and I happen to have the controller laying around, I plan to replace it but I don't think that is the cause of the issue as everything points to the usb. From the Log Dec 6 12:01:14 Tower root: Fix Common Problems: Warning: Marvel Hard Drive Controller Installed. I have attached the log dump. What I have tried so far: Restart docker service reboot server full shut down and start up to reboot Another snippet from the logs: Dec 6 12:07:15 Tower kernel: usb 7-2: device not accepting address 61, error -32 Dec 6 12:07:15 Tower kernel: usb usb7-port2: unable to enumerate USB device Dec 6 12:07:28 Tower kernel: usb 7-2: new low-speed USB device number 62 using ohci-pci Dec 6 12:07:28 Tower kernel: usb 7-2: device descriptor read/64, error -32 Dec 6 12:07:28 Tower kernel: usb 7-2: device descriptor read/64, error -32 Dec 6 12:07:28 Tower kernel: usb 7-2: new low-speed USB device number 63 using ohci-pci Dec 6 12:07:29 Tower kernel: usb 7-2: device descriptor read/64, error -32 Dec 6 12:07:29 Tower kernel: usb 7-2: device descriptor read/64, error -32 Dec 6 12:07:29 Tower kernel: usb usb7-port2: attempt power cycle Dec 6 12:07:29 Tower kernel: usb 7-2: new low-speed USB device number 64 using ohci-pci Dec 6 12:07:30 Tower kernel: usb 7-2: device not accepting address 64, error -32 Dec 6 12:07:30 Tower kernel: usb 7-2: new low-speed USB device number 65 using ohci-pci Dec 6 12:07:30 Tower kernel: usb 7-2: device not accepting address 65, error -32 Dec 6 12:07:30 Tower kernel: usb usb7-port2: unable to enumerate USB device tower-syslog-20201206-1704.zip
  13. I tried several methods I found on the internet but couldn't remove the write only, even using partitioning tools. I ended up getting a new USB drive, based on a video from space invader one. Backedup and restored onto the new USB drive, got a new Unraid licence. Now everything is working greate. It all came down to the USB not being write only. The drive was probably on its way out. It would be a nice feature for unraid to have a failover usb option similar to freeNAS. Thanks Constructor for the help and pointing me in the right direction about the USB. Linenoise
  14. I tried to place the unraid boot usb into my windows machine and it did pop up with errors, but when I try to run run "correct errors" it fails and says the drive is read only. When I bring up properties for the usb drive it is missing the security tab. Anyway to make the drive read/write? This is a micro usb and there is no mechanical write protect switch on it.
  15. Thanks, I'll do that in the morning, I did have several ungraceful shutdowns. Linenoise