Update from 8.3.0 to 9.0.1 fails

[ralfrupf1976]

Log Database.txt

Steps to reproduce

1. Stop Mastercontainer from gui
2. Update Mastercontainer to 9.0.1
3. Start Update other Containers - stops working, Database import fails.

Expected behavior

It should Update to the newest stable release but it fails with errors on starting the database

Actual behavior

• DIFFERENT_DB_OWNER=1
• psql -v ON_ERROR_STOP=1 --username nextcloud --dbname nextcloud_database invalid command \n The database import failed. Please restore a backup and try again. For further clues on what went wrong, look at the logs above.

Host OS

Ubuntu

Nextcloud AIO version

8.3.0 update to 9.0.1

Current channel

Stable

Other valuable info

[szaimen]

• The database import failed. Please restore a backup and try again. For further clues on what went wrong, look at the logs above.

Can ypu post these logs here?

[szaimen]

Lege mal alles, was im Log zur Datenbank war hier aufs Mail - was dienst darf publiziert werden.

Hi, if you've sent an attachment: that was not posted on github. Please upload the file on github manually. Thanks!

[ralfrupf1976]

In my first post I integrated the log of the database container - Log Database.txt

[chrisb-gif]

Same for us here, same logs. We digged deep yesterday. We tried several backup-points and investigated the database. When we looked up the database,nothing was written into it it was created but empty. We looked up the ROLEs and the rights and came to the outcome, that the dbuser who is statet in the config.php, has no rights except "createDB" in the new database. I also think that the postgres user isnt created in the time when the database gets cleared. Maybe this is a hint for someone with more knowledge.

BTW we also tried to put the database dump manually into the new database and added correct rights to the role. Tables get created everything looking fine but Tables got weird names like "oc_appconfig_ex" "oc_ex_apps" etc. so this fails also.

[szaimen]

Hi, @ralfrupf1976 your database logs look very weird. I've never seen such logs as it looks like somehow the migration documentation is printed into your logs which I honestly cannot explain.

@ralfrupf1976 @chrisb-gif did you both migrated from a different kind of installation to AIO by following the migration documentation?

[szaimen]

Also @chrisb-gif can you also post your database logs here from when it fails to import the database dump?

[ralfrupf1976]

Hi, @ralfrupf1976 your database logs look very weird. I've never seen such logs as it looks like somehow the migration documentation is printed into your logs which I honestly cannot explain.

@ralfrupf1976 @chrisb-gif did you both migrated from a different kind of installation to AIO by following the migration documentation?

Yes, i migrated from a typicall LAMP Installation to Nextcloud AIO following the migration documentation.

[chrisb-gif]

@szaimen Yes we formely migrated from nextcloud hoster instance to nextcloud-aio 28.0.6 which worked pretty good. We investigated further and got it into maintenance mode. Tried to do occ missing and the manual occ upgrade. Exception: Updates between multiple major versions and downgrades are unsupported. Update failed is the actual output of occ upgrade When we look into the database only 56rows are written and some tables are missing, interesting cause we pushed the complete dump into a newly created database. Seems so that mastercontainer hangs between versions or does not get the right one to start now.

I put the logs here databaselog.txt

[szaimen]

@chrisb-gif thanks for the logs! Can you please restore a backup from before the update to v9.0.1 and start the containers again and then directly post the database container logs here? (I need to investigate what happens on your instance when it tries to import the dump)

[chrisb-gif]

@szaimen Yes, i restored to a point before the upgrade. Interestingly the Mastercontainer/Website where i can stop and start the containers says im at 9.0.1 although i restored to a point before the update.

I put the logs created directly after the restore here databaselogs-afterrestore.txt

the database docker container keeps restarting over and over again

[szaimen]

Thanks for the logs! It looks like this is your issue:

• GREP_STRING='Name: oc_appconfig; Type: TABLE; Schema: public; Owner:'
• grep -qa 'Name: oc_appconfig; Type: TABLE; Schema: public; Owner:' /mnt/data/database-dump.sql
• echo 'The needed oc_appconfig line is not there which is unexpected.' The needed oc_appconfig line is not there which is unexpected.
• echo 'Please report this to https://github.com/nextcloud/all-in-one/issues. Thanks!' Please report this to https://github.com/nextcloud/all-in-one/issues. Thanks!
• exit 1

[szaimen]

Can you please check why the grep string is not found in your database dump? It would probably be useful if you could grep for appconfig; Type: TABLE; Schema: public; Owner: inside the database dump and post the output here. Thanks!

[chrisb-gif]

@szaimen Like this?

