Copying 32-bit unRAID configuration to new 64-bit unRAID flash drive

[trurl]

I wanted to start with a clean install of 64-bit unRAID to a new flash while keeping my disk assignments, share configurations, users, etc. but without any of the other stuff that might have accumulated on my 32-bit flash. After examining the contents of /boot/config, it looked like the following files would need to be copied. The descriptions of each file may be incomplete.

 

Text Files - things that are set from the webGUI

disk.cfg: Settings - Disk Settings and Device Settings for each disk

flash.cfg:  Device Settings for the flash

ident.cfg: Settings - Date and Time; Identification

network.cfg: Settings - Network Settings

share.cfg: Settings - Share Settings

passwd and smbpasswd : Users from GUI plus other users

 

shares folder: each share has a .cfg file

 

super.dat: not text but seems to contain the disk serial numbers.

 

I copied these to a new flash (with a new key) containing only the files in the unRAID 64-bit distribution. It almost worked and here's where I think I may have gone wrong.

 

Instead of shutting down and taking both flash drives to Windows to do the copying, I mounted the new flash in unRAID (with the array running) and copied there. Then I rebooted and selected the new flash to boot in the BIOS. Everything went just fine and all my configuration seems to be there, but it started a parity check.

 

I think something gets written, probably super.dat, when the array starts to indicate it is running, and then gets written again to indicate the array is stopped. I copied the file when it was running so unRAID thought it was restarting from an unclean shutdown. In fact, I think I remember reading about this on the forum.

 

This is probably all documented somewhere. Please elaborate, correct, or link to the documentation.

 

[graywolf]

super.dat contains your disk assignment information.

 

If you have a listing of your disk assignments. You just need to know which is parity, cache, unassigned.

Then with the 64-bit, you do your new config, assigning the disks accordingly and that will create the super.dat file

 

[trurl]

super.dat contains your disk assignment information.

 

If you have a listing of your disk assignments. You just need to know which is parity, cache, unassigned.

Then with the 64-bit, you do your new config, assigning the disks accordingly and that will create the super.dat file

And then I could have told it to trust parity and I could start the array.

 

But I would have had to recreate the users and share settings.

 

Instead, I copied super.dat and the cfg files I listed. Then I didn't have to assign or recreate anything. I think the only problem was copying super.dat while the array was running. Then when I rebooted it started the array as if it had been an unclean shutdown and began a parity check.

 

I let the parity check finish and it was a little faster than with 32bit. I plan to do more testing on that.

 

Thanks for confirming the role of super.dat in the disk assignments. Am I correct that it also tracks whether the array is started or stopped?

 

[graywolf]

not 100% but I'm pretty sure it does.

 

If you had stopped the array then copied the super.dat file then I doubt it would have gone into parity check.

[garycase]

... It almost worked ...

 

If everything worked and the only "issue" is that it started a parity check, I'd say it worked just fine.    Certainly doesn't hurt to do a parity check with the new version 

 

On the other hand, UnRAID clearly writes the shutdown status to the flash ... otherwise it wouldn't "know" when it boots whether or not the last shutdown was "clean".    I suspect you're correct that this info is written to super.dat => but it's certainly simple enough to check (just repeat the process, but shut down first; and include super.dat in the copied files).