Error "expect user" during restore - how to migrate?


#1

{This is a copy of a question asked in an reply, as new topic now; as suggested by Unknwon; see here for my original question}

I’m currently trying to migrate my gogs installation from one server to another - more specifically from a PI (pi@gitpi, gogs 0.11.19.0609, raspberrian) to a VM (git@gitvm, gogs 0.11.66.0916, debian), database SQLite on both sides; using this method. But my attempt ends in a [FATAL] [...g/setting/setting.go:589 newContext()] Expect user 'pi' but current user is: git during restore.

What I did is the following (the machines can share a server filesystem, which I indicated by adding rudimentary mount statements):

[old server]

pi@gitpi:~ $ sudo mount //server/some/dir /home/pi/git_data  # actually a more detailed cifs mount
pi@gitpi:~ $ sudo service gogs stop
pi@gitpi:~ $ sudo ln -s /home/pi/git_data/tmp_cae /tmp/cae
pi@gitpi:~/gogs_go/gogs $ ./gogs backup -v --tempdir /home/pi/git_data/tmp/  --target /home/pi/git_data/backup/
pi@gitpi:~ $ sudo shutdown now

[this produces the backup file]

[new server]

git@gitvm:~$ sudo mount //server/some/dir /home/git/gogs-data  # actually a more detailed cifs mount
git@gitvm:~$ sudo service gogs stop
git@gitvm:~/gogs$ ./gogs restore  -v --tempdir /home/git/gogs-data/tmp --from /home/git/gogs-data/backup/gogs-backup-20181129110513.zip
2018/12/03 09:04:40 [ INFO] Restore backup from: /home/git/gogs-data/backup/gogs-backup-20181129110513.zip
Unzipping /home/git/gogs-data/backup/gogs-backup-20181129110513.zip...
Extracting file...gogs-backup/
Extracting file...gogs-backup/metadata.ini
Extracting file...gogs-backup/db/
Extracting file...gogs-backup/db/User.json
[...]
Extracting file...gogs-backup/db/Version.json
Extracting file...gogs-backup/custom/
Extracting file...gogs-backup/custom/conf/
Extracting file...gogs-backup/custom/conf/app.ini
Extracting file...gogs-backup/data/
[...]
Extracting file...gogs-backup/repositories.zip
2018/12/03 09:05:43 [FATAL] [...g/setting/setting.go:589 NewContext()] Expect user 'pi' but current user is: git

Seems gogs tries to nail me to the username I chose for the first installation!?

Is there any way to migrate (relatively easily) to a new username on a new machine?

The first hint about adjusting the RUN_USER setting didn’t help.

Is there anything else I can do to make this work?


#2

Thanks for the detailed report!

I got the problem now.

Can you try the following steps see if they work?

  1. Unlock the installation flag:
[security]
INSTALL_LOCK = false
  1. Perform backup
  2. Perform restore
  3. Relock the installation flag and change the RUN_USER
[security]
INSTALL_LOCK = true

#3

Thank you very much for your help!

This works better now … but …

now the restore dumps core at a later stage:

git@gitvm:~/gogs$ ./gogs restore  -v --tempdir /home/git/gogs-data/tmp --from /home/git/gogs-data/backup/gogs-backup-20181206082934.zip 
2018/12/06 11:28:10 [ INFO] Restore backup from: /home/git/gogs-data/backup/gogs-backup-20181206082934.zip
Unzipping /home/git/gogs-data/backup/gogs-backup-20181206082934.zip...
Extracting file...gogs-backup/
[...]
Extracting file...gogs-backup/repositories.zip
2018/12/06 11:29:12 [TRACE] Importing table 'User'...
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x800c56]

goroutine 1 [running]:
github.com/gogs/gogs/vendor/github.com/go-xorm/xorm.(*Session).DB(...)
	/home/vagrant/gopath/src/github.com/gogs/gogs/vendor/github.com/go-xorm/xorm/session.go:241
github.com/gogs/gogs/vendor/github.com/go-xorm/xorm.(*Session).Begin(0xc42034a500, 0x107f898, 0xc42034a500)
	/home/vagrant/gopath/src/github.com/gogs/gogs/vendor/github.com/go-xorm/xorm/session_tx.go:10 +0xe6
github.com/gogs/gogs/vendor/github.com/go-xorm/xorm.(*Engine).DropTables(0x0, 0xc4201073e0, 0x1, 0x1, 0x0, 0x0)
	/home/vagrant/gopath/src/github.com/gogs/gogs/vendor/github.com/go-xorm/xorm/engine.go:1313 +0x77
github.com/gogs/gogs/models.ImportDatabase(0xc4207fac90, 0x26, 0x1, 0xc4207fac01, 0x26)
	/home/vagrant/gopath/src/github.com/gogs/gogs/models/models.go:320 +0x3c4
github.com/gogs/gogs/cmd.runRestore(0xc420337e00, 0x0, 0x0)
	/home/vagrant/gopath/src/github.com/gogs/gogs/cmd/restore.go:99 +0x840
