Rockstor on ryzen

I built a config with a ryzen 7 2700 cpu and I tried to run rockstor on it.
I installed it first on an other machine with a supported cpu since the kernel in the installer does not support ryzen and I upgraded it to the most recent version. Then, I put the install disk in my ryzen build and I can boot on it but after choosing to boot on rockstor nothing happen and my screen is not receiving any signal.
My config:
Asus TUF B450 Gaming Plus
Ryzen 7 2700
2x8 GB Ballistix Sport LT 3000 MHz
XFX R9 380
Hope that someone can help me

Hi @Glotoven,

I had similar issues.
My build:

  • Ryzen 5 1600
  • MSI Mortar Arctic B20M
  • 2x8Gb non-descript random DDR4 ;o)
  • Cheapest damned graphics card I could find.

I was able to resolve it by following the same methodology, but performing the upgrade after swapping machines.
Installed using my Intel desktop with an older image (Rockstor-3.8.16.iso), moved the disk over to the Ryzen system, booted and then upgraded.

Give that a shot, and let us know how you go.
If that doesn’t take you anywhere, I would suggest instead installing OpenSuse manually with a BTRFS root partition, and then installing the Rockstor RPMs. @phillxnet can probably give you a leg up on this.

2 Likes

Ok, I did that and I’ve finally managed to boot on my ryzen machine with the older version of rockstor, but now when I try to enter the activation code to update the version, I get this error :
Capture

@Glotoven First off, a belated welcome to the Rockstor community.

Could you give us the output of the following command run as root on your Rockstor machine:

yum info rockstor

That way we can see the exact version you are on.

Thanks.

Thank you, here’s what I got:
2

@Glotoven Thanks for the info.

I’m assuming here no additional section and in which case their is no ‘available’ version. And this along with your reported stable channel activation issue point possibly to a network issue. I’ve seen Rockstor installs take a couple of reboots to get their network sorted when transferred from one machine to another. This is a rough edge we need to work on but if that is it then you may find that if you try a reboot or two and make sure to give the system time to sort itself out each time (a few minutes should do it) then it may just end up sorting your activation problem out.

To check relevant network connectivity to the Rockstor update servers, which use a non standard port, you can execute the following command:

wget http://updates.rockstor.com:8999/rockstor-testing/rockstor-3.9.1-16.x86_64.rpm

which should, if your connection is active and the 8999 port is not blocked by a firewall or the like (unlikely but we have seen this) produce output like the following:

...
Resolving updates.rockstor.com (updates.rockstor.com)... 157.230.16.221
Connecting to updates.rockstor.com (updates.rockstor.com)|157.230.16.221|:8999... connected.
HTTP request sent, awaiting response... 200 OK
Length: 15975840 (15M) [application/x-rpm]
Saving to: ‘rockstor-3.9.1-16.x86_64.rpm’

rockstor-3.9.1-16.x86_64.rpm                100%[===========================================================================================>]  15.24M  2.71MB/s    in 6.6s    

2019-11-11 11:31:09 (2.30 MB/s) - ‘rockstor-3.9.1-16.x86_64.rpm’ saved [15975840/15975840]

Your system is wanting to connect to the Stable updates repository during activation but this is the same but with authentication added and that doesn’t look to be the issue here as it would be reported as such.

So in short I’d first check that you have internet connectivity from within this ‘moved’ Rockstor install with the above wget command and once that is sorted, possibly by just rebooting and given the system time to reconfigure itself once or twice then try again to setup the stable channel subscription.

Then once successfully subscribed we have just one more hoop to jump through. As that install is old, more on this later, some certificates have changed in interim years. The Rockstor Web-UI doesn’t yet account for these. So once you have subscribed you will need to update via the command line:

yum update

It’s going to take ages as their are several hundred MB’s of updates. But should work in the end. I have recently tested an update from an older iso install (3.8.15.iso) up to latest stable 3.9.2-50 via this command line update, where you will be asked to accept a few new keys from named repositories, and although slow it did get their in the end. That was for another support requirement such as yours where they were only able to boot and install one of our older isos.

