postgresql - manual mode
link best version is /usr/lib/postgresql13
link currently points to /usr/lib/postgresql13
link postgresql is /usr/lib/postgresql
slave clusterdb is /usr/bin/clusterdb
slave createdb is /usr/bin/createdb
slave createuser is /usr/bin/createuser
slave dropdb is /usr/bin/dropdb
slave dropuser is /usr/bin/dropuser
slave initdb is /usr/bin/initdb
slave pg_basebackup is /usr/bin/pg_basebackup
slave pg_checksums is /usr/bin/pg_checksums
slave pg_config is /usr/bin/pg_config
slave pg_controldata is /usr/bin/pg_controldata
slave pg_ctl is /usr/bin/pg_ctl
slave pg_dump is /usr/bin/pg_dump
slave pg_dumpall is /usr/bin/pg_dumpall
slave pg_isready is /usr/bin/pg_isready
slave pg_receivewal is /usr/bin/pg_receivewal
slave pg_recvlogical is /usr/bin/pg_recvlogical
slave pg_resetwal is /usr/bin/pg_resetwal
slave pg_restore is /usr/bin/pg_restore
slave pg_rewind is /usr/bin/pg_rewind
slave pg_verifybackup is /usr/bin/pg_verifybackup
slave pg_waldump is /usr/bin/pg_waldump
slave postgres is /usr/bin/postgres
slave postmaster is /usr/bin/postmaster
slave psql is /usr/bin/psql
slave reindexdb is /usr/bin/reindexdb
slave vacuumdb is /usr/bin/vacuumdb
/usr/lib/postgresql10 - priority 100
slave clusterdb: /usr/lib/postgresql10/bin/clusterdb
slave createdb: /usr/lib/postgresql10/bin/createdb
slave createuser: /usr/lib/postgresql10/bin/createuser
slave dropdb: /usr/lib/postgresql10/bin/dropdb
slave dropuser: /usr/lib/postgresql10/bin/dropuser
slave initdb: /usr/lib/postgresql10/bin/initdb
slave pg_basebackup: /usr/lib/postgresql10/bin/pg_basebackup
slave pg_controldata: /usr/lib/postgresql10/bin/pg_controldata
slave pg_ctl: /usr/lib/postgresql10/bin/pg_ctl
slave pg_dump: /usr/lib/postgresql10/bin/pg_dump
slave pg_dumpall: /usr/lib/postgresql10/bin/pg_dumpall
slave pg_isready: /usr/lib/postgresql10/bin/pg_isready
slave pg_receivewal: /usr/lib/postgresql10/bin/pg_receivewal
slave pg_recvlogical: /usr/lib/postgresql10/bin/pg_recvlogical
slave pg_resetwal: /usr/lib/postgresql10/bin/pg_resetwal
slave pg_restore: /usr/lib/postgresql10/bin/pg_restore
slave pg_rewind: /usr/lib/postgresql10/bin/pg_rewind
slave pg_waldump: /usr/lib/postgresql10/bin/pg_waldump
slave postgres: /usr/lib/postgresql10/bin/postgres
slave postmaster: /usr/lib/postgresql10/bin/postmaster
slave psql: /usr/lib/postgresql10/bin/psql
slave reindexdb: /usr/lib/postgresql10/bin/reindexdb
slave vacuumdb: /usr/lib/postgresql10/bin/vacuumdb
/usr/lib/postgresql13 - priority 130
slave clusterdb: /usr/lib/postgresql13/bin/clusterdb
slave createdb: /usr/lib/postgresql13/bin/createdb
slave createuser: /usr/lib/postgresql13/bin/createuser
slave dropdb: /usr/lib/postgresql13/bin/dropdb
slave dropuser: /usr/lib/postgresql13/bin/dropuser
slave initdb: /usr/lib/postgresql13/bin/initdb
slave pg_basebackup: /usr/lib/postgresql13/bin/pg_basebackup
slave pg_checksums: /usr/lib/postgresql13/bin/pg_checksums
slave pg_config: /usr/lib/postgresql13/bin/pg_config
slave pg_controldata: /usr/lib/postgresql13/bin/pg_controldata
slave pg_ctl: /usr/lib/postgresql13/bin/pg_ctl
slave pg_dump: /usr/lib/postgresql13/bin/pg_dump
slave pg_dumpall: /usr/lib/postgresql13/bin/pg_dumpall
slave pg_isready: /usr/lib/postgresql13/bin/pg_isready
slave pg_receivewal: /usr/lib/postgresql13/bin/pg_receivewal
slave pg_recvlogical: /usr/lib/postgresql13/bin/pg_recvlogical
slave pg_resetwal: /usr/lib/postgresql13/bin/pg_resetwal
slave pg_restore: /usr/lib/postgresql13/bin/pg_restore
slave pg_rewind: /usr/lib/postgresql13/bin/pg_rewind
slave pg_verifybackup: /usr/lib/postgresql13/bin/pg_verifybackup
slave pg_waldump: /usr/lib/postgresql13/bin/pg_waldump
slave postgres: /usr/lib/postgresql13/bin/postgres
slave postmaster: /usr/lib/postgresql13/bin/postmaster
slave psql: /usr/lib/postgresql13/bin/psql
slave reindexdb: /usr/lib/postgresql13/bin/reindexdb
slave vacuumdb: /usr/lib/postgresql13/bin/vacuumdb
Again… puzzling as it seems your system should point Django to use v10 . This is also expected as we now manually set this during each RPM install/update:
So what we see here is a sign that the RPM update did what it was supposed to do.
I’m honestly really not sure why Django still tries to use v10 on your system, though. We could try uninstalling v10 as that should then (theoretically) prevent it to even being detected as an option. That shouldn’t break things either, but I’m always a bit reticent in doing that. It depends on whether you are game. You could always see what packages would be removed if you were to do that before committing to anything:
zypper remove postgresql10
and make sure to press n (for NO) when asked.
Well what is the worst that could happen, the system is not working as is, so if we cant fix it here, I’ll probably end up reinstalling.
I would rather not, but I’m willing to try if this fixes anything.
If I uninstall sql10, and then try the force install rockstor, then that should be enough?
That would be the idea, yes… unless I am barking at the wrong tree and there is some old psycopg binary at play somehow… Could you quickly check that, actually?
zypper search *psycopg*
It did not seem to fix it.
When I run:
sudo systemctl start rockstor-bootstrap
I get this:
A dependency job for rockstor-bootstrap.service failed.
So something else is up.
zypper search *psycopg*
Loading repository data…
Reading installed packages…
S | Name | Summary | Type
—±------------------------------±----------------------------------------------±----------
| python-psycopg2 | Python-PostgreSQL Database Adapter | srcpackage
i+ | python2-psycopg2 | Python-PostgreSQL Database Adapter | package
| python3-aws-xray-sdk-psycopg2 | psycopg2 backend for the AWS X-Ray Python SDK | package
| python3-psycopg2 | Python-PostgreSQL Database Adapter | package
| python311-psycopg2 | Python-PostgreSQL Database Adapter | package
Maybe it’s that python2-psycopg2 remnant you have still installed, then. What would be removed if you run:
zypper remove python2-psycopg2
(you can say n for no here again if you don’t want to commit).
I have removed python2-psycopg2
Sadly that didnt seem to help. Still gets an error about depency.
journalctl -xe, gives this:
Jan 18 22:28:09 RockstorNAS [RPM][6204]: Transaction ID 65a997e9 started
Jan 18 22:28:09 RockstorNAS systemd[1]: Reloading.
Jan 18 22:28:09 RockstorNAS systemd[1]: Configuration file /etc/systemd/system/smb.service is marked world-inaccessible. This has no effect as con>
Jan 18 22:28:09 RockstorNAS systemd[1]: /usr/lib/systemd/system/rpc-statd.service:14: PIDFile= references a path below legacy directory /var/run/,>
Jan 18 22:28:10 RockstorNAS systemd[1]: Reloading.
Jan 18 22:28:11 RockstorNAS systemd[1]: Configuration file /etc/systemd/system/smb.service is marked world-inaccessible. This has no effect as con>
Jan 18 22:28:11 RockstorNAS systemd[1]: /usr/lib/systemd/system/rpc-statd.service:14: PIDFile= references a path below legacy directory /var/run/,>
Jan 18 22:28:11 RockstorNAS [RPM][6204]: install rockstor-5.0.6-0.x86_64: success
Jan 18 22:28:11 RockstorNAS [RPM][6204]: Transaction ID 65a997e9 finished: 0
Jan 18 22:28:27 RockstorNAS sudo[5497]: pam_unix(sudo:session): session closed for user root
Jan 18 22:28:33 RockstorNAS sudo[7816]: root : TTY=pts/0 ; PWD=/ ; USER=root ; COMMAND=/usr/bin/systemctl start rockstor-bootstrap
Jan 18 22:28:33 RockstorNAS sudo[7816]: pam_unix(sudo:session): session opened for user root by root(uid=0)
Jan 18 22:28:33 RockstorNAS systemd[1]: Starting PostgreSQL database server…
░░ Subject: A start job for unit postgresql.service has begun execution
░░ Defined-By: systemd
░░ Support: systemd-devel Info Page
░░
░░ A start job for unit postgresql.service has begun execution.
░░
░░ The job identifier is 5247.
Jan 18 22:28:33 RockstorNAS postgresql-script[7819]: Your database files were created by PostgreSQL version 10.
Jan 18 22:28:33 RockstorNAS postgresql-script[7819]: Could not find executables for this version.
Jan 18 22:28:33 RockstorNAS postgresql-script[7819]: Please install the PostgreSQL server package for version 10.
Jan 18 22:28:33 RockstorNAS systemd[1]: postgresql.service: Control process exited, code=exited, status=1/FAILURE
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: systemd-devel Info Page
░░
░░ An ExecStart= process belonging to unit postgresql.service has exited.
░░
░░ The process’ exit code is ‘exited’ and its exit status is 1.
Jan 18 22:28:33 RockstorNAS systemd[1]: postgresql.service: Failed with result ‘exit-code’.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: systemd-devel Info Page
░░
░░ The unit postgresql.service has entered the ‘failed’ state with result ‘exit-code’.
Jan 18 22:28:33 RockstorNAS systemd[1]: Failed to start PostgreSQL database server.
░░ Subject: A start job for unit postgresql.service has failed
░░ Defined-By: systemd
░░ Support: systemd-devel Info Page
░░
░░ A start job for unit postgresql.service has finished with a failure.
░░
░░ The job identifier is 5247 and the job result is failed.
Jan 18 22:28:33 RockstorNAS systemd[1]: Dependency failed for Tasks required prior to starting Rockstor.
░░ Subject: A start job for unit rockstor-pre.service has failed
░░ Defined-By: systemd
░░ Support: systemd-devel Info Page
░░
░░ A start job for unit rockstor-pre.service has finished with a failure.
░░
░░ The job identifier is 5237 and the job result is dependency.
Jan 18 22:28:33 RockstorNAS systemd[1]: Dependency failed for Rockstor startup script.
░░ Subject: A start job for unit rockstor.service has failed
░░ Defined-By: systemd
░░ Support: systemd-devel Info Page
░░
░░ A start job for unit rockstor.service has finished with a failure.
░░
░░ The job identifier is 5121 and the job result is dependency.
Jan 18 22:28:33 RockstorNAS systemd[1]: Dependency failed for Rockstor bootstrapping tasks.
░░ Subject: A start job for unit rockstor-bootstrap.service has failed
░░ Defined-By: systemd
░░ Support: systemd-devel Info Page
░░
░░ A start job for unit rockstor-bootstrap.service has finished with a failure.
░░
░░ The job identifier is 5120 and the job result is dependency.
Jan 18 22:28:33 RockstorNAS systemd[1]: rockstor-bootstrap.service: Job rockstor-bootstrap.service/start failed with result ‘dependency’.
Jan 18 22:28:33 RockstorNAS systemd[1]: rockstor.service: Job rockstor.service/start failed with result ‘dependency’.
Jan 18 22:28:33 RockstorNAS systemd[1]: rockstor-pre.service: Job rockstor-pre.service/start failed with result ‘dependency’.
Jan 18 22:28:33 RockstorNAS sudo[7816]: pam_unix(sudo:session): session closed for user root
lines 1245-1317/1317 (END)
It seems it complains about database files being made by SQL10, that is now missing 
I’m off to bed for today, I’ll pick up again tommorow evening, if you have any ideas for what I can do.
Thanks for being willing to test like that with me… that’s part of what can happen on the Testing channel but I’m sorry I couldn’t get an easy answer to you.
Now, I think I do have a better idea of what is actually happening, although having a simple resolution besides re-installing Rockstor might be more difficult.
Correct; here it is for reference:
This happens when the postgresql.service systemd service tries to start. If we look at that service (systemctl cat postgresql.service), we can see it tries to run the following:
ExecStart=/usr/share/postgresql/postgresql-script start
That file is provided by the system postgresql-server package (v16 as of this writing):
# zypper search --provides /usr/share/postgresql/postgresql-script
Loading repository data...
Reading installed packages...
S | Name | Summary | Type
--+-------------------+-----------------------------------------------------------+--------
i | postgresql-server | The Programs Needed to Create and Run a PostgreSQL Server | package
That script is just a bash script that does some checks, such as compatibility between postgresql versions. The part that is failing on your machine is:
if test -r $DATADIR/PG_VERSION ; then
DATA_VERSION=$(cat $DATADIR/PG_VERSION)
POSTGRES=/usr/lib/postgresql$(echo -n $DATA_VERSION | tr -d .)/bin/postgres
fi
if test -x /usr/bin/postgres; then
ACTIVE=$(readlink -q -f /usr/bin/postgres)
test -z "$POSTGRES" && POSTGRES="$ACTIVE"
fi
if test -n "$DATA_VERSION"; then
if test -z "$ACTIVE" -o "$ACTIVE" != "$POSTGRES"; then
echo " Your database files were created by PostgreSQL version $DATA_VERSION."
if test -x "$POSTGRES"; then
echo " Using the executables in $(dirname $POSTGRES)."
else
echo " Could not find executables for this version."
echo " Please install the PostgreSQL server package for version $DATA_VERSION."
fi
fi
If you run cat /var/lib/pgsql/data/PG_VERSION, you should indeed see 10.
Now, the problem is on how to migrate the database from v10 to v13. I’ll need to be more careful about that one (it seems a db dump followed by restore with the new psql version used to be the way) but that is uncharted territory for me. @phillxnet , would you have any insight here?
A re-install of Rockstor would save you all that hassle, of course, as you would start anew.
EDIT: some details on how to manually upgrade: SDB:PostgreSQL - openSUSE Wiki
These would be rather involved and I’m not sure yet how well they would play with future updates, though.
It responded 10 as you expected.
I would off course like to not have to reinstall, as many things would then have to be setup again.
But if the install is allready broken to a point where it would be hard to repair, I guess I’ll have to do just that.
I’m just having a hard time having to reinstall a setup that boots and works, but just needs to have the Rockstor install repaired
Thanks a lot for the confirmation!
@phillxnet created a dedicated issue to explore our options to address this, thanks to your willingness to test and debug above. Thank you so much, @phillxnet, for already looking into this despite everything else you already had ongoing.
It’s not really broken per se. It’s just that postgresql refuses to start a database that was created by a different version. Rockstor itself simply cannot start because of that. That means that your database is not really broken or damaged, but it does need to be upgraded to a newer version of PostgreSQL. If you do delete /var/lib/pgsql/data/, then yes, your database is gone, but that is not the case here. I’m hopeful there is a way out of this for you without having to re-install Rockstor, but of course, we cannot know for sure yet as that has not been tested yet. I understand time may be of the essence here for you so it depends on whether you can/are willing to wait for this potential database upgrade option.
Sorry I’m not able to provide you with a better answer just now.
Thats fine.
I’ll leave the system as it is right now, and will be happy to test the fix that they develop.
It seems I have triggered a specific set of events to make this happen, but I cant be the only one that has been upgrading from old installs, trying to stay updated, so others will probably see these problems.
I’ll await what happens.
I had the same issue and tried the below and it works for me.
Through SSH
sudo zypper in --force rockstor
Followed by:
sudo systemctl start rockstor-bootstrap
I saw that a new version was available so I went ahead and did:
sudo zypper in --force rockstor
Which took some time, but seemingly produced no errors.
Followed by:
sudo systemctl start rockstor-bootstrap
Which gave this output:
A dependency job for rockstor-bootstrap.service failed. See ‘journalctl -xe’ for details.
“journalctl -xe” gives this:
░░ The unit run-user-26.mount has successfully entered the ‘dead’ state.
Jan 29 16:08:53 RockstorNAS systemd[1]: user-runtime-dir@26.service: Deactivate>
░░ Subject: Unit succeeded
░░ Defined-By: systemd
░░ Support: systemd-devel Info Page
░░
░░ The unit user-runtime-dir@26.service has successfully entered the ‘dead’ sta>
Jan 29 16:08:53 RockstorNAS systemd[1]: Stopped User Runtime Directory /run/use>
░░ Subject: A stop job for unit user-runtime-dir@26.service has finished
░░ Defined-By: systemd
░░ Support: systemd-devel Info Page
░░
░░ A stop job for unit user-runtime-dir@26.service has finished.
░░
░░ The job identifier is 71789 and the job result is done.
Jan 29 16:08:53 RockstorNAS systemd[1]: Removed slice User Slice of UID 26.
░░ Subject: A stop job for unit user-26.slice has finished
░░ Defined-By: systemd
░░ Support: systemd-devel Info Page
░░
░░ A stop job for unit user-26.slice has finished.
░░
░░ The job identifier is 71791 and the job result is done.
lines 1507-1529/1529 (END)
░░ The unit run-user-26.mount has successfully entered the ‘dead’ state.
Jan 29 16:08:53 RockstorNAS systemd[1]: user-runtime-dir@26.service: Deactivate>
░░ Subject: Unit succeeded
░░ Defined-By: systemd
░░ Support: systemd-devel Info Page
░░
░░ The unit user-runtime-dir@26.service has successfully entered the ‘dead’ sta>
Jan 29 16:08:53 RockstorNAS systemd[1]: Stopped User Runtime Directory /run/use>
░░ Subject: A stop job for unit user-runtime-dir@26.service has finished
░░ Defined-By: systemd
░░ Support: systemd-devel Info Page
░░
░░ A stop job for unit user-runtime-dir@26.service has finished.
░░
░░ The job identifier is 71789 and the job result is done.
Jan 29 16:08:53 RockstorNAS systemd[1]: Removed slice User Slice of UID 26.
░░ Subject: A stop job for unit user-26.slice has finished
░░ Defined-By: systemd
░░ Support: systemd-devel Info Page
░░
░░ A stop job for unit user-26.slice has finished.
░░
░░ The job identifier is 71791 and the job result is done.
“cat /var/lib/pgsql/data/PG_VERSION” gives 13, so the update of the database was successfull.
Any ideas as how to bring it back to life?
@KarstenV Hello again.
Thanks again for helping to tease out the multi-faceted issues around this last testing update.
Re:
Just wanted to note that we now have 5.0.7-0 out in testing. It should address both the DB format update requirement issue from systems dating back to Leap 15.3, and the failure to remove our legacy Poetry version, both uncovered predominantly in this thread.
See:
A regular command line update of the rockstor rpm should invoke the required DB update and legacy poetry removal. But you system may be in an interim state, so do keep that in mind and report as you go here, just in case.
N.B. you will need to re-install your by-hand removed postgres10 dependencies. That helped to diagnose the problem: but they are a definite required to be installed to perform the db update. The script we added to do this DB update can be run by-hand as root at the command line, and will help to inform you of these requirements. Existing systems will already have these installed as that is what the systemd required before to access the older DB formats.
Hope that helps.
Seems I answered before your post.
As you’ll see it still does not work.
Any input to what I could try is welcome
@KarstenV Hello again.
We will need a little more log entries on this front. Note that this update has been tested to update from a 4.6.1-0 install with your reported DB, but again we need to know if you did this rpm update before re-installing he by-hand removed postgres10 dependencies of yaw. If you did then this is the problem.
I.e. what postgres packages do you have installed ?
Folks running old DB formats will still have all the old dependencies to read them. This is assumed.
I remember reinstalling postgres 10 again after removing it to restore my system to the previous state.
Running “update-alternatives --list postgresql”, gives this:
/usr/lib/postgresql10
/usr/lib/postgresql13
/usr/lib/postgresql14
So postgres 10, 13 & 14 is installed.
After a reboot I tried “journalctl -xe”
This time it was much more talkative:
Jan 29 16:33:06 RockstorNAS su[19427]: pam_unix(su-l:session): session opened for user postgres by (uid=0)
Jan 29 16:33:06 RockstorNAS su[19427]: pam_unix(su-l:session): session closed for user postgres
Jan 29 16:33:06 RockstorNAS systemd[1]: session-c7.scope: Deactivated successfully.
░░ Subject: Unit succeeded
░░ Defined-By: systemd
░░ Support: systemd-devel Info Page
░░
░░ The unit session-c7.scope has successfully entered the ‘dead’ state.
Jan 29 16:33:06 RockstorNAS su[19466]: (to postgres) root on none
Jan 29 16:33:06 RockstorNAS systemd[1]: Started Session c8 of User postgres.
░░ Subject: A start job for unit session-c8.scope has finished successfully
░░ Defined-By: systemd
░░ Support: systemd-devel Info Page
░░
░░ A start job for unit session-c8.scope has finished successfully.
░░
░░ The job identifier is 2969.
Jan 29 16:33:06 RockstorNAS su[19466]: pam_unix(su-l:session): session opened for user postgres by (uid=0)
Jan 29 16:33:06 RockstorNAS su[19466]: pam_unix(su-l:session): session closed for user postgres
Jan 29 16:33:06 RockstorNAS systemd[1]: session-c8.scope: Deactivated successfully.
░░ Subject: Unit succeeded
░░ Defined-By: systemd
░░ Support: systemd-devel Info Page
░░
░░ The unit session-c8.scope has successfully entered the ‘dead’ state.
Jan 29 16:33:06 RockstorNAS su[19499]: (to postgres) root on none
Jan 29 16:33:06 RockstorNAS systemd[1]: Started Session c9 of User postgres.
░░ Subject: A start job for unit session-c9.scope has finished successfully
░░ Defined-By: systemd
░░ Support: systemd-devel Info Page
░░
░░ A start job for unit session-c9.scope has finished successfully.
░░
░░ The job identifier is 3089.
Jan 29 16:33:06 RockstorNAS su[19499]: pam_unix(su-l:session): session opened for user postgres by (uid=0)
Jan 29 16:33:07 RockstorNAS su[19499]: pam_unix(su-l:session): session closed for user postgres
Jan 29 16:33:07 RockstorNAS systemd[1]: session-c9.scope: Deactivated successfully.
░░ Subject: Unit succeeded
░░ Defined-By: systemd
░░ Support: systemd-devel Info Page
░░
░░ The unit session-c9.scope has successfully entered the ‘dead’ state.
Jan 29 16:33:09 RockstorNAS systemd[1]: rockstor-pre.service: Main process exited, code=exited, status=1/FAILURE
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: systemd-devel Info Page
░░
░░ An ExecStart= process belonging to unit rockstor-pre.service has exited.
░░
░░ The process’ exit code is ‘exited’ and its exit status is 1.
Jan 29 16:33:09 RockstorNAS systemd[1]: rockstor-pre.service: Failed with result ‘exit-code’.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: systemd-devel Info Page
░░
░░ The unit rockstor-pre.service has entered the ‘failed’ state with result ‘exit-code’.
Jan 29 16:33:09 RockstorNAS systemd[1]: Failed to start Tasks required prior to starting Rockstor.
░░ Subject: A start job for unit rockstor-pre.service has failed
░░ Defined-By: systemd
░░ Support: systemd-devel Info Page
░░
░░ A start job for unit rockstor-pre.service has finished with a failure.
░░
░░ The job identifier is 2719 and the job result is failed.
Jan 29 16:33:09 RockstorNAS systemd[1]: Dependency failed for Rockstor startup script.
░░ Subject: A start job for unit rockstor.service has failed
░░ Defined-By: systemd
░░ Support: systemd-devel Info Page
░░
░░ A start job for unit rockstor.service has finished with a failure.
░░
░░ The job identifier is 2603 and the job result is dependency.
Jan 29 16:33:09 RockstorNAS systemd[1]: Dependency failed for Rockstor bootstrapping tasks.
░░ Subject: A start job for unit rockstor-bootstrap.service has failed
░░ Defined-By: systemd
░░ Support: systemd-devel Info Page
░░
░░ A start job for unit rockstor-bootstrap.service has finished with a failure.
░░
░░ The job identifier is 2602 and the job result is dependency.
Jan 29 16:33:09 RockstorNAS systemd[1]: rockstor-bootstrap.service: Job rockstor-bootstrap.service/start failed with result ‘dependency’.
Jan 29 16:33:09 RockstorNAS systemd[1]: rockstor.service: Job rockstor.service/start failed with result ‘dependency’.
Jan 29 16:33:09 RockstorNAS sudo[19083]: pam_unix(sudo:session): session closed for user root
Take a look at the following PR:
Your presumed shell scripting capability should enable you to see what we do, and why. We also do not delete the old DB. If you are careful you can also preserve that and re-instate it, if need be. But we need more info on what is failing on your system currently. I.e. your system is in an indeterminate state, and we need to know more about exactly what is failing.
I.e. if you re-installed all of Posgtres dependencies, it’s not just postgresql10 for example, but also the server related package that may have been removed when you uninstalled postgres10.
For example a system such as yours would have had at least the following installed by way of grand-fathering in form the Leap 15.3 base OS of the installer and original DB instantiation:
installer:~ # zypper se -s postgresql10
...
i+ | postgresql10 | package | 10.23-150100.8.53.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
...
i+ | postgresql10-server | package | 10.23-150100.8.53.1 | x86_64 | Update repository with updates from SUSE Linux Enterprise 15
...
Also look to the zypper history, that will be far more informative (hopefully) on your install. Also I’m unsure if the --force in will have resulted in the same outcome as an update.
Also note the following from the proof of function system used here:
installer:~ # ls -la /var/lib/pgsql/
total 20
drwxr-x--- 1 postgres postgres 144 Jan 26 15:42 .
drwxr-xr-x 1 root root 442 Jan 19 16:34 ..
-rwx------ 1 postgres postgres 769 Jan 26 15:42 analyze_new_cluster.sh
-rw-r----- 1 postgres postgres 192 Oct 20 2021 .bash_profile
lrwxrwxrwx 1 postgres postgres 6 Jan 26 15:42 data -> data13
drwx------ 1 postgres postgres 522 Jan 26 15:41 data10
drwx------ 1 postgres postgres 550 Jan 29 15:32 data13
-rwx------ 1 postgres postgres 42 Jan 26 15:42 delete_old_cluster.sh
Your’s should be very similar, but for others reading this, not necessarily so. @KarstenV system proved our need for DB update that is associated only with older installs zypper dup’ed to cutting edge testing.
Your V10 DB is saved in the data10 directory. Take great care not to loose it if you experiment. If you look to that script we create data13 from an original data dir (not link back then) moved to data10, then create the new data (link this time) to data13 after the migration used data10 & data13. The zypper history log:
less /var/log/zypp/history
should have some info as per the linked PR example. I.e. we given feedback there on the progress of our new script.