One thing I have been thinking of lately with a test box is how you go about jumping between versions to test, for myself would be more to test hardware compatibility?

 

I have my unRaid 4.7 basic box running, everything is good. Make a backup of the USB key to a Win client for instance. Then follow procedures to upgrade to version 5b6a (for instance). Everything works, great. Things meltdown, boo! But, in theory, I then wipe out the USB drive, put the version 4.7 backup of the key I made, reboot and I am back at 4.7 and things "should" be ok?

I am assuming I make 0 changes to disks or disk config while jumping between versions. Should this be ok to jump back and forth for testing, more to make sure things like my Raid card are supported, new version sees disks, even if the are MBR unrecognized and such. Can fall back to 4.7 and I am good.

 

Or, do I assume, and this is why I do it on the TEST box, I do the upgrade, something goes wacky and therefore screwed? Even going back to 4.7 won't help?

 

Just wondering what ways and procedures some of you guys use for jumping back and forth between versions to test out things.

 

Thanks!

Shawn

 

Your procedure looks good. Except that versions after 5.0b4 have been reported to destroy data.

You just change the bzimage and bzroot files to change versions.

 

If you don't want to do the device re-assigning and parity build/check each time then also make a copy of the config folder for each version. I'd just do it on the flash. Changing from 4.7, rename the config, bzimage and bzroot to include -4.7 on the end of the names. Then copy the config-4.7 folder to a new folder just called config and also put the new bzimage and bzroot on the flash. To go back to 4.7 just rename the config, bzimage and bzroot to have -5.0b6a on the end and then remove the -4.7 from the others.

 

One thing to note - you can't make changes to the array like add disks when you are keeping copies of the config folder. If you added a drive in 4.7 then you could not just re-use the config folder from 5.0b6a where the drive didn't exist.

 

Peter

Your procedure looks good. Except that versions after 5.0b4 have been reported to destroy data.

Not entirely true.  (It just looks like data is lost in some situations)

 

The 5.0b5 release would replace a non-standard MBR on a disk with a standard one starting at sector 64.  This would make it impossible to mount an existing disk that had a partition starting on sector 63, making it look like the data was lost.   As soon as the original MBR was replaced, the data was accessible once more.

 

The 5.0b6 release will not start automatically, and will show you which disks seem to have a non-standard MBR (if any) so you can fix the non-standard MBR, and report its current state before fixing it to lime-tech so 5.0beta7 can get smarter.   As long as you do NOT start the array, no MBR partitioning will be overwritten.

 

Both releases (5.0b6 and 5.0b6) apparently would restore a cache drive to a single partition if they currently have multiple partitions.  Again, the data is not "really" lost, if the disk is re-partitioned it is accessible once more.

You just change the bzimage and bzroot files to change versions.

 

If you don't want to do the device re-assigning and parity build/check each time then also make a copy of the config folder for each version. I'd just do it on the flash. Changing from 4.7, rename the config, bzimage and bzroot to include -4.7 on the end of the names. Then copy the config-4.7 folder to a new folder just called config and also put the new bzimage and bzroot on the flash. To go back to 4.7 just rename the config, bzimage and bzroot to have -5.0b6a on the end and then remove the -4.7 from the others.

 

One thing to note - you can't make changes to the array like add disks when you are keeping copies of the config folder. If you added a drive in 4.7 then you could not just re-use the config folder from 5.0b6a where the drive didn't exist.

 

Peter

 

Thanks! And I think I got you on the note. If I had gone back to 4.7, added a disk, I would then need to re-do the "5bxx" config folder from a copy of the updated 4.7 config folder to get the changes.

 

I assume I can "jump" to my 5b6a config and then update to b7 when it comes out, make updated copy of the config.5b7 folder and fall back to 4.7 if I need to...

 

Shawn