[Bug]: 0.18.5 -> Running user_updates_2020_04_02 -> column person.admin does not exist

[lazynooblet]

Updated to 0.18.5, lemmy core starts to initialize and then exits (exitcode: 1)

lemmy-core      | 2023-09-29T17:08:41.365888Z  INFO lemmy_db_schema::utils: Running Database migrations (This may take a long time)...
lemmy-core      | 2023-09-29T17:08:41.370343Z  INFO lemmy_db_schema::utils: Database migrations complete.
lemmy-core      | 2023-09-29T17:08:41.384390Z  INFO lemmy_server::code_migrations: Running user_updates_2020_04_02
lemmy-postgres  | 2023-09-29 17:08:41.385 UTC [44] ERROR:  column person.admin does not exist at character 394
lemmy-postgres  | 2023-09-29 17:08:41.385 UTC [44] STATEMENT:  SELECT "person"."id", "person"."name", "person"."display_name", "person"."avatar", "person"."banned", "person"."published", "person"."updated", "person"."actor_id", "person"."bio", "person"."local", "person"."private_key", "person"."public_key", "person"."last_refreshed_at", "person"."banner", "person"."deleted", "person"."inbox_url", "person"."shared_inbox_url", "person"."matrix_user_id", "person"."admin", "person"."bot_account", "person"."ban_expires", "person"."instance_id" FROM "person" WHERE (("person"."actor_id" LIKE $1) AND ("person"."local" = $2))
lemmy-core      | Error: LemmyError { message: None, inner: column person.admin does not exist, context: SpanTrace [] }
lemmy-core exited with code 1

Running docker via image: dessalines/lemmy:0.18.5 on Debian 11
Updated from 0.18.4-beta.8

[Morethanevil]

Okay, so someone else was stupid as me and has now the same problem :)
You can fix this manually in the database, then your container will start again.

!NO GUARANTEE AND PLEASE MAKE A BACKUP FIRST!

First connect with the database of lemmy. If you use the provided docker example this can be done with:

docker exec -it lemmy-postgres-1 /bin/bash

Now you are inside the postgres container of Lemmy

Type psql -U lemmy to use postgres

You need to create the admin table with (pay attention to ; at the end, it is important!):

ALTER TABLE public.person ADD admin bool NOT NULL DEFAULT false;

And set yourself back to admin again with:

UPDATE public.person SET admin=true WHERE id=2;

Now exit the postgres simply with \q and then type exit to leave the postgres container.

Restart the complete stack with docker compose down && docker compose up -d

It should start again now :)

[Die4Ever]

Okay, so someone else was stupid as me and has now the same problem :) You can fix this manually in the database, then your container will start again.

!NO GUARANTEE AND PLEASE MAKE A BACKUP FIRST!

First connect with the database of lemmy. If you use the provided docker example this can be done with:

docker exec -it lemmy-postgres-1 /bin/bash

Now you are inside the postgres container of Lemmy

Type psql -U lemmy to use postgres

You need to create the admin table with (pay attention to ; at the end, it is important!):

ALTER TABLE public.person ADD admin bool NOT NULL DEFAULT false;

And set yourself back to admin again with:

UPDATE public.person SET admin=true WHERE id=2;

Now exit the postgres simply with \q and then type exit to leave the postgres container.

Restart the complete stack with docker compose down && docker compose up -d

It should start again now :)

my docker exec was like

docker exec -it lemmy_postgres_1 /bin/bash

also you might want to make sure you're setting the correct user as admin before you run that UPDATE query, do like

SELECT id, name, actor_id, admin FROM public.person WHERE id=2;

[Morethanevil]

I choosed id=2 because it is the first user you create, so it should work for most single user instances. If there are more admins, they can be set aagain via UI. The first mistake was to use this betaversion, but downgrading back did not work either. :D

Thanks for the additional infod

[lazynooblet]

Excellent thanks both, this allowed me to upgrade to 0.18.5, seems to have been stable for last hour. I guess I should leave this open in case the bug gets addressed internally. If the maintainers want to close it as its just an edge case, go ahead.

[luke911]

Thank for this everyone, I didn't notice the latest tag had been suspended and so decided to upgrade to 0.18.5 today and thankfully found this fix that worked perfectly.

[Nutomic]

Did everyone run into this issue after upgrading from 0.18.4-beta.x or :latest to 0.18.5? It looks like the 0.18.4-beta.x actually point to main branch, not sure why. @dessalines do you know more about it? And :latest also points to main branch, we got rid of it to avoid problems.

So by installing 0.18.5, you effectively downgraded from main branch to an older version which isnt really tested/supported. You need to manually downgrade the db as described above, or directly upgrade to 0.19.0 which should work without problems. And we need to ensure that tags are on the correct branch so this wont happen again in the future.

[dessalines]

I just checked, and the release/v0.18 branch, and the 0.18.5 release tag does not have the 2023-08-01-101826_admin_flag_local_user migration, which removes that column.

That means that the only people running into this issue, are ones who incorrectly used the docker:latest tag, which is nowhere in our docs, and which even docker recommends against using because its dangerous.

This issue is now fixed by us removing all docker:latest tags, so hopefully no one will run into this in the future, and will explicitly use tagged versions as docker recommends.

Also for anyone who did this, you will need to either restore from a DB backup before you upgraded, or manually run the DB commands in the down.sqls for every migration since the last release, to get your DB back to stable.