[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Release 0.4-rc4
From: |
Karsten Hilbert |
Subject: |
Re: [Gnumed-devel] Release 0.4-rc4 |
Date: |
Fri, 20 Feb 2009 17:08:11 +0100 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
On Wed, Feb 18, 2009 at 08:07:34PM -0300, Rogerio Luz wrote:
> Ok here is the problem, my server v9 tarball makes a .bz2 file but gives the
> below error/exit
>
> ***** consultorio:/home/rogerio/GNUmed/GNUmed-server.v9/GNUmed-v9/server# sh
> gm-zip+sign_backups.sh
> gm-zip+sign_backups.sh: line 107: -s: command not found
> gm-zip+sign_backups.sh: line 107: -s: command not found
> gm-zip+sign_backups.sh: line 107: -s: command not found
> ******consultorio:/home/rogerio/GNUmed/GNUmed-server.v9/GNUmed-v9/server#
You need to say:
sh ./gm-zip+sign_backups.sh
> Please advise if this is ok, because I am weary to drop my current DB in
> order to restore a new v9
Why would you want to do that ?
> I CAN make backups in .tar files, but I cannot make a restore with the
> script currently in my v9 tarball
Well, the v9 restore script isn't smart enough to restore
from a .tar as well (the v10 one can do that) which is what
it complains about here:
> ==> Testing backup file integrity ...
>
> /root/.gnumed/backup/backup-gnumed_v9-GNUmed_Team-consultorio-2009-02-18-19-56-04.tar:
> bad magic number (file not created by bzip2)
This stuff:
> You can use the `bzip2recover' program to attempt to recover
> data from undamaged sections of corrupted files.
is said by bunzip2 because it thinks you probably know what
you do and the .tar might actually be a damaged .bz2.
You can always turn your .tar into .bz2:
bzip2 -z backup-file.tar
> This was my problem a few months back and Karsten send me some scripts that
> fixed it, but I lost them ... the thing is it is shipped this way in the
> tarball and it should "just work", right??
It works quite well when used as documented right inside the
restore script:
#==============================================================
# $Source: /sources/gnumed/gnumed/gnumed/server/gm-restore_database.sh,v $
# $Id: gm-restore_database.sh,v 1.2 2007/12/02 11:48:24 ncq Exp $
#
# author: Karsten Hilbert
# license: GPL v2
#
# This script tries to restore a GNUmed database from a
# backup. It tries to be very conservative. It is intended
# for interactive use and will have to be adjusted to your
# needs.
#==============================================================
echo "====================================================="
echo "usage: $0 <backup file>"
echo ""
echo " <backup file>: a backup-gnumed_vX-*.tar.bz2 file"
echo "====================================================="
> Now I am having trouble testing the v10 server .... when I try to upgrade:
>
>
> ****consultorio:/home/rogerio/GNUmed/GNUmed-server-v10# sh upgrade-db.sh 9 10
Please try again with
sh ./upgrade-db.sh 9 10
(note that this should be run as root)
> 2) upgrading to new database ...
> Adjusting PYTHONPATH ...
> Please make sure the GNUmed Python modules are in the Python path !
> Traceback (most recent call last):
> File "./bootstrap_gm_db_system.py", line 65, in <module>
> from Gnumed.pycommon import gmLog2
> ImportError: cannot import name gmLog2
> Upgrading "gnumed_v9" to "gnumed_v10" did not finish successfully.
> consultorio:/home/rogerio/GNUmed/GNUmed-server-v10#
Given a standard tarball this works just fine for me. Note
that the upgrade-db.sh script must be invoked from within
server/bootstrap/ !
> PS sending the .po file 65% done
Great ! I have included your translation in 0.4-rc6
already.
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346