[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Restoring a database under Debian

From: Busser, Jim
Subject: Re: [Gnumed-devel] Restoring a database under Debian
Date: Sat, 24 Jan 2015 01:01:07 +0000

On 2015-01-22, at 1:24 PM, Jim Busser <address@hidden> wrote:

> 3) but I remain stuck at the point of locale (see log).

Having in my last post identified the problem as relating to the form of the 
CREATE DATABASE statement, I attempted to get a patched tar fully through the 
restore process in my Debian VM.

So far though, no success.

I had begun with my 'source' (untarred) directory containing my patched dump 
and my roles:


and re-tarred it from the directory one above, so as to avoid including some or 
all of the upstream path.

On Mac OS, tarring with -W (verify) is unsupported, hence

        tar -cf 

However when I tried to restore from this inside Debian VM, the following 
problems ...

- the roles file that I was presented to edit was empty, and
- the script failed, claiming the database.sql file did not exist

despite that following the failure I could (as root) both see them and verify 
that roles.sql is NOT empty.

Mind you, I did run into one strange pair of things on my first attempt to 
restore from the tar which I had created under Mac OS. Namely, (1) the 
unarchived files ended up being owned by some weird non-existent user and group 
503 (non-existent as queried with getenv passwd) and (2) an unexpected extra 
file was observed in the untarred directory, having a name of the form which 
began 'dot underscore' (._backup…database.sql) despite being absent (even with 
ls -al) in the source directory. I did not try to reproduce this.

What I tried instead was to reboot, re-download server 20.2, re-tar my patched 
source directory from inside my Debian VM (using Debian tar -cWf).

Yet my re-try to restore, I was presented the same empty roles file to edit, 
and the same complaints.

I am having trouble to understand why  the inability to read the files which 
did exist, and which were not empty, especially if the active user at that 
point was still root.

I am stuck ...

-- Jim

Terminal output, followed by my checking of permissions:

==> Trying to restore a GNUmed backup ...

==> Reading configuration ...

==> Setting up workspace ...
    dir: /tmp/gnumed/gm-restore_2015-01-23_13-31-40/

==> Creating copy of backup file ...

==> Unpacking backup file ...
 => Extracting (from tarball) ...
drwx------ djb/djb           0 2015-01-22 16:34 
-rw-r--r-- djb/djb         171 2015-01-23 12:59 
-rw-r--r-- djb/djb   383681340 2015-01-23 12:59 
-rw-r--r-- djb/djb       10249 2015-01-21 21:05 

==> Adjusting GNUmed roles ...

   You will now be shown the roles backup file. Please
   edit it to only include the roles needed for GNUmed.

   Remember that in PostgreSQL scripts the comment marker is "--".

   There are more instructions inside the file.

   Press <ENTER> to start editing.

==> Checking target database status ...
head: cannot open 
 for reading: No such file or directory
    ERROR: Cannot determine target database from backup file. Aborting.

Checking permissions …

ls -al 
total 374716
drwxrwx--- 2 root vboxsf      4096 Jan 23 13:35 .
drwxr-xr-x 3 root root        4096 Jan 23 15:54 ..
-rwxrwx--- 1 root vboxsf 383681340 Jan 23 12:59 
-rwxrwx--- 1 root vboxsf     10249 Jan 21 21:05 

-- Jim

reply via email to

[Prev in Thread] Current Thread [Next in Thread]