blu3_v2

I have a HP N40L Microserver running 6.7.2 with no issues. After installing the 6.8.0 Update via Update OS and rebooting, my Array Devices in the Unraid GUI are all missing/blank - even my boot USB. Strangely the GUI reported Configuration Valid, however, instead of attempting to Start the Array I captured Diagnositics and downgraded back to 6.7.2 until this Issue can be explained/resolved. Daignostics Diagnostics.zip Before After This is the first time I have had an unsuccessful Update using Unraid, and would like to update to the current stable version rather than remain on a deprecated release. Could someone please take a look and provide some advice.

After blowing apart the server again, rechecking and re-seating all drives and connections I sat down and read through any logs from the Diagnostics.zip that I could decipher. I could not find any errors in SMART reports etc. and the syslog captured showed no errors, and the server had started up successfully and was ready to start with a Valid Array prior to logging in via Telnet and issuing the Poweroff command. I then set about troubleshooting any other potential issues and thought I would try reboot my Modem/Router, and all wireless iOS devices that I use to access the server on my LAN. After booting up the server (again) I was able to access the GUI, Start the Array, and access all Dockers etc. (all using my original Cache Drive so all Dockers and Data were preserved including in-progress downloads). So it appears that it was simply a LAN issue (IP conflict, hardware issue with Router???).

Firstly a little about my setup: - HP N40L Microserver running unRAID 6.7.2 with 6 Data Drives (8Tb Parity, 1 x 8Tb Data + 4 4Tb Data) and 1 Cache Drive (500Gb) - System is used simply to download and store media files on my local network, and is attached to APC UPS and hardwired directly to Wi-Fi Modem/Router, otherwise all access is via Wi-Fi via various devices (iOS) - Dockers: just the basics - Plex Media Server (LimeTech), ruTorrent (Linuxserver.io) and Sickbeard (all up to date with latest versions) - Uptime prior to Crash was 52 Days, and Parity was last checked only 2 Days ago, with 0 errors. System has been rock-solid and I have never encountered any major problems. The Incident: Last night I arrived home from work, opened up ruTorrent and added a couple of magnet links. After adding the links ruTorrent became unresponsive. Seeing that there have been issues with various versions having 100% CPU usage and I often see the docket reboot itself I was not too concerned. I waited a couple of minutes and tried again but could not reach ruTorrent so I tried unRAID Home with the same result - no GUI access. I fired up Termius and logged in via Telnet successfully, so issued the 'Poweroff' command so shut down the server (stupidly forgetting to save a Syslog or Diagnostics as I did not initially think much of the freeze). On reboot I was able to access the GUI, the Array was valid and all Array Drives present but I noticed that my Cache drive was missing from list of available Drives. I initially thought that maybe my old spinning rust disk had died, being the cause of the crash. I tried opening the syslog from the GUI but it had become unresponsive again. I figured that the 'dead' disk was causing slow reads/errors so logged in again via Telnet successfully and shut down again. I opened up my server and replaced the Cache Drive with a (Brand) New SSD I had in the cupboard and booted back up. When I first booted I opened the GUI successfully but noticed multiple Array Drives missing. I quickly shut the server down (via GUI), opened it backup and checked/re-seated all connections. On rebooting I was sucessfully able to access the GUI and confirm that all Disks were present, Array was valid, and new Cache Drive detected. I assigned the new Cache Drive and clicked Start to start the Array but the GUI did not respond. At this point I was becoming seriously concerned. I thought maybe my motherboard had grenaded and was dropping disks, so tried to connect via Telnet but this did not respond initially either. After trying again I was able to access the server via Telnet and confirm that all Disks were present and detected using the ls -l /dev/disk/by-id command. I then shut down again, and did some research online about what steps to take. I rebooted the server (again) and this time was unable to access the GUI at all (previous times I had been able to load the unRAID Home page, but it had not responded to commands), but could still Telnet in. I saved a copy of the Syslog and Diagnostics, which I have attached to this post (Note: on issuing the Diagnostics command I received a few lines of errors referencing missing info and giving line references to dynamix files etc, but the command completed successfully). I am seeking the help of the unRAID community in diagnosing/fixing this issue. I have always found the community super-helpful and have been able to resolve any minor issues I have had in the past. At this point I am not sure what hardware is to blame (Mobo, RAM, USB/Boot Drive), or if it could be a Software issue with a corrupt file(s). Could someone more knowledgeable than me take a look at the attached Diagnostics, help diagnose the cause(s) and/or let me know if there are any other steps I should take. syslog.txt watchtower-diagnostics-20190820-2108.zip

