How to Install onto Raspberry Pi 4?

Hi, is there anywhere a step by step guide on how to install Rockstor onto a Raspberry Pi 4?

I have went to the download section and seen the installer for the PI is a Raw.xz file. I am not sure what to do with that.

Do I just use something like BalanaEtcher and write this Raw.XZ file to a microsd card and boot the pi from it. Or do I need to do something else entirely?

Sorry if this is an obvious/simple question but I genuinely was not sure what to do.

@AnthGood welcome to the Rockstor Community. I believe, @GeoffA has successfully done an installation on a Pi4, so I’m sure he can give some insights if he has time.

But yes, you would create a self-bootable microSD card from which to boot the system using the Raw.xz file. I have not used BalanaEtcher, but, yes, I believe, that should work.


Hi @AnthGood welcome to the world of Rockstor.
Yes, get that Pi image file and simply burn it to a micro SD card. My favourite is to use Balena Etcher.
Then boot the Pi4 with that card.
Make sure you have a screen and keyboard attached to the Pi for the installation process.
It’s very straight forward.
Come back here with any questions or queries, I’m glad to help.


@AnthGood I’d like to just chip in on @Hooverdan’s and @GeoffA’s instructions here:

For the downloads we, as you mention, have a raw.zx file and on the downloads page we given linux instructions to burn it to a system disk. But note that those instructions include an unzipping element.

I’m not sure if BalanaEtcher does this automatically. But it is required that the image burned to the proposed sdcard is not the compressed one you down load, but the multi-GB result of uncompromising the download first. From the downloads page we have:

Image Test: sha256sum -c Rockstor-Leap15.3-RaspberryPi4.aarch64-4.1.0-0.raw.xz.sha256
Transfer to (sdX): xzcat Rockstor-Leap15.3-RaspberryPi4.aarch64-4.1.0-0.raw.xz | dd bs=4M of=/dev/sdX iflag=fullblock conv=notrunc status=progress

And there the linux command first un xz’ed the image then burns it to the sdcard.

Just wanted to clarify that bit. Also it would be good to know if BalanaEtcher does this automatically as we could then add this to that download section if that is a common program to do this in the ‘other’ OS’s.

Cheers. And apologies if I’m just adding noise here.


I’m afraid I’m stumped on the Raspberry Pi 4 installation, as well. I’m trying to install Rockstor 4 to test the updated MinIO Rock-on. I have tried on two different Pi4s, two different SD cards, and burned the RaspberryPi4 image on both Linux (with dd) and Windows (with Balena Etcher). With a USB-3.3V interface connected to the UART header pins, I can see the boot messages. In every case, I get as far as:

[ 46.266774] Bluetooth: hci0: BCM4345C0
[ 46.270581] Bluetooth: hci0: BCM4345C0 (003.001.025) build 0000
[ 46.280151] Bluetooth: hci0: BCM4345C0 ‘brcm/BCM4345C0.hcd’ Patch

and the boot hangs. I’ve left it for hours and it never proceeds.

I thought maybe I needed to have a USB drive plugged in, so I added a USB3 SSD to the mix. Now it gets past the Bluetooth section but ends up endlessly resetting the SSD. I suspect this may be the UAS problem I see referenced in lots of places, but I can’t figure out how to get past it.

I’m out of ideas and could really use some help, please.

Thanks. Mike

@MikeMcPherson Hello there.

So that’s strange as I tested it here on my Pi4 and all seemed to be OK. Are you using an external monitor as that is what is expected. Regarding the image transfer I noted the command to use on the download page:
so it should be:

Image Test: sha256sum -c Rockstor-Leap15.3-RaspberryPi4.aarch64-4.1.0-0.raw.xz.sha256
Transfer to (sdX): xzcat Rockstor-Leap15.3-RaspberryPi4.aarch64-4.1.0-0.raw.xz | dd bs=4M of=/dev/sdX iflag=fullblock conv=notrunc status=progress

I’ve not tested it without an hdmi and only using a serial conection.

Also note that it should boot from the same image transferred to a USB stick, assuming the firmware on the Pi4 is new enough.

Let us know how you get on. And if anyone else could chip in here with some ideas then great.
In fact maybe the firmware needing to be upgraded may be it. As my test Pi4 did have this done, quite some time ago now, when they first enabled the ability to boot from USB devices.

Hope that helps.