cat database-dump.sql | grep appconfig; Type: TABLE; Schema: public; Owner: -- Name: oc_appconfig; Type: TABLE; Schema: ncdb; Owner: postgres CREATE TABLE ncdb.oc_appconfig ( ALTER TABLE ncdb.oc_appconfig OWNER TO postgres; -- Name: oc_appconfig_ex; Type: TABLE; Schema: public; Owner: oc_nextcloud CREATE TABLE public.oc_appconfig_ex ( ALTER TABLE public.oc_appconfig_ex OWNER TO oc_nextcloud; -- Name: oc_appconfig_ex_id_seq; Type: SEQUENCE; Schema: public; Owner: oc_nextcloud CREATE SEQUENCE public.oc_appconfig_ex_id_seq ALTER TABLE public.oc_appconfig_ex_id_seq OWNER TO oc_nextcloud; -- Name: oc_appconfig_ex_id_seq; Type: SEQUENCE OWNED BY; Schema: public; Owner: oc_nextcloud ALTER SEQUENCE public.oc_appconfig_ex_id_seq OWNED BY public.oc_appconfig_ex.id; -- Name: oc_appconfig_ex id; Type: DEFAULT; Schema: public; Owner: oc_nextcloud ALTER TABLE ONLY public.oc_appconfig_ex ALTER COLUMN id SET DEFAULT nextval('public.oc_appconfig_ex_id_seq'::regclass); -- Data for Name: oc_appconfig; Type: TABLE DATA; Schema: ncdb; Owner: postgres COPY ncdb.oc_appconfig (appid, configkey, configvalue, type, lazy) FROM stdin; -- Data for Name: oc_appconfig_ex; Type: TABLE DATA; Schema: public; Owner: oc_nextcloud COPY public.oc_appconfig_ex (id, appid, configkey, configvalue, sensitive) FROM stdin; -- Name: oc_appconfig_ex_id_seq; Type: SEQUENCE SET; Schema: public; Owner: oc_nextcloud SELECT pg_catalog.setval('public.oc_appconfig_ex_id_seq', 1, false); -- Name: oc_appconfig idx_16449_primary; Type: CONSTRAINT; Schema: ncdb; Owner: postgres ALTER TABLE ONLY ncdb.oc_appconfig -- Name: oc_appconfig_ex oc_appconfig_ex_pkey; Type: CONSTRAINT; Schema: public; Owner: oc_nextcloud ALTER TABLE ONLY public.oc_appconfig_ex ADD CONSTRAINT oc_appconfig_ex_pkey PRIMARY KEY (id); CREATE INDEX idx_16449_ac_lazy_i ON ncdb.oc_appconfig USING btree (lazy); -- Name: appconfig_exconfigkey; Type: INDEX; Schema: public; Owner: oc_nextcloud CREATE INDEX appconfig_exconfigkey ON public.oc_appconfig_ex USING btree (configkey); -- Name: appconfig_exidx; Type: INDEX; Schema: public; Owner: oc_nextcloud CREATE UNIQUE INDEX appconfig_exidx ON public.oc_appconfig_ex USING btree (appid, configkey); -bash: Type:: Kommando nicht gefunden. -bash: Schema:: Kommando nicht gefunden. -bash: Owner:: Kommando nicht gefunden.

[szaimen]

Name: oc_appconfig; Type: TABLE; Schema: ncdb; Owner: postgres

Interesting! Where does Schema: ncdb come from?

[chrisb-gif]

@szaimen I think i got all terms now, grep.txt Schema should be public i guess? But why did it work with this Schema in 8.3.0 , are these the rests of the migration maybe... oh dear.

[szaimen]

Yes, should be public. Can you edit the database dump by changing all occurences of Schema: ncdb; to Schema: public; and check if that makes the import work?

[chrisb-gif]

But then there will stay occurences of ncdb in the ncdb of:

-- -- Name: ncdb; Type: SCHEMA; Schema: -; Owner: postgres

CREATE SCHEMA ncdb;

ALTER SCHEMA ncdb OWNER TO postgres;

SET default_tablespace = '';

SET default_table_access_method = heap;

-- -- Name: oc_accounts; Type: TABLE; Schema: ncdb; Owner: postgres

CREATE TABLE ncdb.oc_accounts ( uid character varying(64) DEFAULT ''::character varying NOT NULL, data text NOT NULL );

ALTER TABLE ncdb.oc_accounts OWNER TO postgres;

Should they also change? No right? I mean it worked under 8.3.0 like a charme

[szaimen]

Should they also change?

Yes, I suppose so

[chrisb-gif]

Im going to fix that. What do i do with the Mastercontainer running on latest version? Will he also go back to 8.3.0?

[szaimen]

Im going to fix that.

Sounds good!

What do i do with the Mastercontainer running on latest version? Will he also go back to 8.3.0?

The restore only restores the data. The images are kept so this is expected and should work fine if the import works correctly.

[chrisb-gif]

OMG Repaired! @szaimen Your an absolute hero today, thank you very much. If you have a link to spend a coffee, let me know. 🥇

[ralfrupf1976]

@szaimen what about my error - still some superpower in the tank?

[szaimen]

OMG Repaired! @szaimen Your an absolute hero today, thank you very much.

Glad to hear! :)

If you have a link to spend a coffee, let me know. 🥇

Feel free to send something to my paypal account (uses the same mail address that is shown on my github profile) :)

