[Solved] Gitea Installation Fails with Database Error

Troubleshooting
1

I used dietpi-software to install Gitea, and that seemed to go fine. Next in the instructions posted here:
https://dietpi.com/forum/t/dietpi-software-details-for-all-installation-options/22/112

I went to 192.168..**:3000 and the “Install Configuration” page came up for Gitea. So far so good. In the above instructions it says very specifically that you should change only certain fields. However, I’m fine with the “gitea” user for the mariadb database and the password field was left blank. No mater what I do I can’t leave the fields as they are, or put a password into the blank password without getting the following error with either “(using password: YES or NO)” depending if I put a password into there or not.

Error Message “Database setting is invalid: Error 1045: Access denied for user ‘gitea’@‘localhost’ (using password: YES)”

I’m guessing that I don’t have mariadb properly configured, but that was not part of the instructions so I’m a bit lost as to what to do as this point. I’m not sure if the dietpi scripts automatically created a user and password in mariadb or I still need to do that. I’m sure this is a noob question (I’m new to the world of website databases), and I tried searching and reading the documentation for Gitea, but they don’t reference database errors. I tried reading some documentation about mariadb, but that references a root user and password, which I didn’t set up when the dietpi script installed and configured everything so I’m unsure if I’m supposed to use my system root user and password for those instructions.

Thanks for any help you are able to offer.

2

Check again the link: You need to enter/adjust the database info as stated there. The database has already been configured/created for you with database and user name both gitea. The password dietpi is just a placeholder for the global software password that you choose either via dietpi.txt before first boot of DietPi, or otherwise you were asked during first run setup for it or for older systems during one of the past updates. Host must be localhost, since MariaDB and Gitea are on the same machine.

3

[See My Next Post - It Was A Password Issue]

Thanks, MichaIng, for giving me some direction. I opened the “Install and Configuration” site again on my network. I left the gitea as the user, and for the password. I did not specify anything in dietpi.txt before I installed and booted Dietpi for the first time. So I used the password that I use to install all my software like when I “sudo apt install” something. Is there a different password that you set other than the ones you set for the user dietpi and root? If so perhaps I misplaced that password.

I checked the “host” and you said it had to be set to localhost. It was set to “127.0.0.1:3306” which should be localhost. I also tried putting into the host field “localhost:3306” but that didn’t work either. I am at a loss as to what I’m doing wrong. Perhaps the password is wrong, but I have installed ProFTP and other software using “sudo apt install” without any issue on my install of Dietpi. Dietpi has also updated to the newest version without issue too. Any other ideas what I might have missed?

Thanks for helping a new user, I appreciate your help and patience.

4

I could kick myself. MichaIng, you were right. I messed up the password. I looked through my Dietpi install notes and discovered what was called a “Global Password”. This was the password your were referring to. I kept trying to use the passwords for my user “dietpi” and “root” and those weren’t working. When I used the “Global Password” it finished the install, and I’m up and running now. Thank you so much for your patience.

5

I’m getting the exact same error on Dietpi v8.12.1 (yes I know I’m resurrecting an old thread, but the issues are very similar).

The solution (as described above) requires knowing the global password, which I thought I knew… but didn’t. So I did a manual workaround, and I’m posting here for anyone who also faces this issue:

## log in to msql as root without pass
sudo mysql -u root

## Check that the database "gitea" is there
MariaDB [(none)]> show tables;

## Check that the user "gitea" is also there
MariaDB [(none)]> SELECT User, Host, authentication_string 
                  FROM mysql.user;

## Change the password for "gitea" to something new
MariaDB [(none)]> ALTER USER 'gitea'@'localhost' IDENTIFIED BY 'mypass123'; 
MariaDB [(none)]> FLUSH PRIVILEGES;

## Quit mysql
MariaDB [(none)]> quit;

After that, you should be able to complete the http://192.168.x.x:3000/ log in, by specifying the table as “gitea”, the user as “gitea”, and the password as whatever you set it to (mypass123).

1 Like
6

@mtekman thank you for posting about this.

I have moved away from Dietpi because I had SD corruption happen twice after doing the dietpi update on a Raspberry Pi 1 B with 512mb of RAM. Where as I have been running Raspberry OS with unattended upgrades for over a year without any SD corruption. I never looked into why the Dietpi update tended to corrupt the SD cards on my old Pi’s.

However, Dietpi is an amazing project, and I should really look into giving it another try on either an unused Raspberry Pi 1 or on x86 hardware that I have lying around in my homelab. Your post provides a fix for an issue that I had, and reminded me that Dietpi in my homelab would be useful.

I moved away from Gitea as well, and chose to simply run git on a RPi 1 that serves as my ‘private’ git server using bare repositories. Since this gives me all the functionality I need without the overhead of running a web app.

