Installing Rockstor 4 onto old PC with OpenSUSE server

1

I’m writing a guide I wish I had found before.
So you don’t have to bang your head against the wall as I did.

The adventure I’ve faced, step by step:

  1. Before doing anything: DISCONNECT your disk drives. You don’t want any accident of mistake damaging your precious data. Leave only one disk or ssh or flash reserved for booting the operating system and that’s all! Seriously: disconnect your precious data before starting!

  2. Rockstor can be installed from a pendrive, which is the most usual and popular way. However, you can also install the operating system and install Rockstor as a regular application on top of it. I strongly prefer the second option since I definitely prefer to have full control of what I’m installing, why I’m installing and how I’m installing.

  3. In any case, as it is so common to virtually all NAS software around, burning a pendrive and installing from it seems to be the no-brainer choice, which would abbreviate my learning curve and my efforts. At least, that was what I’ve thought.

  4. I couldn’t be more wrong than that. Long story short: despite all my efforts and tweaks in the BIOS, I was not able to install Rockstor into my old ASROCK Fatal1ty Killer board, which is serving my home well for 10 years now with its 32Gb of RAM.

  5. OK. Back to the original idea. Let’s install OpenSUSE from scratch. I actually use OpenSUSE as main driver in my primary laptop… which is a joy… and which led me to Rockstar in the first place.

  6. Download the full installation ISO from the link below and prepare a pendrive with it.

https://mirrorcache.opensuse.org/download/distribution/leap/15.3/iso/openSUSE-Leap-15.3-3-DVD-x86_64-Media.iso

  1. The installation of OpenSUSE is pretty straightforward, which can be found easily on YouTube. There are only three crucial aspects to be observed, as I explain below:

6.1 Apparently (since I’m not 100% sure about it!) Rockstar requires NetworkManager. The “problem” is that OpenSUSE does not install it by default. You have to be extremely careful when you are installing OpenSUSE and read every single line of the pre-installation report which is presented just before you smash the big green button with a fateful [Install] written on it. If you do not change anything, OpenSUSE will install Wicked instead of NetworkManager. So, make sure you explicitly tell OpenSUSE installer to choose NetworkManager instead.

6.2. Do select a “Server” install. Do not select a “Transactional Server” install, since Rockstor does not work in this case, unfortunately.

6.3. Do not install any graphical environment. You don’t need that in a NAS. You will have Rockstor, right? Also, it takes precious time and chances are that you will get things wrong and will have to repeat the entire thing many times. You can always install a graphical environment later, if you really need. So, leave it for another time and save time now.

  1. Have I mentioned networking? Obviously your server will need access to the internet. Make sure that the OpenSUSE installer is able to obtain a valid IP address, is able to configure online repositories, etc.

  2. Let your system reboot for your first boot.

  3. Login as root and perform the tasks as I explain before:

9.1. Install etckeeper

$ sudo zypper install etckeeper
$ sudo etckeeper init

This is a neat way to keep track of changes in your /etc.
It is a glorified git repository (but could be mercurial or any other) for your /etc, which allows you rolling back mistakes, saving precious time reinstalling all over again from the pendrive and everything already explained above.

9.2. Install fail2ban and your preferred text editor.

$ sudo zypper install fail2ban zile nano vim

Fail2ban is absolutely mandatory everywhere you have an OpenSSH server. Better safe than sorry. Just install it. Period!

Choose your preferred text editor. Mine is zile, so I install only zile and I ignore nano and vim.

  1. Update the kernel

Just copy the lines below and execute them as root:

$ sudo zypper --non-interactive addrepo --refresh https://download.opensuse.org/repositories/Kernel:/stable:/Backport/standard/ Kernel_stable_Backport

$ sudo zypper --non-interactive addrepo --refresh https://download.opensuse.org/repositories/filesystems/15.3/ filesystems

$ sudo zypper --non-interactive --gpg-auto-import-keys refresh

$ sudo zypper update --no-recommends --allow-vendor-change

  1. Reboot.

  2. Now it’s time to install Rockstor on top of OpenSUSE with a recent kernel.

Just copy the lines below and execute them as root, accepting the key, ignoring not certified repositories (otherwise nothing happens!):

$ sudo zypper addrepo https://download.opensuse.org/repositories/shells/openSUSE_Leap_15.3/shells.repo

$ sudo zypper addrepo -f http://updates.rockstor.com:8999/rockstor-testing/leap/15.3/ Rockstor-Testing

$ sudo zypper --non-interactive --gpg-auto-import-keys refresh

$ sudo zypper install rockstor

  1. Reboot

  2. If everything went according to plan, you will be greeted with Rockstor GUI by browsing to the IP address of your new NAS box.

==========

Now the real adventure begins:

You will observe that you don’t have any storage defined in Rockstor. Yeah… it is obvious, since you had disconnected all your disk arrays before you’ve started. Try to reconnect only one array, one which could be sacrificed in case you make something really wrong and lose the entire array. See if Rockstor can recognize it.

