Issue 1228: Problem re-initing after deleting db folder
Project Member Reported by bklarson@gmail.com, Jan 5, 2012
Affected Version: 2.2.2-rc0

What steps will reproduce the problem?
1. Download Gerrit 2.2.2-rc0
2. Run 'java -jar gerrit-2.2.2-rc0.war init -d gerrit-test --batch --no-auto-start'
3. Run 'rm -rf gerrit-test/db'
4. Repeat step 2
5. Inspect the All-Projects metadata (git clone gerrit-test/git/All-Projects.git && cd All-Projects && git pull origin refs/meta/config)

What is the expected output? What do you see instead?
In the groups file, there are 2 different Administrators groups with different UDIDs.
In the project.config file, there are 2 copies of all permissions.

Please provide any additional information below.
This was reported at https://groups.google.com/forum/#!topic/repo-discuss/IgTrA7_UojU.  The end result is that the first login will fail with an exception because the user cannot be added to the Administrators group.
Jan 5, 2012
Project Member #1 bklarson@gmail.com
I'm not sure if this is a valid use-case.  If it is not, it seems like we should error out during the second init rather than init to a bad state.

I'm going to assume it is valid and try to fix the oddities in the metadata.  Let me know if that isn't correct.
Jan 6, 2012
Project Member #2 bklarson@gmail.com
There are two issues created by following these steps:

1. Duplicate entries in the project.config file
2. Two admin groups with different UDIDs in the groups file

1 is easy to fix, but 2 is more complicated.  Gerrit creates a new admin group with new UDID when it sets up the database.  Then new permissions are created using the new admin group, which go into the repository.  This results in 2 admin groups in the repository.

One solution might be to delete the old admin group from the repository.  Another solution could be to open the repository and get the current admin UDID before creating the admin group when setting up the database.

In the end, this problem is caused because we store group UDIDs in both the repository and the database.  The ideal solution is to quit storing them in the database.  I will investigate this if/when I have time.

This problem also exists in 2.2.1, so Martin and I feel like it shouldn't hold up 2.2.2.  We aren't even sure if this is a reasonable/valid use-case.
Labels: -Priority-Blocker Priority-Minor
Aug 25, 2014
#3 bartwout...@gmail.com
Since the 2.9 version this issue is more problematic because it isn't providing user 1 full administrator privileges. 

Followed steps:
1. Ran init twice
2. Create user 1 ( not part of admin group)
3. Modified MYSQL database by hand to make user 1 admin
4. User 1 still didn't have all admin privileges. 
Oct 4, 2015
Project Member #4 David.Os...@gmail.com
 Issue 2781  has been merged into this issue.
Dec 3, 2015
#5 Sara.Ar...@gmail.com
I am facing the same issue. Is there an update on this?