Thanks for peeking my interest again.

1 Like
7

On an update, DietPi is not doing anything different than running apt update && apt upgrade, which is Debian standard way to update packages. Btw, DietPi offers the option as well to update apt packages once a day automatically (without the need of additional software).

8

guide 7.2
I also followed this guide to install gitea, but also failed with:
Datenbankeinstellungen sind ungültig: Error 1045 (28000): Access denied for user 'gitea'@'localhost' (using password: YES)

I managed to change my global password with instructions in toml file found here and restarted dietpi-dashboard.service.

It always says MariaDB but my config page says MySql.

Also all the pathes given are not existent and so does the

/run/mysqld/mysqld.sock

Where is the database storage folder?
And also I have already a working git repo configured in /home/git/git… Can’t I use this also for gitea or do I have to use the default places. I also have found gitea artifacts in /home/git/gitea…

But anyway I am stuck and nothing works.

9

I did manage to connect to mysql, database gitea and changed password according to @mtekman , but one line was missing , so I post the correct flow here, it was luckily easily done with a best guess after looking at the help of the database (I am no expert in data bases), missing command was to connect to gitea, which was only mentioned as a comment. Magically it connects to a database somewhere out there, stil don’t know the folder’s name:

## log in to msql as root without pass
sudo mysql -u root

## Check that the database "gitea" is there
# next line was missing
MariaDB [(none)]> connect gitea    
MariaDB [gitea]> show tables;
+---------------------+
| Tables_in_gitea     |
+---------------------+
| access              |
| access_token        |
| action              |
| attachment          |
| collaboration       |
| comment             |
| commit_status       |
| deleted_branch      |
| deploy_key          |
| email_address       |
| external_login_user |
| follow              |
| gpg_key             |
| hook_task           |
| issue               |
| issue_label         |
| issue_user          |
| issue_watch         |
| label               |
| lfs_lock            |
| lfs_meta_object     |
| login_source        |
| milestone           |
| mirror              |
| notice              |
| notification        |
| org_user            |
| protected_branch    |
| public_key          |
| pull_request        |
| reaction            |
| release             |
| repo_indexer_status |
| repo_redirect       |
| repo_unit           |
| repository          |
| star                |
| stopwatch           |
| team                |
| team_repo           |
| team_user           |
| tracked_time        |
| two_factor          |
| upload              |
| user                |
| user_open_id        |
| version             |
| watch               |
| webhook             |
+---------------------+
49 rows in set (0,003 sec)

## Check that the user "gitea" is also there
MariaDB [gitea]> SELECT User, Host, authentication_string 
    ->                   FROM mysql.user;
+-------------+-----------+-------------------------------------------+
| User        | Host      | authentication_string                     |
+-------------+-----------+-------------------------------------------+
| mariadb.sys | localhost |                                           |
| root        | localhost | invalid                                   |
| mysql       | localhost | invalid                                   |
| gitea       | localhost | *[xx] |
| oc_admin    | localhost | *[xx] |
| oc_admin    | %         | *[xx] |
| oc_admin1   | localhost | *[xx] |
| oc_admin1   | %         | *[xx] |
| user        | localhost | *[xx] |
+-------------+-----------+-------------------------------------------+
9 rows in set (0,005 sec)

## Change the password for "gitea" to something new (here <mypass123>)
MariaDB [gitea]> ALTER USER 'gitea'@'localhost' IDENTIFIED BY 'mypass123'
## save all changes to table, that are possibly just cached
MariaDB [(none)]> FLUSH PRIVILEGES;

## Quit mysql
MariaDB [(none)]> quit;

