SMB Shares inaccessible after update to 5.0.6-0

phillxnet · January 20, 2024, 3:00pm

@Mark93 Hello again. And thanks for the report.

Your issue could well be due to a an older database format from 4.1.0 stable or before having been transitioned via a zypper dup etc to a newer Leap and now using the testing channel. Let us know if this correlates to yoru system.

See the following known issue (testing 5.0.6-0 only) that is currently being resolved:

via the linked issue repeated here for ease:

github.com/rockstor/rockstor-core

Establish Postgres database format upgrade

opened 12:23PM - 19 Jan 24 UTC

closed 12:02PM - 25 Jan 24 UTC

phillxnet

Thanks to @FroggyFlox & KarstenV on the forum for identifying this need. From t…esting channel/branch v5.0.6.0 onwards we have fully updated our Django to 4.2 LTS, and the related python interface library of psycopg to V3: this has surfaced a Django/db-format incompatibility requiring an in-place db update capability. From @FroggyFlox's forum comment here: https://forum.rockstor.com/t/after-updating-to-5-0-6-0-web-interface-is-not-accesible-and-network-shares-are-also-not-accesible/9226/29 We see that although we have previously update our Postgres dependency to 13, and enforce that binaries use via the alternatives system when doing an rpm update, this does not in-itself adjust the underlying DB format, and the newer start up scripts, if they find an older database, will in-fact invoke the relevant older binary of Postgres, regardless of the alternatives system. New, or more recent installs are not affected assuming the use of our official installer as this always wipes the entire system disk, and so always establish a fresh and alternatives guided postgresql version. But Rockstor installs that have been updated from older Leap instances will inherit DB formats that were default at that time: to date we have reports of Postgres version 10 databases. It is proposed that for the next Stable release we develop a script/mechanism to identify and then migrate, in-place, older db versions to the newer 13 version that we currently favour. From the reports in our ongoing testing phase we have the following from KarstenV's testing efforts with 5.0.6-0 (RC1) rpm. Where we significantly updated our Django (twice), as well as adopting psycopg3 which are both very significant update. ``` NotSupportedError(', ‘django.db.utils.NotSupportedError: PostgreSQL 12 or later is required (found 10.23).’, ‘’] ``` Due to the Postgresql startup scripts failing over to the older Postgres to accomodate the older DB format found: ``` Jan 18 22:28:33 RockstorNAS postgresql-script[7819]: Your database files were created by PostgreSQL version 10. ``` The latter resulted when removing the co-resident postgres v10 as openSUSE can carry multiple postgres package installs and auto-selects the newest able to read the database in question. I.e. form @FroggyFlox's exposition of this issue on the linked form thread we have: > 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 and > 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: ```bash 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 ``` Similarly we might establish our own script to identify older 10 db instances: established by old official installers, and provide an in-place update mechanism via presumably: [pg_upgrade](https://www.postgresql.org/docs/13/pgupgrade.html) which must be run under the newer/target Postgres version involved in the migration. Note that a prior name for pg_upgrade was pg_migrator.

We only try to ensure stable to stable updates and this latest testing channel release has helped to uncovered this new DB compatibility issue ready for the next Stable release. That was we can help to ensure the production update nature we have thus far maintained in the Stable channel. I.e. 4.1.0-0 updates via our how-to to 4.6.1-0. And post the above fix and many others already resolved in testing and to be resolved should help to ensure that 4.6.1-0 updates successfully to 5.1.0-0 when it is released.

The plan is to have a fix for this DB migration issue very shortly. But again this only affects Stables from 4.1.0-0 Leap 15.3 eara that have then been transitioned to latest stable as of a few days ago.

Hang in there and keep an eye on that issue. I’ll update this thread when there is a resolution at hand.

Hope that helps. And it would be good to have your confirmation of a fix on the next testing release, as your report does look a little different. But the indicated issue is my current priority re Rockstor.