Rockstor 4 Installer Recipe - call for beta testers

Announcements
29

I’ll be able to answer that one: Yes, what you are looking for is the “Config Backup & Restore” feature:
http://rockstor.com/docs/config_backup/config_backup.html#configuration-backup-and-restore

As of 3.9.2-52, rock-ons are included in the config backup and will be re-installed with the same settings upon Restore. All details should be explained in the documentation above, but feel free to have a look at the corresponding PR for a demonstration, for instance:
https://github.com/rockstor/rockstor-core/pull/2100

It is important to note, however, that because all rock-ons depend on the same shares as those present in the backup, one needs to import pools and shares (as you did) before restoring the config backup. Note also that restoring rock-ons can take some time depending on how many are to be restored, as the procedure equals to re-installing all the rock-ons that were installed at the time of the config backup. As a result, make sure to give it a few minutes to propagate.

Hope this helps, and let us know if you have any other question.

2 Likes
30

That’s brilliant, thanks. It helps a great deal.

1 Like
31

I just built the installer image put it on an USB stick and installed rockstor from it. Had no major issues.

As I don’t have a openSuse system, I used docker. That was not completely straight forward, but it worked eventually. Here are the commands I used for anyone interested:

# Important part here is the --privileged flag which is required to make mount --bind /proc ... work
docker run --privileged -it --mount src=/home/marenz/projects/rockstor-installer,target=/rockstor,type=bind opensuse/leap:15.2

zypper addrepo http://download.opensuse.org/repositories/Virtualization:/Appliances:/Builder/openSUSE_Leap_15.2/ appliance-builder

zypper install python3-kiwi btrfsprogs gfxboot

cd /rockstor
kiwi-ng --profile=Leap15.2.x86_64 --type oem system build --description ./ --target-dir installers/

Thank you for the hard work. Will experiment a bit with it.

A few things I noticed in the WebInterface:

  • I had the already known error message about some javascript db problem which had no real effects and I think it was gone after a hard-refresh
  • Upon enabling services (SMB, NFS), the “enable” switch was not centered after I clicked on it but was then again centered later.
  • Enabling Rock-ons first didn’t work. With that I mean, I clicked the switch, it showed the “processing” animation but then stayed on “off”. After a second try it worked.
  • When editing a user that has /bin/nologin as shell, in the edit mask it shows /bin/bash . If you don’t change anything and go back it is still bin/nologin in the overview.
    Tiny details like that make it feel a bit unpolished. But none of those are actual problems…

I am now gonna try to setup jellyfin as a rock-on. Will report my progress (if interest?)

Another detail: I still had the usb stick attached for installing and in the rockstor log I constantly see this error:

[08/Jan/2021 19:49:22] ERROR [storageadmin.views.disk:461] Error running a command. cmd = /usr/sbin/smartctl --info /dev/disk/by-id/usb-Kingston_DataTraveler_2.0_6CF049E31FC2BD4039440109-0:0. rc = 1. stdout = ['smartctl 7.0 2019-05-21 r4917 [x86_64-linux-5.3.18-lp152.57-default] (SUSE RPM)', 'Copyright (C) 2002-18, Bruce Allen, Christian Franke, www.smartmontools.org', '', '/dev/disk/by-id/usb-Kingston_DataTraveler_2.0_6CF049E31FC2BD4039440109-0:0: Unknown USB bridge [0x0951:0x1665 (0x100)]', 'Please specify device type with the -d option.', '', 'Use smartctl -h to get a usage summary', '', '']. stderr = ['']
Traceback (most recent call last):
  File "/opt/rockstor/src/rockstor/storageadmin/views/disk.py", line 458, in _update_disk_state
    do.name, do.smart_options
  File "/opt/rockstor/src/rockstor/system/smart.py", line 338, in available
    [SMART, "--info"] + get_dev_options(device, custom_options)
  File "/opt/rockstor/src/rockstor/system/osi.py", line 198, in run_command
    raise CommandException(cmd, out, err, rc)
