If you install the ISO 3.9.1-0 select Stable Channel updates and apply them you should end up 3.9.2-55 as of writing this.
If you are only hosting the database on Rockstor then it will make now difference. That is another element of docker, it abstracts the underlying operating system. As to running DaVinci Resolve itself you can do this on what ever OS you choose. But I’m assuming you wern’t going to run this on Rockstor itself but a client machine.
Separation of concerns is always a good thing really.
OK, so this may well be where our slightly newer but still old elrepo kernel doesn’t agree with your hardware. We have seen it where the 4.10 kernel works but the 4.12 doesn’t. In which case the soon to be released Built on openSUSE variant may be more your ticket as it has a tone of backports that our 4.12 mainline form elrepo doesn’t. So folks who have this kernel issue after updating have simply selected the older kernel. But given that is a backwards step and it’s best to move forward I’d say keep an eye on our openSUSE version, which is incidentaly available in our current testing branch. But that is a lot more technical to get up and running, at least until we have our new ISO installer released.
No worries. It looks like you are being hampered by a kernel update which I hadn’t picked up on before. These can be pretty tricky and leave you with the following options:
1: Different hardware and upgrade a current Rockstor ISO to Stable.
2: Jump on our current Testing Channel via a Leap15.1 install: technically challenging but not that bad. However this is not intended for end users just yet; hence the following threads title:
I wouldn’t worry about this knowledge not being transferable. There is a great deal of overlap between the various linux distributions. And Rockstor is aiming to be very much an appliance distribution anyway so the distro we use is mostly irrelevant to the end user, especially if they resource only the Rock-ons. And there are really only 3 enterprise linux distros anyway RedHad/CentOS, Ubuntu, and SuSE/openSUSE. Of which only the latter user btrfs by default and employ the majority of the btrfs developers. This means they are the most aggressive with the btrfs backports.
Let us know what you fancy doing and if you do fancy a walk on the wild side with our “Build on openSUSE” testing channel variant, which may not suffer from the kernel issues you have just mentioned, then look to the following forum thread:
Hope that helps.