I also tried downgrading due to the previously mentioned CPU usage issue, however, since doing so my RSS Feeds no longer automatically update and files/folders are no longer automatically moved to their Tagged Directory (ie. TV/Movies) once downloads complete. I can manually Refresh Feed and downloads start fine. I have so far tried restarting the Docker and returned to the latest build and these problems persist. I am guessing it is a permissions issue - could someone please some advice on what to check or how to fix permissions (I thought this was performed automatically on Docker start). Update: Deleted Docker and reloaded from template (Latest) and the issues seem to have been resolved for now.

Another user checking in with unscheduled Parity Checks. Like Harro, KernelG and others I have a custom schedule (Checks scheduled for the first Monday of the month every 3rd month), and since updating to 6.6.1 Parity Checks have commenced EVERY Monday. Tried editing settings and selecting Apply, then Done but settings are ignored. From the 6.6.2 Release Notes this bug does not seem to have been fixed so thought I better post my experiences here

I could not see anything from the Release Notes, but does anyone know if 6.6.2 fixes the issue of Custom Parity Check Schedules being ignored. I have Checks scheduled for the first Monday of the month every 3rd month, and since updating to 6.6.1 Parity Checks have commenced EVERY Monday.

Just wanted to give a huge thanks to johnnie.black for the advice. I ordered a replacement PCIe SATA card (this time using an ASMedia chipset), installed it over the weekend, and now all drives are successfully recognised. I have just completed a Preclear and Parity check successfully, and old Parity has now been added to the Array. Thanks again for the expert advice.

Thanks, that is a relief.

As Drive 5 was not yet part of the Array and still showing as Unassigned, I was able to stop the Array and change Drive 5 to No Device. When I restarted the Array, Parity was still displayed as valid. Hopefully I don't have any Parity issues with the drive removed from the array before being successfully added. On checking the System Log I was getting constant errors as the system tried to spin this drive down. Once it was as Unassigned, it was still throwing errors into the Log. I have been advised by a helpful forum member that the Marvell controller on my SATA card is notorious for dropping disks, and still suspect dodgy cabling, so I have unplugged this drive from my server until I can source and now PCIe SATA card and cable.

Disk 4 has been on the same controller for a few weeks and has undergone a change from ReiserFS to XFS, as well as a complete Parity Check without issues. I set Disk 5 as No Device rather than attempt to add the old Parity back to the Array for now as it was giving errors while trying to Spin Down, and even now when Unassigned. I will unplug it until I can source a new SATA card and/or cabling.

Hi, After successfully upgrading my old and previously healthy 4Tb Parity Disk to a new 8Tb Disk and converting my entire array to XFS, I attempted to add the now Unassigned old 4Tb to the Array as additional storage (after re-checking Parity which showed 0 errors). However, the Process Aborted shortly after starting and now I am left with the old Parity Drive (Drive 5) having a Blue Square beside it. Could someone please take a look at my Diagnostics file(s) and advise me how to proceed to either fix and add the drive to the array or remove it without harming Parity. See link for Diagnostics http://users.on.net/~jilbo/watchtower-diagnostics-20180404-1845.zip (posted from iPad) Background info. The old Parity Disk in question was removed from its original hot-plug bay of my Microserver and reinstalled connected to a PCIe SATA card as part of the upgrade process. The first time I booted with the old Parity connected it was not available as an Unassigned Device (could only be seen by output of ls -l /dev/disk/by-id). It was only after shutting down and re-checking cabling that it appeared as an Unassigned Device. I suspect it may have been due to a loose connection to the PCIe card, as the card is definitely working - with Disk 4 in my array successfully connected to the other port.

Looks like I spoke too soon. Shortly after starting the Clearing process I received Read errors and the Process Aborted. Have posted in General Support section as unrelated to this plugin.

My old Parity Drive was perfectly healthy, and I can now report that it was correctly recognised as an Unassigned Device once I shutdown the server and triple-checked all cabling (turns out it must have a loose/intermittent connection to my PCIe SATA card). It is now undergoing a Preclear just to be safe before being added as an Array Disk.

Thanks for the tip. I just shutdown my server to check that it was not a cabling issue, and now when I boot the drive is not recognised at all. Looks like I will have to shutdown and recheck cabling again or remove the drive and see if I can format it from another system before adding to the array. I find it strange that the drive had previously been functioning perfectly in unRAID as a Parity drive, then when installed back into the same system it is not recognised. Maybe it has to do with the fact the the Parity drive contains data without a file-system or partition structure as such.

