Hi,
what is the recommended procedure to upgrade from an existing 3.9 stable to 4 ?
Does that always amount to a fresh install or how do i take data and configuration across.
My installation is on a Gen10 HP Microserver with a separate 128G system disk, and multiple data pools.
Best regards
Tobias
Welcome to Rockstor @twermann
The journey from 3.9 to 4 is a fresh install and the underlying Linux distros are different (CentOS for v3 vs opensuse for v4).
However there is no official v4 installer available yet, but you can build your own from the latest beta version:
I have gone through this build before: it is quite straightforward.
Your existing v3.9 data pools and config can be imported into v4. I trust you have effective and current data backups. When installing v4, I’d suggest a fresh target disk, and disconnect all the data pools. After install is complete, shutdown, reconnect data drives and reboot.
Good luck!
3 Likes
Hi,
thanks, its a bit of a rocky road.
when trying to build the image on a OpenSuse Leap15.2 on WSL from the Microsoft app store, building the raw image fails with
KiwiCommandNotFound: Command “qemu-img” not found in the environment
So switching over to a Leap15.2 on VirtualBox.
On VirtualBox i can build the image, put it on a USB stick and start the install.
However in the middle of the install, the screen turns black - no further messages and no visible response to the keyboard.
Alt-CTR-Return restarts the machine, it starts booting from HD but same result, the screen ends up blank and unresponsive except for ALT-CTR-Return.
I dont know how to capture the boot messages, but this is the last i could see on the screen:
This is regardless of the boot choice normal/failsafe.
The Machine is a Gen10 HP Microserver (Opteron), has been running 3.9 with a 4.10 kernel with no issues.
Vanilla Leap15.2 installs/boots with no problems.
Best regards
Tobias
@twermann Hello again.
Re:
Great, that’s actually quite a few hurdles over and done with. Do consider helping others with this process if you see question on this come up on the forum.
We have had another report of what looks / sounds exactly like this. I don’t think it’s yet been posted publicly on the forum but calling @rockstoruser77github I think it was who reported and resolved a similar problem with regard to a failed vga output during install on their N54L microserver. I believe they resorted to using a doner machine to install Rockstor to a USB device and then moved this over to their microserver. @rockstoruser77github if you could correct me on this that would be grand.
Esentially the installer doesn’t know who to use that VGA output and will likely need some custom kernel options to make it work as expected. If someone could chip in with these then we may be able to offer a custom install target within our DIY rockstor-installer config for this rather popular line of servers.
So if you search generally for linux on Gen10 HP Microserver you may find some appropriate kernel command line optinos that make the VGA output behave properly.
Do report back your findings and hopefully we can, in time, add this as a note on the installer config or as a known hardware target.
Hope that helps.
1 Like
Hi, thanks for the hint with the kernel options, I will check that out and update.
1 Like
switching to EFI boot from legacy, i now get to more meaningful messages in the boot sequence:
and there seem to be known issues with some kernels, then again this is an integrated GPU on the Opteron.
https://bugzilla.opensuse.org/show_bug.cgi?id=1168611
finally, booting with kernel parameter “nomodeset” worked.
4 Likes
Nice spot and fix. Don’t you just hate it when things that should be so straightforward, aren’t?
Anyway, glad you are on the road now. Look forward to hearing further findings from you.
2 Likes
I’ve recently hit a problem with expired certificates on 3.9 so it looks like I need to make the leap.
I can see how to create a new boot device and then boot up with the current disks/pools attached but is there anyway to migrate the current config; users, access rights, etc., or do I need to recreate all of those from scratch?
Sorry if this is the wrong thread to add this but this seemed most relevant to moving from an existing 3.9 to 4.1.
Thanks.
You should have the ability to run a backup configuration that you can then reimport here:
Don’t know at which 3.9.x level it was introduced, but if you have it, it should work to create the backup, download it outside of Rockstor, and after installing 4.x, use the same menu item to upload the config file and you should get your settings/users, etc. back.
I think, if you have custom rock-ons, the json files you want to place back on the new install (and refresh) so that they show available, if there is an entry in your backup file. Don’t remember right now, whether this is correct or not.
2 Likes
That’s great thanks.
Not sure how I missed that but I’m going to blame age.
1 Like
@jmangan Hello there.
I’ll jump in with an additional note that actually relates to @Hooverdan’s reports on a bug he found in the config restore which has now been fixed by @Flox in 4.1.0-0. So make sure to be updated to at least that version before you do a restore.
See the 4.1.0-0 release notes here:
This version is essentially the first v4 stable but currently not in the Stable channel as I’m giving it a day or two to see if we’ve missed any show-stoppers. But likely this will also appear in the stable channel exactly as-is very soon. In the mean time, with caution to the changelog displayed within the Web-UI, you can get this from testing. But be warned that we are about to start the next testing phase and so testing rpms will again be broken very soon as we update the entirety of Django and then Python with all the inevitable bugs that are likely with code wide changes such as this.
Hope that helps.
2 Likes
Everything has pretty much been said but I just wanted to link to the relevant section of our documentation:
https://rockstor.com/docs/howtos/reinstall.html
Now that Rockstor 4 is the non-legacy version so you can skip to the “Data import” section as mentioned.
They most important bit here is to attempt reassuring your configuration backup after importing your disk(s).
Of course let us know if anything is unclear in these docs and we’ll do our best to clarify and improve them!
2 Likes
I’d also make sure you have current effective data backup(s)… just in case.
Been there, got the t-shirt - unfortunately 
That was long ago with another system.
2 Likes