I Just performed upgrade from version 7.3.1 to 7.3.4. After the upgrade reboot, the server does not recognize the attached USB hard drives (which make up the array).  It lists them as missing.  The disks are seen by the server as Unassigned Disk Devices, however one of the disks mount buttons is grayed out indicating that there might be a problem with the disk (was running fine prior to the upgrade). Should I roll the upgrade back to the prior version or is there a way to fix this?

This is due to a Linux kernel package update, and one of the reasons USB is not recommended for array or pools, it happened before, and it may happen again. To fix it, you can do a new config and reassign the disks to their original positions, check "parity is already valid" before array start, if you need help with the assignments, post the diagnostics.

2 minutes ago, JorgeB said:

This is due to a Linux kernel package update, and one of the reasons USB is not recommended for array or pools, it happened before, and it may happen again. To fix it, you can do a new config and reassign the disks to their original positions, check "parity is already valid" before array start, if you need help with the assignments, post the diagnostics.

Thank you, the diagnostics are attached, I'm not sure I understand what you mean when you say create a new config (sorry if this is a dumb question). I was unaware that using USB disks was not recomended.

scotttower-diagnostics-20261102-1150.zip

Not a dumb question at all. The disks and your data are fine. With this release the drives now report the serial of the disk inside the USB enclosure instead of the enclosure's own ID. Unraid identifies array disks by that ID, so it thinks the original disks are missing. "New Config" just resets the array assignments so you can assign the same disks again under their new names. It doesn't touch the data on the disks.

From the diagnostics, the correct assignments are:

Parity: WDC_WD60NDZW-11C8XS0_WD-WXA2D850TY6J (sdb)

Disk 1: WDC_WD60NDZW-11C8XS0_WD-WXA2D850TLSN (sdc)

Disk 2: WDC_WD60NDZW-11C8XS0_WD-WX92D8564NLF (sda)

Steps:

• Don't mount any of these disks with Unassigned Devices, and don't format anything.

• Go to Tools > New Config. You can leave "Preserve current assignments" at None, since you don't have any pools. Check "Yes, I want to do this", click Apply, then Done.

• Go to the Main page. All array slots are now empty. Using the dropdowns, assign the disks exactly as listed above. Leave Parity 2 and Disk 3 unassigned. The slot count of 5 is normal, because it includes both parity slots.

• Before starting the array, check the "Parity is already valid" box next to the Start button, then start the array.

• Disk 1 and Disk 2 should mount normally with all your data. If either shows as unmountable, stop the array and post new diagnostics before doing anything else.

Going back to 7.3.1 would change the IDs back to the old format, so you would need to repeat this procedure. It's better to stay on 7.3.4.

Also, Disk 1 is currently connected at USB 2.0 speed. If possible, move it to a USB 3 port, otherwise parity checks will be much slower.

Thank you so much! Your help/mentoring is greatly appreciated.

After starting the array (started successfully), I am now getting a message that my boot drive is corrupted or offline...

When I try to pull a Diagnostics, I keep getting a "Lets Finish Setting Up UnRaid" screen.

I keep "Skipping Setup", but the screen keeps popping up.

That typically means there's a problem with the flash drive, you can try to check the system on it or create it (save a backup, recreate using the USB tool, restore only the config folder from the backup, overwriting existing files), also save the diagnostics, but I'm about to go offline for the day, I'll check again tomorrow if no one else helps first.

So... That screen prevents me from stopping the array normally or accessing the console. Is there a best way to bring the array down, to check the drive?

So... I ended up having to bring the server down hard (pulled the plug) and then tested the USB stick. It was dead... So I formatted a new USB stick and recovered the 7.3.1 backup onto that new disk. Then I had to transfer the license onto this new Stick. The array came back online but it did trigger a parity check (which I am OK with it completing). So as of now, I am back at version 7.3.1 with everything working.

My question is, if I do the upgrade again, can I expect to experience the same issues? Will I lose the disk assignments? Can I expect to have an issue with the new USB Stick? The old USB was tested before I did the upgrade (brought the system down, took the USB stick and plugged it into a Windows computer. It mounted and did not report any errors or issues), It may be a coincidence with the USB stick failure but I am a bit gun shy right now...

Glad you got it back up and running.

