sharaleo

Support sorted me out. All good now!

Ah, key replacement does not apper to be working. The array recognises the old key file and initiates the replacement process. Hit hitting Replace Key on the registration page opens a pop-up that (after signing in) then says to complete the process by hitting the Finish Key Replacment button in the GUI, but that just opens the same pop-up windows again. I have emailed support with details, so I am sure they will sort me out.

Thanks! Array is back up, data seems fine. I'll get to work on reconfigurations and sorting out the license side of things!

Howdy, been a while, a testament to how well Unraid runs, really... I finally had a USB die. In fact, this USB is a 1GB Sandisk Cruzer pretty much from when I first deployed Unraid. It dates back to at least 2008. It's seen some s%*t. My array started misbehaving, plugins/dockers would not update, so i did a reboot and discovered the fault seems to have been the USB dying. Probably should have replaced that sucker a while ago... Unfortunately, I don't have a recent USB backup. I thought my Crashplan setup was capturing the flash drive but that does not appear to be the case. The most recent USB backup I do have is from 2021 but I know at least a couple of drives have changed and likely a few share, docker and general config settings. I am trying to access the failed USB, but at this stage it will not come up in Windows after trying a few things, so I am not confident. That said, my shares are not that complicated and my dockers are ultimately ephemeral and can be re-configured without too much trouble. I do know my drive order with certainty, so no issues there. As long as I can get the array up, I can re-configure pretty much everything else. I just want to validate what my next steps should be. 1 - Re-install current Unraid to new flash drive 2 - Boot, enter new password to access GUI, assign drives 3 - Start array 4 - Re-configure shares, plugins, docker and other settings 5 - Follow procedure to re-apply license Does that seem corrent? Anything I am missing? When I start the array, should I check the 'Parity is already valid'? I will run a fresh parity check anyway, once I confirm the array is up and data is all present and correct, but should I first start the array with that setting checked, then restart with it unchecked after confirming everything looks good? Also, with license registration, the FAQ says '...install Unraid on the new flash device, boot it up on your server, and then install the old registration key on the new flash (from the Tools > Registration page). From there you can request and then install a replacement key." However, I see nothing in the GUI to install the old registration key (ie I guess the pro1.key file from my 2021 backup?). Am I understanding that right? I feel like I may need to contact support since the registration/license process has probably changed... Thanks in advance!

Thanks for the reply. Ended up being something simpler - stupid Unraid date has slipped, so could not pull any update info at all from docker or git. Realised when I tried for the Unraid update and got cert errors... Updated Unraid, then the containers, now all good. Cheers!

Silly question, but how do I update the docker container? I am still on...er...sabnzbd 1.0.2 running on Unraid 6.1.9. Unraid has never shown that the container is anything other than up to date: Even if I force update, I don't really get a result: Is my install too old, or am I doing updates wrong? Have the repositories changed? Best to just delete and pull a fresh build? Thanks in advance!

Quick bump to say thanks for the consise guide. Bit the bullet and finally upgraded to 6.1.9 from 5.0.4 tonight without a hitch (well it just booted and my shares are up, so I should be good!). Cheers!

Ran --rebuild-tree, seems to have resolved the problem, a few files in lost&found, but the array is back, along with all shares. Cheers!

parity:

3rd attachment unraid_syslog_28-07-2012_-_post_reiserfsk_on_md2_-_smaller_version.txt

2nd attachment unraid_-_28-07-2012_-_results_of_reiserfsk_on_md2.txt

Hi all, been a while, but my unraid typically just tends to run... Been stable for 9 months and went on holiday for a few weeks. Came back to a failed drive in my array. Tried a reboot, only to get a constant mechanical drive noise, more or less confirming drive death. Replaced that drive and went through a rebuild. Seemed to be ok, but I started to suffer some write problems. Copying data just did not work, no errors in Windows, just sat there doing nothing. Additionally, I then noticed my shares were missing files/folders. Ran a reiserfsk check on my replaced drive and was instructed to --fix-fixable, which I did. This resulted in no lost&found folders on the drive. Problem was not resolved so I did a parity check, which seemed fine (all green), but resulted in intermittent ata errors on a different drive (did not capture the syslog before reboot). Ran a reiserfsk on that drive, which results in a --rebuild-tree. The wiki instructs to ask fof help, so here I am! What action should I take from here? Original failed drive was disk9 (md9). Replaced failed Seagate 1TB with brand new Seagate 1TB New drive problem is on disk2 (md2) - Western Digital 1Tb WDC_WD10EARS - can browse the drive via windows explorer, some content 'looks' to be missing (one folder of four is empty when I suspect it should have content) A couple of files attached: - Fresh reboot syslog - reiserfsk result from md2 - syslog post remount from reiserfsk check on md2 Hardware: Intel Core2Duo E2180 4Gb Ram - 4 x 1Gb Gigabyte GA-EP35-DS3R Supermicro 8 port SATA card - PCI (the recommended one that was originally supported) Intel gig NIC - PCI 16 Drives - all SATA no cache drive single 750W Corsair PS (12 months old) unraid_Syslog_28-07-2012.txt

