After the upgrading from 6.12.13 to 6.12.14, my Unraid system would not respond, except to ping. Webgui wouldn't load, array and docker didn't appear to be online. Restarted a couple of times, logged in to the console and confirmed that the network was up, but webgui and array would not come up.

 

So I logged into Unraid Connect, downloaded the most recent backup zip file, created a new USB key with USB Creator and tried to restore the system. For some reason, the system ignored the network IP config entered in the USB Creator (and presumably present in the backup?), and resulted in the same condition: the restored system won't load the Webgui or start the array. I tried 3 times with the same outcome. Interestingly, the "restored" config is also 6.12.14. 

 

Finally, I created a USB Key with 6.12.14 without the backup file, and the system booted right up and loaded the Webgui. BUT, my config is completely gone.

 

It seems that there must be some driver or configuration in my system that is not compatible with 6.12.14. Can this be identified and eliminated from the USB Key created from the restore, so I can recover my system?

 

Thanks in advance.

tower-diagnostics-20250104-2040.zip

its important to make backups of the flash drive...

did you edit the go file?

Edited January 5, 20251 yr by bmartino1

Flash drive is missing files, recreate it using the stock install, then restore the config files you have, but you will likely still need to reconfigure some stuff.

9 hours ago, bmartino1 said:

did you edit the go file?

No.  Should I? What should be added/removed? There's not much there.

So, with a lot of trial-and-error, and I've found that if I create a stock install and copy everything from the backup config folder to the new install EXCEPT the super.dat

the system boots, and the webgui comes up!  However, all my disks are listed as unassigned.

 

What's the best course of action at this point?

 

If I reassign all of the disks to their original spot in the array, should everything come up as expected? Is there a log file (perhaps in the diagnostic zip?) that I could use to correlate the drives (by serial #) to their assigned location in the array?

 

Thanks,

Mark

I would probably check if auto-start is enabled, and if so disable it. It seems to be in disk.cfg (probably: startArray="no"), but since you have access to the webgui, you can just disable it there, restore your super.dat, and reboot.

I think super.dat contains your disk spec, and it would appear so on your experience.

 

> If I reassign all of the disks to their original spot in the array, should everything come up as expected?

Yes. But I would definitely mount as read only and not let in recreate the parity, but instead validate the parity is correct not writing corrections, at least for some gigabytes. I'm not quite sure what the options are. We wouldn't want it to overwrite your good data with parity if you mount incorrectly. You can mount the disks in read-only mode safely manually in a terminal if you so desire, to check the data is there.

If you only have one parity disk, the order of your array disks shouldn't matter for the parity. Though of cause it might very well matter for your shares, if some shares are on specific disks.

Do you have stored information elsewhere about which disks were array-disks and which were parity? Probably not... I checked my disks ids and I don't see them in my syslog.

Remember to check your syslog for disk errors before and after recreating the array.

Alex.

4 hours ago, mwf369 said:

EXCEPT the super.dat

super.dat contains your array disk assignments. You also need the pools folder from config for any pool configurations.

 

1 minute ago, trurl said:

super.dat contains your array disk assignments. You also need the pools folder from config for any pool configurations.

 

Much safer if you just copy it from the backup (assuming no assignment changes since backup was taken) instead of trying to reassign things.

On 1/5/2025 at 2:26 PM, Alex R. Berg said:

> If I reassign all of the disks to their original spot in the array, should everything come up as expected?

Yes. But I would definitely mount as read only and not let in recreate the parity, but instead validate the parity is correct not writing corrections, at least for some gigabytes. I'm not quite sure what the options are. We wouldn't want it to overwrite your good data with parity if you mount incorrectly. You can mount the disks in read-only mode safely manually in a terminal if you so desire, to check the data is there.

If you only have one parity disk, the order of your array disks shouldn't matter for the parity. Though of cause it might very well matter for your shares, if some shares are on specific disks.

I had notes on where the drives were assigned within Unraid, but was hoping to validate this from the config before recreating these assignments. Any time the old super.dat was included on the USB, the webgui wouldn'y load, so this was the best option. And it worked!

 

Thanks for your help.

Mark