CommandException: Error running a command. cmd = /usr/sbin/smartctl --info /dev/disk/by-id/usb-Kingston_DataTraveler_2.0_6CF049E31FC2BD4039440109-0:0. rc = 1. stdout = ['smartctl 7.0 2019-05-21 r4917 [x86_64-linux-5.3.18-lp152.57-default] (SUSE RPM)', 'Copyright (C) 2002-18, Bruce Allen, Christian Franke, www.smartmontools.org', '', '/dev/disk/by-id/usb-Kingston_DataTraveler_2.0_6CF049E31FC2BD4039440109-0:0: Unknown USB bridge [0x0951:0x1665 (0x100)]', 'Please specify device type with the -d option.', '', 'Use smartctl -h to get a usage summary', '', '']. stderr = ['']
1 Like
33

@Marenz Hello again.
Re:

That’s a good start at least :).

The alternative vagrant/virtualbox based method contributed by @mikemonkers may have been easier than using docker I suspect:

Thanks for sharing your docker approach here, interesting. The kiwi-ng system actually has a build in virtualisation function now so it may be useful overall to try and move to that in our instructions. But it’s still a little new and I like that we use the core kiwi-ng functionality only currently.

Yes, there is an annoying lag in the switches some times. They appear to get stuck for a bit. This I think is long standing and likely a low level javascript issue that we may be able to fix by updating our dependencies. But we may end up getting more that is broken so holding off on that until we have our os transition in place.

OK, again this may be down to delay, we need to revamp hole elements of our UI really but all in good time. We should keep an eye on this one however.

Could you make a GitHub issue for that in our rockstor-core repo. That way we have attribution which is always good. I’ve not noticed this one myself.

Agreed. We do want to get to all these paper cuts in the end and we hope to do some of the already identified ones before the next stable release. But as always it’s down to resources and we are rather short on those. Developer time/attention is a major shortage actually. So if you fancy taking a look at any of these then that would be great. But getting all we can in clearly defined GitHub issues with clear reliable reproducers is the start of this.

Yes, all reports are welcome. Though best to report in a dedicateed thread with an indication of the exact version of Rockstor you are running. I.e. 4.0.4 or the just released 4.0.5 which has quite a few changes in comparison to prior releases.

Yes, this is a limitation of smrtmontools and it’s ability to ‘read’ the device. Many USB sticks have incomplete smart support. The message is harmless but we do have a doc guide on -d options you can try:

http://rockstor.com/docs/smart/smart.html#disk-custom-s-m-a-r-t-options

It has and example of this exact error message as it’s very common with USB sticks that have partial support or need a -d option to be properly recognised. Many will simply not work with smart no matter what options you put in.

Thanks for the detailed feedback. And agreed we have lots of paper cuts, but far fewer than we use to have and we have transitioned to a more appropriate OS in the interim so once that process is done we can settle down to dealing with all the reports as and when developer time/attention is available.

Hope that helps.

1 Like
34

So, after a few days I wanted to tinker again with the system but had to discover that it was unbootable. I suspect the reason is that it is formatted with GPT (I believe I’ve read something like that in the boot process messages the first time) and the system is too old to understand GPT…

It did boot after the installation but not again after. I did try a re-install just now and have the same behavior.

Thinking about using a normal Leap installation and adding the sources now…

1 Like
35

Although I’m unfortunately won’t be able to provide you with expertise on GPT, I might be able to help with the following:

If you prefer, you can also install the rpm rather than building from sources. See the post below for help:

2 Likes
36

For what it’s worth, it was not due to GPT. A normal leap install with GPT worked.

1 Like
37

Thanks for the hint. I used the RPM on top of my leap install now :slight_smile:

38

I’m new to Rockstor and was running the Centos 3.9.1 ISO for a day before I decided to try to build a 4.0.4 ISO as described in the top post. First I did a server install of Suse Leap 15.2 and used kiwi-ng to build an iso. With my new built iso I did a new install of Rockstor 4.0.4-0 and it running nicely.
A big thanks to all doing a great job of developing Rockstor. :+1:

3 Likes
39

I forgot to say “knock on woods”. I just got a problem:
Error setting up e-mail alerts
:crazy_face:

2 Likes
40

I installed today; after a couple of ‘practice runs’ installing to a separate drive, I installed to the boot drive. I imported from one of the drives that had been part of my RAID1 pool under v3 and it worked like a champ: the pool and share were recreated. All I had to do was recreate the user that I want to own the share and recreate the the SAMBA share.
Bottom line is that it was really as smooth as can you could ask for given that the OS is being ripped out from underneath it.

3 Likes
41

Looking forward to use Rockstor because of its simple setup for Nextcloud, Wordpress-sites in addition to the BTRFS Features. If its working as intended i may want to test Rockstor for production-use aswell. Most of my hardware is running Proxmox, except my Firewall-Server.

Questions:
Are there any known issues / tweaks with Rockstor & Proxmox ?
Is AES-NI capability needed / does Rockstor use it?

42

@DigitEgal Welcome to the Rockstor community.

Try posting this question:

in it’s own thread. That way it may catch the eye of folks more easily. This forum thread is predominantly about the installer recipe.

Hope that helps.

43

Hi,

I’ve taken the plunge, with new 2242 nvme SSD which arrived today, which I can screw down properly to the MB, and installed 4.0.7 (from my kiwi built ISO CD) having first disconnected my data drives.

Install seems really smooth, although looks like memtest86+ is not added to the ISO build by kiwi

I then re-connected the data drives and imported the disks/pools/shares, and then restored config from the back-up I’d made before I started. I started the restore around 40 minutes ago, and so far only Plex seems to be re-installed (I had NextCloud, JellyFin, Subsonic and Syncthing installed as well.)

Would you expect it to have done by now?
I was only evaluating JellyFin and Subsonic, but I do need Nextcloud and Syncthing back.

1 Like
44

I started a new topic for this, Hope that’s ok

45

Hi @HarryHUK,

I’ll try to be helpful in your other thread that you created more recently, but I wanted to address the point below in case it helps future readers who may have the same question:

It all depends on the number of Rock-ons to restore, but yes, I would expect it to not take 40 mins in most cases, at least. This is simply due to the fact that the procedure to restore Rock-ons goes through the re-installation of all Rock-ons that were installed at the time the config was backed-up. Thus, the procedure should take about the same time as if you were re-installing your Rock-ons yourself one by one. This means that if it normally takes x mins to install Rock-ons A and B on your system (minus all user interactions through the installation wizard, of course), it should also take x mins to restore a config backup were Rock-ons A and B were installed. Note that it needs to pull (most likely) the underlying Docker images again, extract them, etc… so that’s why it can take quite some time for those using quite a few Rock-ons and/or Rock-ons with large underlying images.

2 Likes
46

@HarryHUK Hello again.
I can chip in on this one:

See the upstream issue in kiwi-ng’s GitHub repo on this:

Hope that helps

2 Likes
47

I found my Rockstor 3.9.1 CD and ran memtest till around 42% (30 minutes?)
No errors till that point.
I might run it again and leave it longer but I think the memory is fine.

48

I appreciate it takes time, but the nature of the failure meant there was no indication on the UI it had failed. I had forgotten there was normally good progress indication.

Once I had rolled back docker and tried again, I could see nice feedback on progress.

3 Likes
49

@HarryHUK Hello again.
Re:

Yes, you really need 2 run of 100% to be fairly sure. Often a ram failure will only be ‘spotted’ by a single test. And the 100% means all tests have been run on all the memory. Otherwise you’ve likely only run less than half the tests on all the memory.

It does take ages, but can be reassuring. Note however that it will run for ever so theirs that.

Glad you’ve gotten the docker rollback sorted. Bit of a pain that and we are planning to ‘sort’ this soon hopefully. One way or another.

Hope that helps.

3 Likes