Did you ever get this issue sorted out and your disk recognised? I have a similar problem, having just completed a Parity Disk Upgrade (4 > 8Tb). When I plugged my old Parity Drive in it is not recognised as an Unassigned Device (from the unRAID Main Tab or when using the Unassigned Devices Plugin). It was seen as an output when I ran ls -l /dev/disk/by-id from the terminal and also showed up in the recently updated Preclear Disks Plugin screen (as device sdh), however, there is no drive/model info attached to the drive and when I attempted a Preclear it failed.

Awesome. Thanks for the confirmation johnnie.black

Update: I have replaced my old 4Tb Parity Drive with a new 8Tb HDD, and am currently completing the Parity Rebuild. I would like to re-use my current 4Tb Drive as a new Array Drive seeing that there is nothing wrong with it and I have room in both my case and on my unRAID Licence, but just wanted to check the correct process (as last time I added brand new drives to the array after using the preclear script - and I believe this is no longer required). Can I just do the following once the Parity Rebuild is complete: - Stop Array and Shutdown Server - Install the old Parity Drive - Restart Server, and assign it to a new Disk Slot - Start Array, and unRAID will format the drive Will unRAID be confused by the old parity disk being added back to the array in a new disk slot and mess up parity, or will it allow me to format and clear the drive for use (and probably to use the mirror-method to convert all of my Drives to XFS)?

Limetech - I just checked my server under Settings > Scheduler > Mover Settings > Mover logging, and it was already set to Enabled. I still don't see any Mover finished notifications as I did previously. Is there anywhere else I need to adjust my Mover notifications?

Thanks limetech, will dig around in Settings and turn it back on.

I second this request. I too like to run the Mover, stop Dockers, and stop Array prior to updating to reduce the risk of failure.

Thank you for the simplification. Am I correct in assuming that the same procedure applies to replacing a smaller array disk? Looks like XFS is the way forward. I will have to do some more reading, and may start a new topic to check my procedure when I am ready to add the old disks back to array.

Thanks for the advice, I realise I cannot convert in place. I thought that while I had a spare disk it might be an opportune time to use the mirror-method to copy my data disk by disk and convert to XFS, but was wondering if it is worth going to the trouble (is ReiserFS fine to keep using, and is XFS that much of an improvement?). If I am going to convert to XFS, it would be best to do it sooner rather than later (as amount of data and copy time is only going to increase with time).

Hi, I currently have a HP N40L Microserver running 4x4Tb HGST HDD on unRAID 6.4.1. I have just purchased 2x8Tb WD MyBook Externals, and plan on shucking the drives to Upgrade my server. Initially these drives will replace two of the existing drives (the first being the Parity disk of course, seeing it will be larger than my current Parity Drive), however, I then plan on adding the old drives to the array in the 5.25" slot using a PCI SATA card and Nexus Double-Twin. After reading the FAQ I think I have the procedure worked out, but wanted to check with the unRAID community (read - experts) to make sure I was planning on doing everything correctly as I wild hate to screw things up and lose any data. Parity Drive Replacement Procedure (Additional question - is this the same to replace an old 4Tb Array Drive with a new 8Tb?) 1. Run non-correcting Parity Check 2. Stop Array 3. Unassigned current Parity Drive 4. Shut Down server 5. Replace old 4Tb with new 8Tb Drive 6. Reboot server 7. Assign new 8Tb to Parity slot 8. Restart Array, at which point unRAID will prompt me to rebuild parity. Re-adding old drive(s) as new Array Drive (should this be done one disk at a time or can both old drives be added at the same time to extend array?) 1. Stop Array 2. Shut Down server 3. Install extra Drives 4. Reboot server 5. Add Drives to extra Disk slots 6. Restart Array, and unRAID should prompt me to format and add to Array. Am I missing anything or is this the correct Upgrade Procedure? On the subject of Formatting Drives, all of my current drives are formatted as ReiserFS. Am I best to: Format the new disks as ReiserFS so that all disks are the same format, format the new disks as XFS, or take this opportunity to convert my whole array to XFS which is now the recommended format as per unRAID?

Hi, My unRAID server (WATCHTOWER) has been running flawlessly and is currently on Version 6.3.2, however, I have just noticed the following error being repeated in the syslog since my last reboot: Watchtower ntpd[1454]: receive: Unexpected origin timestamp 0xdc894add.aeb536f1 does not match aorg 0xdc894b20.ae287975 from [email protected] xmt 0xdc894add.cfcfe1a9 This is the first time I have seen this error, so I have attached the diagnostic.zip to this post. Could anyone suggest a fix, or at least let me know if it is anything to worry about. Thanks in advance P.S. A bit of background. I have just moved house and plugged into the ADSL modem prior to booting up the server on this occasion. Could this be the cause or contributing to the problem? watchtower-diagnostics-20170401-0843.zip