@Joulinar : So I found out, that a previously installed version of gitea was present at the system (aand now I remember it working), but it was not selected in dietpi-software nor it was configured. I managed to change all the data fields necessary (and it was quite a big change (only) in the second block, where the gitea-log, the gitea repo (identical to the git repo now) was configured. After updating the log the error vanished and server went offline. So is there any incompatibilities in the last one to three years?

Do you have any further tips how to revive the system? Or does it simply take a longer time to synchronize? Attached the typed in config data on the web config page…the supposed ini file is not saved :

root@Server:/home/git/git/nameofrepo/scripts.git# ll /mnt/dietpi_userdata/gitea/custom/conf/app.ini
ls: Zugriff auf '/mnt/dietpi_userdata/gitea/custom/conf/app.ini' nicht möglich: Datei oder Verzeichnis nicht gefunden
root@Server:/home/git/git/nameofrepo/scripts.git# ll /mnt/dietpi_userdata/gitea/custom/conf/
ls: Zugriff auf '/mnt/dietpi_userdata/gitea/custom/conf/' nicht möglich: Datei oder Verzeichnis nicht gefunden
root@Server:/home/git/git/nameofrepo/scripts.git# ll /mnt/dietpi_userdata/gitea/custom/
ls: Zugriff auf '/mnt/dietpi_userdata/gitea/custom/' nicht möglich: Datei oder Verzeichnis nicht gefunden
root@Server:/home/git/git/nameofrepo/scripts.git# ll /mnt/dietpi_userdata/gitea/

Install config gitea.txt (1.8 KB)

1 Like
10

I personally don’t use Gitea, but if it was already present on your system, could it have been installed outside of the DietPi script? This would at least explain why it wasn’t listed as installed. Next, it could be possible that this installation is using a different file system structure/location. Did you already tried searching Gitea folder??

find / -name "gitea"

As well service log should give some information about path used

journalctl -u gitea.service
11

@Joulinar Thanks, good tips and hints where to look! No I guess, I remember I had to change the ssd image of the dietpi installation because of assumed previous issues. At least that is my best guess. I can’t remember of a script. And it was for sure running once. Do you know some places of scripts of GItea (guess not, because you do not use it)

I guess I have found the service (did not mention yesterday!) here (and all my findings on / I could find besides /home/git:

-rwxr-xr-x  1 root   root   45747928  25. Jul 2022  /usr/local/bin/gitea

drwxr-xr-x  2 gitea  gitea  4096      28. Jan 22:19 /var/log/gitea
-rwxr-xr-x  1 gitea  gitea  132160264 28. Jan 22:18 /mnt/dietpi_userdata/gitea
-rwxr-xr-x  1 gitea  gitea  132160264 28. Jan 22:18 /mnt/dietpi_userdata/gitea/gitea  
drwx------  2 mysql  mysql       4096 25. Jul 2022  /mnt/dietpi_userdata/mysql/gitea

The mysql data base is under control of mysql user. Could that be an access problem?

Do you know if this installation could be only a stub with missing rights. I am thinking of the possibility, that when I tried to install it acc. your description, it failed maybe because of either non existing dirs in /mnt or missing rights creating it (because web browser does not have su rights)?? Any hints what I can do more here, with the service, options, rights?

In the end : How can I soberly (re)set up this process again?

[EDIT]
The service fails with demanding a lower version, it no longer supports auto-migration, oops!:

● gitea.service - Gitea (DietPi)
     Loaded: loaded (/etc/systemd/system/gitea.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Mon 2024-01-29 02:42:41 CET; 10h ago
    Process: 1004 ExecStart=/mnt/dietpi_userdata/gitea/gitea web (code=exited, status=1/FAILURE)
   Main PID: 1004 (code=exited, status=1/FAILURE)
        CPU: 3.139s

Jan 29 02:29:02 Server gitea[1004]: 2024/01/29 02:29:02 cmd/web.go:117:showWebStartupMessage() [I] Prepare to run install page
Jan 29 02:29:04 Server gitea[1004]: 2024/01/29 02:29:04 cmd/web.go:304:listen() [I] Listen: http://0.0.0.0:3000
Jan 29 02:29:04 Server gitea[1004]: 2024/01/29 02:29:04 cmd/web.go:308:listen() [I] AppURL(ROOT_URL): http://localhost:3000/
Jan 29 02:29:04 Server gitea[1004]: 2024/01/29 02:29:04 ...s/graceful/server.go:70:NewServer() [I] Starting new Web server: tcp:0.0.0.0:3000 on PID: 1004
Jan 29 02:42:41 Server gitea[1004]: 2024/01/29 02:42:41 ...s/install/install.go:225:checkDatabase() [I] Gitea will be installed in a database with: hasPostInstallationUser=false, dbMigrationVersion=58
Jan 29 02:42:41 Server gitea[1004]: 2024/01/29 02:42:41 ...ations/migrations.go:616:Migrate() [F] Gitea no longer supports auto-migration from your previously installed version.
Jan 29 02:42:41 Server gitea[1004]: Please try upgrading to a lower version first (suggested v1.6.4), then upgrade to this version.
Jan 29 02:42:41 Server systemd[1]: gitea.service: Main process exited, code=exited, status=1/FAILURE
Jan 29 02:42:41 Server systemd[1]: gitea.service: Failed with result 'exit-code'.
Jan 29 02:42:41 Server systemd[1]: gitea.service: Consumed 3.139s CPU time.

Ok, now the solution path seems clearer! But again, what would you do?

After restart of the service the web config page is available again, but the error remains even with your recommended default values (and only them). So the last thing which can differ IMHO is the gitea data base itself which scheme is not fitting?? How can I transform this database then?