[szaimen]

@szaimen what about my error - still some superpower in the tank?

Can you restore a backup from before the update and start the container again and directly post the database container logs here again?

[ralfrupf1976]

I already did yesterday - same problem...

[szaimen]

Ah right. Can you run grep -a 'Name: oc_appconfig; Type: TABLE; Schema: public; Owner:' on the database dump and post the output here?

[ralfrupf1976]

OK - I'll do it in the evening

[chocology]

I have. similar issue from upgrading to the latest version. I had to restore from the backup. Now it lookis like its been running but I simply cannot access it from reverse proxy. Can I add my logs here too?

[szaimen]

I have. similar issue from upgrading to the latest version. I had to restore from the backup. Now it lookis like its been running but I simply cannot access it from reverse proxy. Can I add my logs here too?

Yes, I need the database container logs after the import fails

[szaimen]

@ralfrupf1976 any update on the grep command? :)

[chocology]

It looks like it is running perfectly but I simply cannot access my Nextcloud

I have. similar issue from upgrading to the latest version. I had to restore from the backup. Now it lookis like its been running but I simply cannot access it from reverse proxy. Can I add my logs here too?

Yes, I need the database container logs after the import fails

Setting postgres values... chmod: /var/run/postgresql: Operation not permitted

PostgreSQL Database directory appears to contain a database; Skipping initialization

2024-06-19 12:16:23.992 CEST [14] LOG: starting PostgreSQL 16.3 on x86_64-pc-linux-musl, compiled by gcc (Alpine 13.2.1_git20240309) 13.2.1 20240309, 64-bit 2024-06-19 12:16:23.992 CEST [14] LOG: listening on IPv4 address "0.0.0.0", port 5432 2024-06-19 12:16:23.992 CEST [14] LOG: listening on IPv6 address "::", port 5432 2024-06-19 12:16:23.999 CEST [14] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432" 2024-06-19 12:16:24.031 CEST [24] LOG: database system was shut down at 2024-06-19 11:24:49 CEST 2024-06-19 12:16:24.090 CEST [14] LOG: database system is ready to accept connections 2024-06-19 12:25:15.379 CEST [428] ERROR: duplicate key value violates unique constraint "oc_appconfig_pkey" 2024-06-19 12:25:15.379 CEST [428] DETAIL: Key (appid, configkey)=(core, files_metadata) already exists. 2024-06-19 12:25:15.379 CEST [428] STATEMENT: INSERT INTO "oc_appconfig" ("appid", "lazy", "type", "configkey", "configvalue") VALUES($1, $2, $3, $4, $5) ++ rm -f /mnt/data/database-dump.sql.temp ++ touch /mnt/data/export.failed ++ pg_dump --username nextcloud nextcloud_database Setting postgres values... chmod: /var/run/postgresql: Operation not permitted

PostgreSQL Database directory appears to contain a database; Skipping initialization

2024-06-19 13:51:40.414 CEST [13] LOG: starting PostgreSQL 16.3 on x86_64-pc-linux-musl, compiled by gcc (Alpine 13.2.1_git20240309) 13.2.1 20240309, 64-bit 2024-06-19 13:51:40.414 CEST [13] LOG: listening on IPv4 address "0.0.0.0", port 5432 2024-06-19 13:51:40.415 CEST [13] LOG: listening on IPv6 address "::", port 5432 2024-06-19 13:51:40.424 CEST [13] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432" 2024-06-19 13:51:40.467 CEST [23] LOG: database system was interrupted; last known up at 2024-06-19 13:46:30 CEST 2024-06-19 13:51:42.681 CEST [25] FATAL: the database system is starting up 2024-06-19 13:51:45.472 CEST [23] LOG: database system was not properly shut down; automatic recovery in progress 2024-06-19 13:51:45.538 CEST [23] LOG: redo starts at 2/1264CC10 2024-06-19 13:51:45.545 CEST [23] LOG: invalid record length at 2/12680CB0: expected at least 24, got 0 2024-06-19 13:51:45.545 CEST [23] LOG: redo done at 2/12680C78 system usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s 2024-06-19 13:51:46.757 CEST [13] LOG: database system is ready to accept connections

[szaimen]

Yeah looks good. @chocology please open a new discussion with your problem then: https://github.com/nextcloud/all-in-one/discussions/new?category=questions