Upgrading Unraid 5.0.6/6.3.5 on 2 Machines: Order of Operations?

[wheel]

History on First Box ("Box 1"):

History on Second Box ("Box 2"):

 

 

Box 1's at 5.0.6: I'd held off on moving to 6+ until I had LSI cards, but I'm ready to roll with those cards in hand now. Box 2's at 6.3.5 and ready to upgrade so I can get better diagnostic info moving forward.

 

Box 1 just had a parity check complete late last night. Box 2 threw up 166k errors during its last parity check about a week ago on a disk that'd been improperly reconstructed due to read errors the the day prior, and no drives have been modified since.

 

I've identified all corrupted files on that 166k error disk, and can easily replace them after the upgrades, but haven't done anything to them yet. Planning to move cables from misread/error-causing disk if new diagnostics from upgraded Unraid can't provide a better idea of whether my read errors are coming from a bad drive or bad cabling.

 

Both boxes share the same UPS, so I'm planning to upgrade one box at a time for safety and feel like I should prioritize the v5 box (but wanted to check just to be sure that's a good call.).

 

From what I've read, 6.8.3 is a safe update considering the hardware I'm dealing with on both boxes, but if I'm making a wrong assumption there or it's safer to upgrade to a lower but more-stable/tested version, I'd love to know before locking in!

 

In light of all that, any suggestions on the best order in which to take the following steps would be greatly appreciated:

 

 

A: Upgrade Marvell cards to LSI on Box 1

 

B: Upgrade Unraid 5.0.6 to 6.8.3 on Box 1

 

C:Run NC Parity Check on Box 1 (step even needed?)

 

D:Run Correcting Parity Check on Box 2

(to get error count to zero since all files are replacable? step even needed?)

 

E: Upgrade Unraid 6.3.5 to 6.8.3 on Box 2

 

F: Run NC Parity Check on Box 2 (step even needed?)

 

(LAST STEP?): Move Cabling on Box 2 if New Diagnostics Don't Show Drive Faults; Run NC Parity Check Before Next Rebuild to Avoid Repeat of Corrupted Rebuild

Edited April 9, 2020 by wheel

[wheel]

Slight speed bump on the 6.3.5 to 6.4+ upgrade on Box 2 (decided to go ahead and take care of that one first):

 

Instructions say to install "Fix Common Problems" plugin. Couldn't find a direct URL or .plg in its forum thread, so in order to search for that, I tried adding Community Applications through the URL, but just got an error message that I need a higher version (6.4+) to install it.

 

Is there an easy way to get past this catch-22 and install an older version of Fix Common Problems that it sounds like I'll need to upgrade from 6.3.5 to 6.4+, and from there onto even newer versions of unraid?

 

Thanks in advance for any guidance!

[Squid]

In a nutshell, just go for the upgrade.  Review this thread though

 

https://forums.unraid.net/topic/66327-unraid-os-version-650-stable-release-update-notes/

 

You will not lose any data.

[wheel]

Thanks, Squid - reviewed the thread, got ready to upgrade, and the “Update Plugin” operation gave me two errors:

 

downloading: https://S3.amazonaws.com/dnld.lime-technology.com/stable/unRAIDServer-6.5.3-x86_64.zip ... failed (Invalid URL / Server error response)

 

downloading: https://S3.amazonaws.com/dnld.lime-technology.com/stable/unRAIDServer-6.5.3-x86_64.zip download failure (Invalid URL / Server error response)

 

Is there any way I can still upgrade 6.3.5 to 6.5.3 manually, and then upgrade further using the upgrade system from there?

[Squid]

You'll have to do the manual method.  Download the 6.8 zip file from limetech's website, and extract all of the bz* files within the archive onto your flash drive.

[wheel]

Ok, I’m about ready to do that (box array is stopped, moving/overwriting 6.8.3 bz* files to flash root) but wanted to make sure - is this magnitude of jump (6.3.5 to 6.8.3) something I can just do over SMB, or should I shut down the system, remove the flash drive, and manually add those bz* files to be safe?

 

Thanks again for the help!

[wheel]

Box 2 successfully upgraded to 6.8.3, I successfully upgraded a couple of 4TBs to 6TBs with clean parity checks after, and now I’ve hit a new headache.

 

I want to go ahead and upgrade my Parity Drive to 8TB for future failed disk replacements, but whenever I place my precleared (twice) WD 8TB in the hotswap cage slot which previously held my Box 2 Parity Disk and try to boot the system, it fails to boot (normal startup beep, four beeps that usually come after the hard drives are all read, and then the system seems to hang - never shows up as an attached device on my network).

 

When I replace that new 8TB Parity Drive with the old 6TB Parity Drive, the system boots fine. Is there a chance that the 8TB is messing up the boot order in some way, or is it more likely the jump from 6 to 8TB is blowing past my power supply? Or even just something weird with the disk despite finishing two preclears fine?

 

PSU is a CORSAIR Enthusiast Series TX650 650W ATX12V/EPS12V 80 PLUS BRONZE Certified Active PFC High Performance Power Supply; motherboard’s a SUPERMICRO MBD-X8SIL-F-O Xeon X3400 / L3400 / Core i3 series Dual LAN Micro ATX Server Board w/ Remote Management.

 

11 6TB drives, 8 4TB drives, a 6TB Parity, and a 1TB Cache.

 

edit: Going to be pretty difficult to source a monitor to see where the boot’s hanging, but probably not impossible if it’s my only hope.

 

I’ve attached diagnostics from the last successful boot (using the old 6TB Parity Drive) in case they help.

tower-diagnostics-20200416-0011.zip

Edited April 16, 2020 by wheel

[wheel]

Bummed a monitor off a neighbor, got into BIOS and changed boot order back to flash drive, unraid booted up fine, but the 8TB drive isn't showing up at all now as a possible parity replacement.

 

Edit: just ran ls -l /dev/disk/by-id and the 8TB isn't showing up in the list at all.

 

Edit 2: when I needed to swap the BIOS boot order, the new entry (that I swapped back to the flash drive) was "SAS: #0200 ID0E LUN", if that helps.

 

Edit 3: Confirmed the 8TB is fine - just threw it in a caddy on another system and all seems normal, with unraid 6.5.3 recognizing it as an unassigned drive.

 

Any ideas why the 8TB isn't showing up at all? The system's definitely interacting with the drive, if only by virtue of changing the boot order when it was installed vs. not.  Diagnostics from post-BIOS-change boot with 8TB drive in play attached.

tower-diagnostics-20200416-0854.zip

Edited April 16, 2020 by wheel