Set up Rockstor some time ago, but haven’t used my NAS server very much so it’s running an old version which has been upgraded about 2 or 3 times. I have two RAID 1 arrays, each has a two physical 3TB hard disks. Rockstor is installed on a separate drive (Sandisk USB memoryStick)
The last time I switched it on, it failed to boot the latest installed version:
Rockstor (4.6.0-1.e17.elrepo.x86_64) 3 (Core) with debugging
It wouldn’t boot with the previous version:
Rockstor (4.4.5-1.e17.elrepo.x86_64) 3 (Core) with debugging
Rockstor (4.4.5-1.e17.elrepo.x86_64) 3 (Core)
But luckily it did boot with an earlier version:
Rockstor (4.3.3-1.e17.elrepo.x86_64) 3 (Core)
I was able to log on to the web dashboard, and enable the Samba shares which has allowed me to access the two RAID1 shares, and make an additional backup of most of my data. But the web dashboard is showing the warning:
You are running an unsupported kernel(4.3.3-1.el7.elrepo.x86_64). Some features may not work properly. Please reboot and the system will automatically boot using the supported kernel(4.6.0-1.el7.elrepo.x86_64)
I did buy support for one year some time ago, but never managed to get it upgraded past 4.6.0-1
Would I be able to build a new Rockstor install on a new boot disk, install this on my server, and be able to import my two RAID1 arrays retaining the data?
I can only export the configuration while it is running the oldest version 4.3.3-1, so am not sure if this configuration backup would be ok to use?
Would a new Rockstor install need a backup of the configuration to find /identify the two RAID1 arrays?
You pools should import just find. And if not then details what happened if they don’t here on the forum so we can advise how we might the that sorted. We haven’t had an outright failure yet, but there have been a number of hick-ups, mainly concerning quotas and large pools, or poorly pools of course.
Nice.
Thanks, and lets see if we can get you up and running on the new v4. Loads of improvements, under the hood mainly but still.
Back then there was far less saved in this config backup. But all that is saved should be restored OK.
Be sure to first update to 4.1.0-0 before you try the config import though.
No. In fact you would import the pool before doing the config restore. But again that’s a super old config save so take some good notes on your current critical parts of the config, just in case. But the pool import will also import the shares and snapshots. You may only need to recreate the shares and set up Rock-ons again if you use them, but I’m not sure we even had a working rock-on system then. And for a while the Rock-ons would fail to start after a reboot anyway. Rough times back then.
Main point of caution is to ensure you dont’ accidentally install to a data drive. That would be bad. You could even detach all data drives so that it is impossible to make a mistake. The you can do all updates and install the 4.1.0-0 etc and then after shutting down once all has settled re-attach the data drives and then power on to do the import and config restore. Although you may want to just setup from scratch if it’s a fairly simple install.
Install is far faster these days so theres that.
Hope that helps.
Also look to this recent forum post for a similar question asked recently:
I know some probably think I’m getting a bit boring now (but it won’t stop me), but do you have a current backup of your data before upgrading. You never know…
Thank you for the comprehensive reply to my query. I wasn’t using my NAS very often so as it was working as a simple network storage I was happy leaving it at the last successful upgrade. I don’t believe I am using any Rockons, but am interested in setting up Plex on it at a later date.
Having read your answers, I will remove all the disks from my Nas (which is an old HP Gen7 N54L Microserver) and use a new disk to set up a new Rockstor install, then insert the 4 Raid disks and see if it finds the 2 Raid1 arrays…
Would I better off just connecting the first 2 disks making up one of the two RAID1 arrays, checking that works ok, and then connecting and importing the last 2 disks making up the second RAID1 array?
Hello Geoff, I have copied the majority of my files to other disks on my Windows PC, but haven’t used any backup software as such. So there is a slight risk as I don’t know how well Windows verifies file copies compared to decent backup software, but I have copied the most important files to two different disks.
Sounds like a plan. Be sure to fully update the install to get 4.1.0-0 before you do the final shutdown before the drive re-attachment.
This is likely why you had such difficulty during the install last and had to jump back to a really old version of Rockstor to complete a successful install.
You may have to add a custom kernel boot option to get around quirks in this hardware. But it should be doable. Just take care to note or photograph down any error messages you get during the install if it doesn’t go as per the How-to: https://rockstor.com/docs/installation/installer-howto.html
That way folks here on the forum can advise what may be needed to get this install done and the resulting install booting as intended.
Not really as you will only be importing one btrfs volume (btrfs raid array) or Pool in Rockstor speak anyway. Just given the system time to settle between each import. But we have to get the install sorted first of course.
I can chip in on this one:
It doesn’t.
Nice. And given you have used btrfs raid1 in both pools you also have two independent devices each with a checksummed copy within each pool. We just need to get the install sorted to get to them .
I’m totally with you there. It doesn’t matter whether you use formal backup software or a simple copy and paste process, the key thing is that you have copies of the files you want to keep safe.
By the way, I use regular rsync cron jobs (nightly and weekly) to create my backups to 2 different devices. I also have an online backup.
Sorry for the late update on this thread. But thanks to Phil and Geoff’s help it looks like after some final editing today I have regained access to my data on my Rockstor server, though the installation may have some issues. Server is an older HP N54L Microserver.
I did initially create a USB bootable media, the install went through but then it seemed to crash after restarting the server with some strange graphics appearing on the screen. I left it at that point, did some reading, but didn’t return to trying again until this morning!
I read the link “Upgrade Path from 3.9 to 4?” which suggested booting with kernel parameter “nomodeset”. Initially I managed to temporarily add this in, by selecting the 'E’dit option on the Rockstor boot menu, and it continued booting and I was later able to access the Webgui and set up new account and password details.
I then looked into how to set and save this nomodeset parameter option to the default boot, and ended up opening a System shell from the Webgui, and editing the etc/default/grub file with sudoedit.
The grub file has a comment about running “grub2-mkconfig -o /boot/grub2/grub.cfg” if changes where made, but I wasn’t able to do this, probably due to my lack of knowledge. I had to google a few sites to learn how you saved the file from sudoedit!!
After checking the changes made to etc/default/grub had been saved, rebooting and checking I could log into the Webgui, I then powered off and connected my 4 data drives (2 x Raid 1 pools). Powered on and the disks were shown ok, and I was able to click the “down arrow” icon by them to import them in. Then set up the Samba service and Samba shares and can now connect to the Shares and see the files from a Windows PC.
The only query I have now is - I have the “nomodeset” option set, but the screen on my HP server is still showing some weird characters / graphics after booting up. Do I need to worry about this, and also do I need to run the suggested command “grub2-mkconfig -o /boot/grub2/grub.cfg”?
Nice to see we work, with a little messing about, on at least your version of an old HP Gen7 N54L Microserver
You can tell what options were presented to a running kernel by the following command run as the root user:
cat /proc/cmdline
If you nomodeset is in the output then you are done with that being implemented and grub is applying it as expected. Otherwise, assuming the edit in in place and correct, the mkconfig command run as root should assert this in subsequent boots.
I have seen corrupted boot messages and their consequent log entries before with bad RAM but yours look different in that they are only affecting a specific title component of the boot message. I.e. only the service names are being scrambled.
Let us know who you get on with this. Otherwise, if it’s not bad RAM then you are good to leave this as an inconvenience as it may well be cosmetic only. But a pain as you then can’t see the service names.
As @GeoffA mentions, we may just have an additional quirk here of interfacting with these particular machines. Would be nice to track down thought.
I don’t think I saw any funny characters on the console when booting at the end. (I don’t have a console connected to the machine which is buried away now in a cupboard.)