From my experience, I had to reboot my computer before Rockstor was able to see the physical disks I’ve reconnected. Even in this case, Rockstor was able to see the disks, but not the disk array which they form.

Since my “guinea pig” disk array is ext4, I’ve just mounted it by hand, creating an entry for it in my /etc/fstab. Rockstor was able to see it after that. No reboot needed.

But stop!

This is where my knowledge reaches its limits and I cannot help you without risking your data.
I’m sure you can find valuable help in this forum.

I hope it helps.

Long life to your data with Rockstor! :slight_smile:

1 Like
2

@rgomes Welcome to the Rockstor community.

Nice, and thanks for sharing your findings.

However in what way was our similar (official) guide on the Downloads page insufficient:

I.e. the
“Built on openSUSE Rpm” section.
Subtitled: Install on Vanilla openSUSE/SuSE SLES

and:

We actually base our installer on a JeOS openSUSE build “Just enough Operating System” so it’s actually fairly small when done, i.e. no manuals etc.
Plus if you wish to create a custom package set for the isntaller you can always just edit these and build your own installer via the instructions here:

That’s a shame. If you report your findings in an issue in the above installer repo we may be able to get that sorted. We use the openSUSE kiwi-ng installer builder so we should be able to sort whatever. We do have a known and as yet unresolved issue with some uefi systems issued (with a around) here:

Or was your issue more video related, and in which case maybe the following would have helped:

Yes, it’s great that we always have this fallback and we have tried to stick as closely to upstream as possible for this and many other reasons. Hence basing our package selection etc on their JeOS appliance builds.

Correct, as indicated on our Downloads page instructions referenced above.

I think this is only for server installs but not absolutely certain. I think for desktop/laptop they favour NetworkManager. I think they may move to NetworkManager across-the-board by default in time.

Yes, the Transactional Sever option is very different. Read-only root is quite the change/set of changes. We may get there in time however!

That’s a new one on me. Cheers. But not required for Rockstor mind :).

We normally install nano actually within our installer. It was one of the compromises we made above the minimum of JeOS. It’s my favourite cli editor anyway.

I’d like to have this integrated in Rockstor in time, with a Web-UI component.

N.B. we have a how-to for this, see:
Installing the Stable Kernel Backport
And it should be noted that this is more than a kernel update, it is moving outside of the generic Leap 15.3 setup and carries non trivial risks as a result. All hopefully clarified in that HowTo hopefully. Give that a look at let us know what you think.

I would prefer for folks to follow our official guide on this front actually. Same sort of ball park though.

But to be a little more careful here, in case anyone fails to look at our official doc: I would say to honour at least:

zypper in --no-recommends rockstor-4.1.0-0

It’s our last stable version of the rockstor rpm that we duplicate (exactly) in the testing channel. Otherwise you get the latest testing which will soon likely be broken in multiple ways as we move towards the next stable version.

You may well have found “Refresh” button press in the Disk overview page would have surficed.

Thanks @rgomes that was a good read. And quite interesting. Had you not seen our Downloads guide for doing the same? Note that you will also need to disable AppArmor (I know, read the disclaimer there). We are getting there. And a concerted effort on that front shouldn’t be that much effort all in, once establishing all that we do with AppArmour we can carry the necessary definitions and work well along side it. Always lots to do and our move from CentOS to openSUSE (Rockstor 3.x to 4.x) was quite the effort and has left us with a little more backlog than we had before. Oh well, in time.

Yes, we are stickly btrfs only and only recognise btrfs-raid. But only from the Web-UI perspective. Below that we are neat openSUSE so then anything goes. But bigger stuff like multi-path and LVM etc will potentially massively confuse Rockstor so take care on those fronts and in trying to shoe horn other filesystems into the Web-UI. We are at a very low level concerned only with btrfs pools and subvolumes.

Thanks again for sharing your adventure. Take a look at the links I posted above as there are some caveats you may not have been aware of. Plus it would be good to have more eyes on these docs: as always. All the website and docs and all code including installer builder are open source and on GitHub so pull requests welcome. There are always errors or emissions so key an eye out.

Way to go with your first post here. Cheers.

Plus, lets see if we can’t narrow down your installer issue. First try opening a new thread on what went wrong as we may be able to narrow it down here on the forum before creating a focused and narrow issue in the installer repo. I’m due to build new installers soon hopefully, as they then have all pending updates pre-installed, and we have some minor improvements lined up in the issues. Also hoping the suspected upstream UEFI boot for some systems is fixed now.

Hope that helps to you too. ;).

3 Likes
3

Hi Philip,

Thanks a lot for you kind message.

Answering your questions about documentation:

I’ve first tried the simpler alternative, playing by the book. But that failed due to my old hardware. Then, I’ve decided to do something which I was willing to do in the first place: just install Rockstor on top of openSUSE server. However, I was not able to find such documentation. I found bits and pieces in one article, some more bits and pieces in another place, and so on… until I’ve condensated everything into a simple shell script. I’m an “old school” guy who believes that there’s no better documentation than a shell script.

