Since this is my first post I feel like a short introduction of myself would be in order: I am from Germany and I work as a software developer/programmer for mobile banking apps. And for the past year or so I have been trying to move more towards Linux and away from Windows/macOS for productivity and gaming related stuff. And I wanted to touch my toes into DIY NAS since that interested me.
Now for my problem: Long story short I tried to update my machine/NAS from Leap 15.6/rockstor 5.1.0 to Leap 16.0/rockstor 5.5.5. And somewhere along the process of updating something went wrong.
My machine still boots but the Leap 16.0 installation is throwing D-Bus Message errors and can only be used with my IP-KVM since not even base services can be loaded. And booting older snapshot from months back does not work correctly either sadly. Older snapshots allow me to at least SSH into the machine but rockstor won’t start.
So far I have tried some suggestions from other topics/threads but it seems like I am stuck for now. As it looks like somehow parts of the poetry installation got wiped during the update. The system still recognizes it has a poetry installation but under /opt/rockstor/ there is nothing there.
I have not tried to reinstall rockstor or anything like that, because I would like to keep my configuration of that system.
Now, I do run a second system that I built a custom rockstor installer with LUKS for and that runs Leap 16/rockstor 5.5.5 without issue. My original plan was to transfer the files, shares and parts of the configuration of the old system, over to that newer system.
I am currently wondering if it would be better to just pull the drives from the old system and simply put them in my new system.
Edit: If this post feels like it is missing stuff, it may be because I accidentally clicked on post before I was finished. This is just my first draft I wrote down.
@Reynevan welcome to the Rockstor community.
that’s a very unfortunate outcome. Did you ever make a backup of your settings on the old system using the WebUI?
If you did, you might be able to find it in this directory:
/opt/rockstor/config-backups-rpmsave
depending on your IP-KVM you might be able to mount a virtual USB drive from there and then copy the backup settings down onto your local machine (or just use the command line to mount a physical USB stick on your server) or if you can get services like sshd, or sftp running from within the command line you might be able to get in to get that backup out. Then you could do a reinstall with the Leap16.0 base and apply that backup to get back to the settings you had (or maybe most of them, depending on how old that backup was).
In case you did not, I suspect trying to fix your machine will be hard to do, and a reinstall might be better than physically moving your drives to the new machine and copy at least your files over to the new box (and trying to recall what the settings were ).
Do you have any logs that tell you what is going wrong, e.g. dmesg? I assume, since not even basic services start the rockstor log is not populated with anything recent. Though possibly older information might be sign to what’s not working.
thank you for your fast reply and for your time reading my longer post.
Unfortunately I did not make any backup of my settings from the webUI before I attempted the update.
rockstorNAS:~ # ls -la /opt/rockstor/
total 0
drwxr-xr-x 1 root root 82 Jul 24 20:56 .
dr-xr-xr-x 1 root root 44 Dec 21 2025 ..
-rw-r--r-- 1 root root 0 Dec 20 2025 .initrock
drwxr-xr-x 1 root root 92 Dec 20 2025 certs
drwxr-xr-x 1 root root 58 Jul 24 20:56 conf
drwxr-xr-x 1 root root 430 Mar 12 09:58 rockons-metastore
drwxr-xr-x 1 root root 16 May 30 2025 src
drwxr-xr-x 1 root root 6 May 30 2025 var
That is all that is there at the current moment on my machine in this directory.
Would there be any way to pull the configuration from where it is stored via CLI and without rockstor being started? Or are the setting encrypted in the database? (I assume the settings are stored in some kind of DB)
As to help with where I am headed for a solution:
I think I should clarify it would not be that bad if I lost the configuration. I mostly experimented with them to get a feeling of how things work, like file sharing and docker containers/rock-ons and what not. If anything I care for the rock-on configs if I’m honest, the rest is pretty simple and plain and easy to reproduce.
I wanted to redo all of those settings/configs anyway since I certainly did things “wrong” and/or unsafe as I progressed and learned (like permissions and passwords/keys).
Also I planned to move everything over to my second machine in the near future. Which is why I asked if it would be feasible to simply transfer the drives and and start over from there again. From what I could gather the disks and their filesystems are intact and able to mount.
As for the logs I believe there are logs on the machine, at least I found some. Also dmesg gives a lot of output on Leap 15.6 and Leap 16.0. (For Leap 16 I see a lot of SELinux stuff from systemd).
Which ones would you like to see? And what specifically of them?
Can you check what the SELinux setting is? Or did you already change it as part of your upgrade to permissive behavior?
In the /etc/selinux/config is the parameter SELINUXTYPE set to permissive? If not, change that and reboot.
If not, you’ve mentioned that you can’t even use services like ssh but have to rely on your KVM. I’d be curious why even that service is failing. If you can see that in the dmesg log and further investigate it via `journalctl -xeu sshd.service’
As for the settings piece, yes, all the settings are stored in the postgresql database that’s (when it works) started before rockstor is runnning. And the settings backup is essentially a json dump of those settings. So, first action on your new system, create a baseline backup of your settings, before doing anything else .
If the database is running you could investigate the rockon related tables that can be found under the storageadmin database. It will be fairly cumbersome to dig through those tables looking for the information you need to rebuild your Rockons (see @flox’s framework implementation post on how they designed the Rockon functionality. But I’m also not a psql wizard to make this an efficient view.
If not, you’ve mentioned that you can’t even use services like ssh but have to rely on your KVM. I’d be curious why even that service is failing. If you can see that in the dmesg log and further investigate it via `journalctl -xeu sshd.service’
Interestingly I did some digging and I was able to restore SSH access with ip link set eth1 up and dhclient eth1. At least so far that i can more easily paste and copy I/O. So it seems like SSH works but networking does not.
rockstorNAS:~ # journalctl -xeu sshd.service
Aug 05 18:05:24 rockstorNAS systemd[1]: sshd.service: Failed to read SELinux context of '/usr/lib/systemd/system/sshd.service', ignoring: Operation not permitted
Aug 05 18:05:28 rockstorNAS systemd[1]: Starting OpenSSH Daemon...
░░ Subject: A start job for unit sshd.service has begun execution
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░
░░ A start job for unit sshd.service has begun execution.
░░
░░ The job identifier is 315.
Aug 05 18:05:28 rockstorNAS sshd-gen-keys-start[1143]: Checking for missing server keys in /etc/ssh
Aug 05 18:05:28 rockstorNAS sshd[1178]: Server listening on 0.0.0.0 port 22.
Aug 05 18:05:28 rockstorNAS sshd[1178]: Server listening on :: port 22.
Aug 05 18:05:28 rockstorNAS systemd[1]: Started OpenSSH Daemon.
░░ Subject: A start job for unit sshd.service has finished successfully
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░
░░ A start job for unit sshd.service has finished successfully.
░░
░░ The job identifier is 315.
Aug 05 18:07:31 rockstorNAS sshd-session[1514]: Accepted keyboard-interactive/pam for root from 192.168.30.152 port 59789 ssh2
Aug 05 18:07:31 rockstorNAS sshd-session[1514]: pam_systemd(sshd:session): Failed to connect to system bus: Connection refused
Aug 05 18:07:31 rockstorNAS sshd-session[1514]: pam_unix(sshd:session): session opened for user root(uid=0) by root(uid=0)
Aug 05 18:07:31 rockstorNAS sshd-session[1514]: pam_selinux(sshd:session): Unable to get valid context for root
Aug 05 18:07:31 rockstorNAS sshd-session[1514]: error: ssh_selinux_setup_pty: getfilecon: Operation not supported
Aug 05 18:07:31 rockstorNAS sshd-session[1514]: logind: canot open dbus
So, first action on your new system, create a baseline backup of your settings, before doing anything else .
That is a good advice I will take immediately.
If the database is running you could investigate the rockon related tables that can be found under the storageadmin database.
Thank you for the pointers regarding the DB. It has been a while since I worked with postgres but I think this may be a way to go.
What does systemctl status dbus tell you (you can also check using the journalctl -xeu mentioned above to check the dbus service errors)? Can you start/restart it with systemctl start dbus?
rockstorNAS:~ # systemctl status dbus
× dbus-broker.service - D-Bus System Message Bus
Loaded: loaded (/usr/lib/systemd/system/dbus-broker.service; enabled; preset: enabled)
Drop-In: /usr/lib/systemd/system/dbus-broker.service.d
└─block-restart.conf
Active: failed (Result: exit-code) since Wed 2026-08-05 18:05:27 CEST; 54min ago
Invocation: 2c4d4a70e5874dc3a56416f5316456c8
TriggeredBy: × dbus.socket
Docs: man:dbus-broker-launch(1)
Process: 974 ExecStart=/usr/bin/dbus-broker-launch --scope system --audit (code=exited, status=1/FAILURE)
Main PID: 974 (code=exited, status=1/FAILURE)
Aug 05 18:05:27 rockstorNAS systemd[1]: Failed to start D-Bus System Message Bus.
Aug 05 18:05:27 rockstorNAS systemd[1]: dbus-broker.service: Start request repeated too quickly.
Aug 05 18:05:27 rockstorNAS systemd[1]: dbus-broker.service: Failed with result 'exit-code'.
Aug 05 18:05:27 rockstorNAS systemd[1]: Failed to start D-Bus System Message Bus.
Aug 05 18:05:27 rockstorNAS systemd[1]: dbus-broker.service: Start request repeated too quickly.
Aug 05 18:05:27 rockstorNAS systemd[1]: dbus-broker.service: Failed with result 'exit-code'.
Aug 05 18:05:27 rockstorNAS systemd[1]: Failed to start D-Bus System Message Bus.
Aug 05 18:05:27 rockstorNAS systemd[1]: dbus-broker.service: Start request repeated too quickly.
Aug 05 18:05:27 rockstorNAS systemd[1]: dbus-broker.service: Failed with result 'exit-code'.
Aug 05 18:05:27 rockstorNAS systemd[1]: Failed to start D-Bus System Message Bus.
rockstorNAS:~ # systemctl start dbus
Failed to start dbus.service: Operation refused, unit dbus-broker.service may be requested by dependency only (it is configured to refuse manual start/stop).
See system logs and 'systemctl status dbus.service' for details.
rockstorNAS:~ # journalctl -xeu dbus
-- No entries --
This is now crossing into territory where I have very little knowledge about things happening.
There’s probably a better way somewhere, but you could, as your “Rockon settings backup” take a psql dump of the storageadmin database.
Subsequently, you could force a reinstallation of the Rockstor package:
zypper in --force rockstor
It did work for me on a VM where I made a distribution upgrade and ran into issues for rockstor-bootstrap to start (due to a bunch of failed dependencies) without destroying any of the settings I already had (but there were very few, so I might just have been lucky).
@Reynevan & @Hooverdan from the /opt/rockstor directory listing posted it looks like the prior rockstor was uninstalled, likely as part of dependency management/resolution during the presumed zypper dup. This is expected, and we have yet to release our new stable where we can then establish a proper procedure to ease this Leap 15.6 to Leap 16.0 transition, akin to our existing how-tos for this.
So that’s good news - it may well be that a rockstor package re-install can then just pick-up from that DB. But there may be some foot-work involved if the DB from the last instance is in need of a format update. We have a script that does this on rpm install/update when an older format is detected. So any feedback on that script failing would be good of course. Especially with some knowledge of Postgress a-foot :).
Just wanted to pop in this context and to link to the following prior post that also observed the ‘rockstor’ package being uninstalled in a similar scenario. They later move to Leap 16.0 with related SELinux and ‘rockstor’ package uninstalled issued (the linked post).
Note also that before any ‘rockstor’ package install/re-install you should update to the OS specific repo as in the above forum post. We build all rpms in each repo on the indicated OS - to help to ensure compatibility.
Don’t know what’s going on with the dbus service!!
In the future we are going to take-up @Hooverdan advice and go with the now provided CLI update too for future updates - along with guiding folks on who to change our own repos, as we do in our existing/prior “Distribution update from * to *” howo-tos to avoid rockstor being uninstalled at all. We have also, internally, had to adopt a rather heavy handed approach to our package update that addresses issues of Postgres versions being maintained to facilitate DB format updates, see:
Where we added a --force-resolution to our own unattended zypper based Web-UI enacted update that fixed an issue for us at that time when updating from an older install; which was at the very start of our current testing phase so v5.5.0-0 so pertains to the update experience here given this move was from 5.1.0-0 to 5.5.5-0.
Remember that it is important to match our repos to the host OS as we have had to modify slightly our dependencies per OS target. Once we have our next Stable out we can iron all this out hopefully, so that Stable to Stable updates are a more known entity .
So that’s good news - it may well be that a rockstor package re-install can then just pick-up from that DB.
Good news everyone,
that worked indeed as intended. I had the backup ready but after a rollback and reinstall with a reboot everything seems to be in order (so far).
I will have a look into the DB stuff you posted @phillxnet. But for now since im up an running I want to focus on moving my data to my new server
).
.