Thanks, Philip. I updated the firmware on both Pi4s to the latest. I tried an external HDMI monitor and keyboard, but never saw a thing on the screen. And that is exactly the dd command I used.

I’ll try a USB stick and report back.


1 Like

First mystery solved. I had a bad micro-HDMI adapter that was damaging the on-board connector, bending one of the shield fingers and causing a short. Fortunately, it doesn’t seem to have done any permanent damage. Bending the shield finger back where it belongs and replacing the adapter got the video working again and Rockstor booted.

Now I’m wresting with a different issue: no Web interface. I’m seeing a bunch of NGINX error messages about “rockstor.cert”. Trying to track it down.



Bingo! My second problem was self-inflicted: I made the mistake of following the directions in the MOTD and used zypper to update the system. That was a bad idea!

So, with a good HDMI adapter that doesn’t try to break the socket, and with a clean install of Rockstor, the server came up with no problem.

And the MinIO Rock-on works perfectly!

Thanks for your help. Mike


@MikeMcPherson Thanks for the detailed reporting here and glad you tracked down the various issues. That hdmi cable potentially damaging the Pi4 socket was not a good show.

But re:


That MOTD is our own, and intentional, from here:

I want to maintain this compatibility with command line update as it’s all we do in the background anyway.

However I’ve recently suspected, from some reporting in this area, that an nginx update is upsetting things with one of our now deprecated ssl settings. I’ve not yet looked into this but you may have hit on this. Or we have an issue whereby a reboot is required if a command line update is performed before first setup. Should be an easy fix once we have it narrowed down. I.e. we simply use this file for our config:

And we have seen an ssl config deprecation warning that should be addressed as a Stable update if that is in fact what is breaking the Web-UI. Food for thought and investigation. I’ve not yet experienced this myself but have been a little distracted of late with some behind the scenes responsibilities.

Thanks again for the reporting and for proving the function of your newly submitted MinIO Rock-on fixes. Much appreciated.


@MikeMcPherson Hello again.

Just done a full update on an already setup install and we look to be OK on the nginx front. So it may just be we need a:

A reboot may be required after updating.

or something; added to the MOTD.

The directive I mentioned that is deprecated but still used by us generates the following message:

2022/05/04 16:58:14 [warn] 6532#6532: the "ssl" directive is deprecated, use the "listen ... ssl" directive instead in /opt/rockstor/etc/nginx/nginx.conf:47

This test was with:

rleap15-3:~ # zypper info nginx
Loading repository data…
Reading installed packages…

Information for package nginx:
Repository     : Leap_15_3
Name           : nginx
Version        : 1.19.8-3.6.1
Arch           : x86_64
Vendor         : SUSE LLC <>
Installed Size : 2.2 MiB
Installed      : Yes
Status         : up-to-date
Source package : nginx-1.19.8-3.6.1.src
Upstream URL   :
Summary        : A HTTP server and IMAP/POP3 proxy server
Description    : 
    nginx [engine x] is a HTTP server and IMAP/POP3 proxy server written by Igor Sysoev.
    It has been running on many heavily loaded Russian sites for more than two years.

Just for the record and to round out what I’d mentioned here earlier.

Hope that helps.


I’ve been busy reading Pi threads since I hope that’s my next Rockstor install, and came across this thread. I don’t have the ability to contribute or test right now, but I at least did some research and it looks like the change is minor. As far as I can tell it touches 2 lines in the current conf file
listen 443 default_server;
needs to be
listen 443 default_server ssl;
ssl on;
needs to be removed or commented out.
Hope this helps, if this is restating what you already know sorry to waste your time, I took out of the thread that the problem was known but not the solution.

1 Like

@D_Jones Thanks for double checking our pending requirements. Much apprecaited.

If you fancy having a go at a pull request to apply these changes you are of course most welcome:

Should cover it hopefully. But also take a note of our following currently pending issue regarding our developer documentation:

And the existing issue we have open for this newer ssl directive is from @Hooverdan here:

Take a look particularly at the latter issue link as it mentions some caveates that we should be careful to watch for where we programmatically edit our nginx config under some circumstances.

Hope that helps.

1 Like

@phillxnet I’ve contributed to documentation in the past, then changed jobs, moved cross country, and I’m still catching up. Hope to be more active in the future, maybe even get brave and venture out of docs and into code.