I’m aware that there are several scenarios and there are even two Linux distributions involved. So, the effort of keeping high quality documentation is far from being a trivial task.

Answering your question about hardware:

Someone else, i.e.: the openSUSE team, already did an excellent job creating an installation process which detects all sorts of hardware, old and new, enterprise grade or commodity. OpenSuse was able to recognize my hardware without any trouble, which is plenty enough for my purposes. Then, I was able to install Rockstor on top of openSUSE. Perfect! That’s all I need.

IMHO, the big “mistake” several other NAS solutions fall into is forcing users into this process of burning a proprietary ISO which contains whatever it is. No, I don’t want that. I want the original distribution and then I decide what I do next. All this process involving downloading an ISO, burning a pendrive, backing up your current stuff, installing a new ISO over some existing stuff… all of that is just a big waste of time. I don’t need that. If Rockstar is capable of being installed via package manager (and it is!)… then… that’s all I need. That’s perfect to me.

I hope this paragraph below, even though off-topic, can be useful somehow:

I was trying OpenMediaVault before, which “installs just fine” on top of Debian. But… why then I left OMV behind? Answer: Because OMV is intrusive and “tries to help me without my consent”. The problem is that OMV fails to help me, causing me troubles instead. So, in the end, OMV caused me troubles without my consent, which is unacceptable.

Correct, as indicated on our Downloads page instructions referenced above.

Yes, I’ve read this in the documentation, but I think it vanished in the middle of several other things I’ve read. My problem, and I mean “my problem”! … is that I expect a concise shell script as documentation.

Yes, the Transactional Sever option is very different. Read-only root is quite the change/set of changes. We may get there in time however!

I guess that support for transactional server is a requirement only for those running transactional servers, necessarily. Similar results can be accomplished by snapshoting, using snapper.

[etckeeper] That’s a new one on me. Cheers. But not required for Rockstor mind :).

True. etckeeper is a nice complement to snapshoting, but not a requirement.

I’d like to have this integrated in Rockstor in time, with a Web-UI component.

Yes, the user decides whether or not a component is desirable.

N.B. we have a how-to for this, see:
Installing the Stable Kernel Backport

As I said… I’ve stumbled onto this article too. But “my problem” is that I was expecting to find a shell script which “does it all for me”. Out of topic, but I have lots of shell scripts which “do it all for me” at http://github.com/frgomes/bash-scripts

I would prefer for folks to follow our official guide on this front actually. Same sort of ball park though.

It is not my intent to provoke confusion.

zypper in --no-recommends rockstor-4.1.0-0

Shouldn’t it be zypper install --no-recommends rockstor ? without any specific version? Zypper should pick the latest, isn’t it?

You may well have found “Refresh” button press in the Disk overview page would have surficed.

I’ve tried that, and some other things too, until I’ve finally resorted to a reboot. No idea why it didn’t work.

Thanks @rgomes that was a good read. And quite interesting. Had you not seen our Downloads guide for doing the same?

The difficulty I’ve found with the documentation is that it jumps from one page to another without putting a conclusion to the matter. I definitely understand that there are several things involved, from burning ISOs to nuances post-installation. But the point is: IMHO, it should be something linear and self-contained. I mean:

Lets’s say that there are 5 flavors of installation:

  1. From an ISO with JeOS
  2. On top of an existing openSUSE 15.3
  3. On top of an existing openSUSE Tumbleeweed
  4. From ISO with CentOS
  5. On top on an existing CentOS 8

OK. In this case, you need 6 pages: one initial page which tells how many options we have. Then N pages which detail each option in a single page which is self contained, without distractions, without jumping to other topics.

Notice that “my option” was “On top of existing openSUSE 15.3 server”, which is not listed above.

Given that I was not able to find this option anywhere, I’ve decided to contribute, or hopefully contribute, with one.

Yes, we are stickly btrfs only and only recognise btrfs-raid. But only from the Web-UI perspective. Below that we are neat openSUSE so then anything goes. But bigger stuff like multi-path and LVM etc will potentially massively confuse Rockstor so take care on those fronts…

Yes. I’m converting 2 arrays to btrfs but one I will leave as ext4 for the time being. I’m actually newbie to btrfs and so… it will take me some experimentation until I find the proper layout of subvolumes (and how to snapshot them!) which satisfies my purposes. Thanks for the advice about mdadm not being directly supported, etc.

Plus, lets see if we can’t narrow down your installer issue. First try opening a new thread on what went wrong as we may be able to narrow it down here on the forum before creating a focused and narrow issue in the installer repo.

Thanks a lot for your kind offer, but installing on top of an existing openSUSE was my preferred choice since the beginning, really. I’ve tried the ISO install in order to shorten my learning curve. It didn’t.

Once again, thanks a lot anyway :slight_smile:
Cheers

3 Likes