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:
Thanks @phillxnet
As far as I can see the stable channel updates require me to pay the 20GBP subscription and the license is based on my system ID. My government has just effectively just cancelled the entire basis of the industry I work in due to ‘the virus’. So as this is currently a testing platform for me and I haven’t yet settled on the hardware I want to use, the subscription cost isn’t feasible at the moment.
I’ll see what I can do about starting from scratch with the openSUSe build instructions you linked me to.
Thanks again.
This may be more skating to where the puck is going to be anyway and given your recent linux ventures may end up being quite approachable. Plus you get all the openSUSE/SuSE btrfs back-ports. Just remember to not create any shares on the system dive as that facility is currently broken and would anyway hamper your ability to easily re-install and import your data pool once we have our installer finalised and blessed by the openSUSE board for not infringing on their ‘marks’ (Trade marks).
Hope you manage this OK and do ask on the forum if you encounter any issues. I’d advise that you start a new forum thread however, that way once you are setup with a new testing install we can return to this one to continue the proposed Postgesql 9.5 Rock-on that @Hooverdan has already put time into.
@Hooverdan if you still fancy popping in a postgresql 9.5 Rock-on pull request we might have it ready by the time @AudioDan24 is back up and running again. Ideally we also need a quick and simple way to establish if it actually works. That way we can include this within the pull request as a proof of function step: given the usual Web-UI button is not going to server that function with such non Web-UI Rock-ons. The same might also help to finish off our outstanding Postgesql 10.6 Rock-on pull request and get that one merged as well.
Thank you @Hooverdan, much appreciated.
Sorry, my entire industry has just been demolished by our government in a matter of three days so I’m caught up with trying to find work. This will unfortunately have to go on the back-burner for me for now.
Thank you again for all your help.