And so we have circled back around to our old isos and their later versions not being fit for purpose with newer hardware. If you are game I would like to contact you via PM to test a proposed new iso that is not quite ready for release but will be all the sooner with willing testers on newer problematic hardware such as you have here. Let me know and we can take it from their (open invite to all forum members also). I should have the first alpha iso of this type ready in a few days hopefully. But first things first is to get you up and running with our current offerings and from where you are now.

Please post any command output that doesn’t look right here and we can take it form their. Once this is sorted then you should from then on be good to just use the Web-UI to do the updates.

Thanks for you patience and let us know how the network issue goes, if all is well the reboots, auto re-config should short it and the ‘yum update’ with PGP keys accepted should get you up and running.

1 Like

Thank you for your help, I succeed in installing the last version of rockstor, but when it asked me to reboot to update the kernel, I get this error:
20191111_151833%5B271%5D
and when I try to uninstall the latest kernel with the command:
sudo yum remove kernel-4.12.4-1.el7.elrepo.x86_64
It says that there is no package marked for removal, but I can still boot from the previous kernel.

@Glotoven Thanks for the update and glad you got most of the way.

So can I assume that if you do:

yum info rockstor

it now shows that you have 3.9.2-50 installed?

If so then at least that bit is done.

Re the kernel panic, this is a shame. We have had a few folks whos machines just don’t like our unmodified elrepo kernel-ml without a fair bit of messing about you might be best sticking to this 4:10 kernel until we have our openSUSE Leap15.1 offering available. This will also have a 4:12 kernel but with very many backports, including the important curated btrfs ones.

You are likely unable to remove the 4:12 kernel as you appear to have not added the “-ml”. It may well be worth trying to re-install it. It may just be that something didn’t quite get setup correctly, the panic suggests that it just can’t find it’s root so it may be an initramfs issue.

To confirm what kernel packages the package manager thinks you have installed you can do:

yum list installed | grep kernel
kernel-ml.x86_64                   4.6.0-1.el7.elrepo             @anaconda/3   
kernel-ml.x86_64                   4.12.4-1.el7.elrepo            @rockstor     

Here on a 3.8.15 to 3.9.2-50 update referenced earlier I have a 4.6 and a 4.12, you should have a 4.10 and the same 4.12.

You could first ensure you are not running the kernel you are about to remove:
though yum does flag this if you try anyway “Skipping the running kernel: kernel-ml-4.12.4-1.el7.elrepo.x86_64”:

uname -a

Should show the 4.10 in your case.

And to remove your 4.12 variant (reinstall does want to do kernels it seems) you can do:

yum remove kernel-ml-4.12.4-1.el7.elrepo.x86_64

Note the ml in this name for main line.

yum remove kernel-ml-4.12.4-1.el7.elrepo.x86_64
Loaded plugins: changelog, fastestmirror
Resolving Dependencies
--> Running transaction check
---> Package kernel-ml.x86_64 0:4.12.4-1.el7.elrepo will be erased
--> Finished Dependency Resolution

Dependencies Resolved

==================================================================================================================================================================
 Package                              Arch                              Version                                        Repository                            Size
==================================================================================================================================================================
Removing:
 kernel-ml                            x86_64                            4.12.4-1.el7.elrepo                            @rockstor                            188 M

Transaction Summary
==================================================================================================================================================================
Remove  1 Package

Installed size: 188 M
Is this ok [y/N]: 

In this state, no 4:12 kernel, Rocsktor will complain within the Web-UI but it’s just a version check and so only cosmetic from the rocsktor package’s point of view. But best if we can get you on the 4:12 if possible as newer btrfs stuff hence the reinstall (remove install) suggestion.

yum update

Should pull the 4.12 kernel back in again.

And their after you should then have the 4:12 installed again visibly via:

yum list installed | grep kernel

Hope that helps and do keep in mind that removing and re-installing kernels is not without risk but given you have just gotten this running I’m assuming you have no data invested as of yet. The above worked for me on a test system.

Hope that helps and well done getting this far. Not a smooth ride but do let me know if you are up for testing our pending alpha iso? My hope is, it being much newer, that it should be much smoother on the newer hardware.

1 Like