Thanks!

Hi mate, I have a P5Q series mobo as well. I had intermittent networking issues for around 12 months. On large copies the server would become unresponsive, drop network and require a hard reboot. I replaced drives, power supplies and tried multiple version of Unraid, all to no avail. The problem ended up being the onboard ethernet controller - I don't think Unraid likes it. From advice here I picked up a cheap Intel based gigabit PCI card and have not had any issues since. (I disabled the onboard controller in BIOS)

Hi All, I just upgraded a drive in my array, but it is rebuilding extremely slowly. I think I may have knocked another drive cable as I am getting a ton of read errors on a different disk. Question is, what is the safe way to shut the array down in its current state? Should I cancel the data rebuilt then stop the array, or just strop it? Cheers!

Thanks all, pretty much followed that advice and let Unraid rebuild the drive itself. All good now, array is up and all data present. I have a feeling the HPA was added to the drive when I upgraded the MB BIOS a while back. As mentioned above, the newer BIOS added the Xpress Recovery feature, so it probably added it to the drive on the next boot. I also just dropped in an Intel PCIe NIC. Hopefully my issues with the array becoming unresponsive on large writes goes away now. Thanks!

Hey Guys, I think I have this under control, but I just would like a sanity check before I proceed. I downgraded to a BIOS I know does not support HPA (according to Gigabyte F4 added the functionality, so I flashed to F3). I have checked and rechecked the BIOS (including advanced settings), and can find no reference to anything HPA related. I booted, confirmed the correct drive and ran the necessary hdparm command. It worked (which is probably a good sign the BIOS isn't trying to set it on boot). Now I reboot and the drive is showing as the correct size, but blue. Unraid understandably thinks I upgraded the drive with a larger one. I ran a reiserfsck on the drive, which returned no corruption issues. So, do I now just run a 'Trust My Parity' as detailed below, and cross my fingers? http://www.lime-technology.com/wiki/index.php?title=Make_unRAID_Trust_the_Parity_Drive,_Avoid_Rebuilding_Parity_Unnecessarily Cheers!

Nasty. Seems at least I don't have HPA on my Parity drive, so that is something. So solution should be as follows (searching forum for specifics): 1 - disable this BIOS feature and ensure mobo is NOT enabling it by default (through updating bios and double checking default is off) , or replace mobo 2 - remove the HPA from the drive by running the relevant hdparm -N command 3 - reboot, assuming all green, run parity. If not, um...seek further advice.... Sound right? Assuming the drive then mounts and the array starts, is there any possibility I'll have issues with parity, given it's a non-parity drive? Should I only run a "Trust my Parity"?

Hi All, I am finally getting around to migrating my array to 4.7 Final. Seem to have an issue with a drive and am seeking advice. I have had intermittent problems with the array when writing large volumes. It will become unresponsive and requires a hard reboot. I have done various things (short of core hardware replacement) to try and diagnose, including disk checks. Log capture reveals absolutely nothing prior to any crashes, so they have been no use. Given I rarely write to the array, I have not exhaustively looked into this. Nevertheless, tonight following a failure during writes, I finally had enough and decided to upgrade to 4.7 and see if this resolves the issue (I know I should have done this ages ago). I was running 4.5.6 and had a valid config, all drives green. I have copied the required files to my USB drive (bzimage, bzroot and memtest for a 4.5.x to 4.7 upgrade). No changes to the hardware config at all, but now I get a red disk when the array boots. Below is the disk screen on boot with the problem drive. It is reporting an incorrect size. Unraid seems to think this disk is new, probably based on the size descrepancy. So the question I have - is this something to do with the 4.7 upgrade, or a good indication that this drive is likely an issue and should be replaced (note the array starts under 4.5.6). Heck this sucker might even be the cause of all my issues. If I should replace the disk, should I roll back to 4.5.6 and replace it from there, then upgrade to 4.7? Or just replace it and let a parity sync take care of it under 4.7? Syslog also attached for reference. Any advice would be appreciated. Thanks in advance! Hardware Mobo - Gigabyte GA-EP35-DS3R 4Gb Ram - Recently Memtested SuperMicro 8 Port Sata PCI card 16 SATA Drives Total No Cache Drive syslog-2011-07-27_-_4.7_upgrade.txt

Thanks! I have set up a Telnet and Tail, so hopefully it will capture something useful next time I have a crash. I'll post all relevant info if and when that occurs. Cheers!

Hiya, I am having some ongoing problems where my Unraid server becomes unresponsive during sustained writes. It locks up, all shares disappear and it becomes inaccessible either by webgui or terminal. In my quest to identify the problem I have run a smartctl on each drive, with no glaring errors. I figure the next step is to run a filesytem check on each of the drives to identify if there are any issues there. I am aware that it is a bad to run a reiserfsck on the parity drive, but need clarification on how to identify which drive is parity. The instructions in the FAQ are to run the below command. What I need to identify is which device (mdx) the parity drive is, so I don't run this command against it. Is parity drive always disk0 and hence md0? reiserfsck --check /dev/md1 (disk1) Thanks in advance! Incidentally, is there are way to capture the log when a lock up of this nature occurs?

I put mine in the regular PCI slot furthest from the CPU socket.

I can now confirm that the SuperMicro card is working on th GIGABYTE GA-EP35-DS3R! Swapped my A8N-SLI Deluxe over to the Gigabyte and it boots no probs. All drives are present and working in Unraid. After further testing on the A8N-SLI, I now believe it is faulty and the cause of my issues. Cheers!

Problem solved!! The culprit was....dodgy mobo!! The A8N-SLI Deluxe I was using is a second-hand jobby I picked up cheap. It appears absolutely fine, except there must be an issue somewhere on the PCI bus. I have tried this motherboard in two arrays now in may different combinations. I have three PCI storage controllers - SuperMicro 8 Port SATA. Generic Silicon Image 4 Port SATA. Generic Silicon Image 2 Port IDE, regardless of which array, what memory, and what configuration of attached drives, this mobo will not boot with any more than one device attached to any PCI controller. Given the the motherboard seems to be the common denominator, I pretty much must conclude that it is at fault, although given it's second-hand, I probably would not conclude that this mobo is not suitable for Unraid. Changed my main array over to a Gigabyte GA-EP35-DS3R and it comes up no problems. Yippee!

Seriously, if they are wanting to remove old data for archival purposes, surely the only real answer is the proven solution of tape backup. I am talking SDLT or LTO here, not SOHO/SMB DAT and AIT crap... As mentioned by a previous poster, I certainly would not trust electronic components like a HD to sit in a safe somewhere and expect data to be recoverable after a few years. Unraid might be fine for protected local storage if transfer speeds are not an issue (it actually sounds like a good fit given their very small size), but if these guys are serious about archiving their data then stick to something that's archival longevity is proven. There may be more cost associated in setting it up, but remember this is their Intellectual Property and presumably their livelihood. Losing this data once it is out of any kind of protected array is probably not an option - that means tape and off-site archival storage (or maybe emerging online backup services - bandwidth permitting...) Unraid is in my opinion, absolutely BRILLIANT for home/SOHO use: different sized disks, parity protection, directory aggregation, no messy "traditional" RAID crap. It is being actively worked on with a growing feature-set. However, if for some reason, I have a catastrophic failure and lose 3TB of Music and Movies, it is hardly the end of my world. The same could not be said if I was running a business and was required to store any kind of business data, mission critical or otherwise. The VALUE of the solution should not be measured by the COST of the solution, but rather by the COST to the business of any potential Data loss. It might cost 20k+ for a robust mid-teir enterprise level solution, but if losing the data means closing the business, it's a small price to pay... Sorry...ranting...Disaster Recovery and Business Continuity are hot topics in Australia at the moment, you'd never suspect I work in the IT industry...selling storage products...