Losing the flash drive right after the upgrade is most likely just bad luck. The upgrade and the array start only write a few small files to the flash drive, and flash drives can fail without warning. Mounting it on a Windows computer only shows that the files can be read. It doesn't test the flash memory, so it would not have found a failing drive. There's no reason to expect a problem with the new flash drive.

The disk assignments are a different matter. Because you restored the 7.3.1 backup, the array config uses the old USB enclosure IDs again. So yes, when you upgrade to 7.3.4 or newer, the disks will show as missing again. Your data is safe, and the fix is the same as before. It should only be needed once, because later releases will keep the new IDs.

When you want to upgrade:

- Let the current parity check finish. It should find 0 errors. If it finds any, post new diagnostics before upgrading.

- Make a new flash backup (Main > Boot Device > Flash > Flash Backup), so you have a backup of the new flash drive.

- Upgrade to 7.3.4 and reboot.

- Go to Tools > New Config, apply it, then assign the same disks as before, by serial number:

Parity: the disk ending in TY6J

Disk 1: the disk ending in TLSN

Disk 2: the disk ending in 4NLF

- Check "Parity is already valid", then start the array.

If anything looks different from this, stop and post the diagnostics before going on.

7 hours ago, FJRpilot said:

Can I expect to have an issue with the new USB Stick?

No, you should not expect issues with a new stick, provided it is a high quality, reliable drive specifically chosen for the job.

However modern consumer USB drives fail at an alarming rate in Unraid.

I'd advise getting a true industrial grade drive, such as an Innodisk 3ME, rather than a standard retail stick:

https://forums.unraid.net/topic/199642-psa-on-industrial-mlc-usb-boot-drives-mlc-nand-end-of-life-and-last-accessible-stock/

@JorgeB , thanks again for your help with this. I completed the steps that you indicated, and my server is back up and running on version 7.3.4. I just wanted to add some information in case there are any additional steps I should take.

After creating the new config and starting the array, I felt it was prudent to grab another backup of the Boot flash. So, I started that process and waited for it to finish. 30 minutes later the process was still running, and I never saw the file download to my workstation. The Web interface had locked up (Unable to initiate a shutdown) and my shares were all off-line which I thought indicated the server may have been out of sorts. I accessed the console, logged into it and looked to see what might be happening (Top and lsof). I saw that the Flash backup appeared to be hung and decided to initiate a "Powerdown" to reboot the server (see attached). One of the steps that was taken was the system stopping the "flash-backup" process (it had not finished).

The server restarted, I logged in and restarted the array. Everything appears to be running normally now but I have not yet taken a new backup of the Boot flash, opting to wait until you had a chance to read this email and respond if appropriate.

One thing to note, I looked in Disk1 /system and noticed that there were 7 boot flash backup zip files (including the one that I thought had hung). Is this expected?

Thanks again for your help, it is greatly appreciated.

Glad it's all back up on 7.3.4.

The server wasn't actually hung, the backup was just taking a very long time. On 7.3.x, when there isn't enough free RAM, the boot backup is created in the "system" share on the array. It's built in many steps, and each step rewrites the whole zip file (about 1.3GB) again. With all array disks on USB, and disk1 on a USB 2.0 port, that can take a very long time. While it runs, the GUI keeps waiting for it to finish, so it looks frozen. The reboot was fine.

About the files in disk1/system: these are backups that were never downloaded. The zip is only deleted after the browser downloads it. You can delete all of them:

- The six 7.3.0/7.3.1 backups from June. They are from the old flash drive and you no longer need them.

- The 7.3.4 backup from today. It was interrupted, so it's incomplete.

- The zix487JB file. It's a partial temp file left by the interrupted backup.

For a backup now, the simplest and fastest way is to shut down the server, connect the flash drive to your computer and copy all the files to a folder there, then put it back and boot. You only need to do this again after a config change or an OS update. This should be better in Unraid 7.4, since the boot backup is streamed directly to your browser instead of being created on the array first.

Also, if a parity check started after that reboot, let it finish, it should find 0 errors.

Thanks again for this explanation. I will try to be more patient. I have a second server running 7.3.4 and it’s Boot-flash backups take less then a few minutes (also running USB disks), so that’s why I got impatient.

Once again, thanks for your help and mentoring.