github.com/gogs/gogs/vendor/github.com/urfave/cli.HandleAction(0xed81e0, 0x107e098, 0xc420337e00, 0xc420092c00, 0x0)
	/home/vagrant/gopath/src/github.com/gogs/gogs/vendor/github.com/urfave/cli/app.go:483 +0xad
github.com/gogs/gogs/vendor/github.com/urfave/cli.Command.Run(0x1033985, 0x7, 0x0, 0x0, 0x0, 0x0, 0x0, 0x105fea6, 0x26, 0x0, ...)
	/home/vagrant/gopath/src/github.com/gogs/gogs/vendor/github.com/urfave/cli/command.go:193 +0xa35
github.com/gogs/gogs/vendor/github.com/urfave/cli.(*App).Run(0xc420032ea0, 0xc420030070, 0x7, 0x7, 0x0, 0x0)
	/home/vagrant/gopath/src/github.com/gogs/gogs/vendor/github.com/urfave/cli/app.go:250 +0x700
main.main()
	/home/vagrant/gopath/src/github.com/gogs/gogs/gogs.go:40 +0x2b8
git@gitvm:~/gogs$ 

Did I make a wrong step in the procedure?


#4

Ah… looks like you have to have INSTALL_LOCK = true otherwise the database connection will not be initialized. :sob:

I guess before restore command has a way to bypass run user check, you would have to:

  1. Unzip the archive
  2. Change the RUN_USER
  3. Zip back
  4. Restore

#5

Maybe you can try “VMware vCenter Converter Standalone Client” to migrate your gogs to VM.It’s a easy tools.


#6

Unknwon, thanks a lot again for answering and searching for a solution!

I tried your proposal - changing RUN_USER in the archive - (and additionally fixed my mishandling of the database file, which I obviously did wrong from the beginning, to start with :flushed: ).

The first error, I came upon after this, seems to be connected with the tmp dir residing on a different file system than the data dir (there’s a share mounted to /home/git/gogs-data):

git@gitvm:~/gogs$ ./gogs restore  -v --tempdir /home/git/gogs-data/tmp --from /home/git/gogs-data/backup/gogs-backup-20181210083034-altered2.zip 
2018/12/10 13:47:56 [ INFO] Restore backup from: /home/git/gogs-data/backup/gogs-backup-20181210083034-altered2.zip
Unzipping /home/git/gogs-data/backup/gogs-backup-20181210083034-altered2.zip...
Extracting file...gogs-backup/
[...]
Extracting file...gogs-backup/db/IssueLabel.json
2018/12/10 13:48:57 [TRACE] Importing table 'User'...
[...]
2018/12/10 13:50:10 [TRACE] Importing table 'Version'...
2018/12/10 13:50:10 [FATAL] Failed to import 'custom': rename /home/git/gogs-data/tmp/gogs-backup/custom /home/git/gogs/custom: invalid cross-device link
git@gitvm:~/gogs$ 

Next I tried with having the tmp dir on the local machine (which currently happens to have just enough free space), but I ended up in a different error:

git@gitvm:~/gogs$ ./gogs restore  -v --tempdir /tmp --from /home/git/gogs-data/backup/gogs-backup-20181210083034-altered2.zip 
2018/12/10 14:06:14 [ INFO] Restore backup from: /home/git/gogs-data/backup/gogs-backup-20181210083034-altered2.zip
Unzipping /home/git/gogs-data/backup/gogs-backup-20181210083034-altered2.zip...
Extracting file...gogs-backup/
[...]
2018/12/10 14:07:48 [TRACE] Importing table 'Version'...
Unzipping /tmp/gogs-backup/repositories.zip...
Extracting file...gogs-repositories/
[...]
Extracting file...gogs-repositories/kt52-2/electric.git/objects/pack/pack-2f85fb081bcb4f49db7bc9b34f2f4c305c1d4ae6.pack
2018/12/10 14:07:50 [FATAL] Failed to extract 'repositories.zip': open /home/git/gogs-data/gogs-repositories/user/repo.git/objects/pack/pack-2f85fb081bcb4f49d57bc9dffffeeeeddddcccc6.pack: permission denied
git@gitvm:~/gogs$ df -h .

The problem here seems to be that restore seems to partly ignore the config settings on the restore machine. The old machine (“backup side”) has ROOT = /home/pi/git_data/gogs-repositories, while the new (“restore side”) had ROOT = /home/git/gogs-data/repos. But it seems that restore writes to /home/git/gogs-data/gogs-repositories!?
[NB: The same share that is mounted to the new machine (s.above) was mounted to the old on /home/pi/git_data.]


BUT, having realised that I did something wrong about the database file in the first place, I tried my first very, very simple approach to the migration again. And it seems to work after all:
As I have most of the data mounted to the new machine anyway, I additionally copied over the database file (stopped old gogs before!), adjusted the new config and started new gogs. Seems to work good up to now. :thinking: :smile: