New here...Just thought I'd better say hello

User Stories
1

A new Rockstor user from south UK here.

My history with NAS is so far quite limited. Five years ago I bought my first NAS box - a single drive WD My Cloud 3TB. I plugged it in, set it up and have had to do nothing to it apart from firmware updates since then. It just works, and has successfully stored music, videos, photos and documents etc without missing a beat. Switching off the built-in Twonky DLNA server improved its performance significantly (it’s a dual core ARM with 256MB RAM).

That reliability is all I need from a NAS really, I run Logitech Media Server and Jellyfin from Raspberry Pi devices very successfully and I like it like that. I’m a big Pi fan to be honest. Also, I don’t want a NAS that I need to keep logging into via the WebGUI or SSH to keep having to check things - I just want it to work for me and my family of six so we can rely on it to store stuff without fuss or bother.

However, I want and need something more solid, with redundancy (and yes, I have effective backups too).

I’ve been through the usual suspects of OpenSource NAS software solutions, and kept coming back to Rockstor. This is currently on an old reliable AMD64 box, but I have plans afoot.

So now I’ve just moved to Stable after a while of Testing, and look forward to what’s ahead.

I’m still learning, and look forward to more of that.

For me Rockstor is definitely a Rockstar.

2 Likes
2

@GeoffA Welcome to the Rockstor community, and thanks for your support.
Re:

Did you know that our release candidates of Rockstor 4 are now Arm64 compatible? We don’t yet have downloads available for Rockstor 4 versions yet but there is a Pi4 target on our DIY installer builder and we have a call out for tester of this new installer Recipe here:

And once installed it should be able to update it’s self via our official testing and stable channels. Although we have yet to populate the Stable channel but we are up to RC (Release Candidate) 3:

Just a thought. In case you fancy testing that or our regular x86_64 installer profile. Hopefully soon we will have downloads available but they in turn will be build via this repo/method so it may be of interest. We do have an outstanding Arm64 Rock-on issue to address, so if you do try the arm variant, along with Rock-ons, you will have to check each Rock-on before install for Arm64 (aarch64) compatibility, though many are already.

https://github.com/rockstor/rockstor-core/issues/2191

Only Pi4 unfortunately as we are not that light (but not that heavy either), and the Pi4 is very much quicker than it’s direct predecessor the Pi3.

Thanks again for the intro and the support.

3

@phillxnet Thanks for the kind welcome!

Funny you should mention about the Rockstor 4 on Pi. I did follow those instructions and built it on a Pi4, however the resulting .raw file would not boot the Pi4 (either from SD card or USB SSD boot). I didn’t get/notice any error messages during the build process, and Leap 15.2 was installed successfully on the same Pi4 4GB for the installer build.
I would love to have R4 running on a Pi4 to test it out, and might have another go this weekend if I get some time. I will take more notice of the build output screen as it progresses, to see if I missed anything obvious.

Cheers

Geoff

4

@GeoffA Thanks for the feedback.

I’ll give it another go here as when last I tried it worked surprisingly well. I’m fairly new to the Arm64/Pi4 land and was expecting it to work a fair bit slower than it actually did.

Great. Thanks. I’ve got a couple of issues and hopefully another Rockstor 4 RC to get done before I’ll have time to have another go. But if you ended up with the .raw then at least the installer ran as expected and to it’s conclusion. The Pi4 I used to build and test this profile on worked with the micro-sd card in the slot directly, and with the same card in a micro-sd-to-usb adapter. But for the latter I had to copy over the required disk based firmware files for the Pi4 to enable it’s USB boot capability. It’s internal boot eeprom had already been updated to enable the USB boot via the Rasberry Pi OS. Which is were I also got the updated firmware files.

Great that you had a go, thanks. And if you do get to have another go, there may have been a regression from when I last tried it that is hopefully fixed now: kiwi-ng, our installer build system, is super active.

Super. And for details of what exactly happened during a build you can look in the

/home/kiwi-images/build/image-root.log

file. But if you got the *.raw file and it was around 4.9 GB then it’s likely completed successfully.

Should boot without modification once transferred to an sdcard. I used something like:

dd bs=4M if=Rockstor-Leap15.2-RaspberryPi4.aarch64-4.0.0-0.raw of=/dev/sdX status=progress conv=fsync

As per the openSUSE Leap images except without the decompression as they are build with the same kiwi-ng tool I believe. I’ll double check this when I next try it out. Your File name will likely vary here though depending on if you edit the *.kiwi file or not.

Also take a note of this transfer method. Note that you will have to have a monitor attached to the Pi4 to run through the initial setup of selecting language, keyboard, setting keyboard etc.

If you do get around to this start a new forum thread so we can gather what’s going on and hopefully either improve the docs on this or track down when it started failing. We could really do with more testers on the Pi4 really to catch these potential regression.

I’ll have another go myself soon once I’ve got a little more back log towards the next release done.

Thanks again for the testing and feedback. I was quite exited to get a working Pi4 installer so it’s a shame it’s not worked in this case. More info I think and we can sort out what’s gone awry. Hopefully we just need better docs.

1 Like
5

@GeoffA Just had another thought.

I’m pretty sure, from memory, that the openSUSE Leap 15.2 Pi4 images don’t use btrfs, and so may well not have those packages installed. And we have had a more recent report of image pre failure right at the last moment because of a missing gfxboot, we are awaiting a pr on this very find (in part).
So before you do the build next time ensure you install these before executing the kiwi:

btrfsprogs gfxboot

I think the regular x86_64 installs include both of these packages due to the differing default from the Arm64/Pi4 images from the Leap 15.2 host. We found this out very recently with a failed vagrant based install that similarly doesn’t use btrfs by default.

So in short where the readme previously stated:

sudo zypper install python3-kiwi

Add the potentially missing in Vagrant images and (from my flaky memory) Pi4 Leap15.2 images, the two required for successful build:

sudo zypper install python3-kiwi btrfsprogs

Appologies for not updated the docs with this find. As stated @mikemonkers had some issues with builds in some vagrant boxes and this came up. And more recently I re-did the build server and found that we also failed to specify the required gfxboot program, but this is x86_64 only.

I’ve now, as a result of you jogging my memory, opened the following issue in our installer repo:

I’m pretty sure this was why your *.raw failed to boot. Me @erisler and @mikemonkers all came across this in various build scenarios so pretty confident that at least could explain our docs failure.

Let us know how you get on. I’ll try and update the docs on this one soon.

Thanks.

1 Like
6

Obviously I couldn’t wait for the weekend to try this again, you know how it is.
So whilst on a work conference call (ahem) I decided to try the original .raw file one more time before rebuilding afresh and using all your excellent advice above - but this time using the latest Balena Etcher writer on my Peppermint Linux laptop.

Again, .raw image (mine reports at 5.2GB in size) successfully written to SD Card.

And… BINGO! Currently running Rockstor 4.0.2-0 on my Pi4. Clearly an issue with the writing to SD card was the issue. I’d used the built-in Peppermint USB image writer without issues before. Yes, maybe I should be brave and use dd.

So, although there is obviously an issue with uninstalled btrfsprogs and gfxboot for some, this does not appear to have been the issue in my case.

Really appreciate all your input and advice @phillxnet. I’m both annoyed and relieved it was something so simple, totally unconnected to the juicy build process and dependancies etc.

I will investigate trying the USB SSD boot, which is my preferred method, at the weekend and report back.

For now, Im going to enjoy setting up a test Rockstor 4 NAS on my Pi4.
Thanks so much!
Cheers
Geoff

2 Likes
7

@GeoffA Re:

Nice.

Yes, and I’ve now fixed that in the readme so that’s another one sorted. And you mention of boot failure definitely jogged my memory on updating the doc re those apps.

No worries. turned out to be very helpful all around. We have had similar issues with certain image writers on the x86_64 side as well.

Thanks for your report and well done on being one of the first to build and test our Pi4 installer. I’m actually unreasonably exited by having this as an official target profile so your feedback has been gratifying and encouraging.

Cheers.

8

Is there a formal thread on here for reporting back findings? I’m very new here and still finding my way around, but am keen to provide whatever feedback I can for my Pi4 findings, and the x86_64 build too when I get to it.

Cheers

9

@GeoffA Re:

Not really. Ideally you want to start a focused thread on a specific issue or feature request. And once that can be clarified (if need be) and a reproducer found (if it’s a bug say) then it’s moved to a GitHub Issue where folks can tackle them if and when they have time. But it’s always good to state the exact version of Rocsktor you are using and how it was installed: i.e. via your own installer or a downloaded one. But as evident from this thread things can take a wild path, and to good effect, so we don’t really enforce any form of formality on the forum as such. Although the Announcement posts are generally read one as they are formal references. We also have the Wiki area which is mainly for developer docs / notes and each thread there states it’s intended audience.

Hope that helps. And keep in mind that we don’t yet have a filter on which Rock-ons are Arm64 compatible so make sure to follow each docker image link before trying to install it. If an Arm64 version is available in that image it is expected to behave identically to the x86_64 variant. If not then it it’s install will fail and may requires some intervention to fix.

And thanks again for stepping up for some testing. All good and crucial to identifying and fixing what ever issues are outstanding or newly created. And the activity on the forum helps to assess when it’s a good time to release another Stable version. Hopefully getting close to the next one now.