After I lost a hard drive on my server, I've been reconstructing from
backups,
Good that you've got far enough to be able to reconstruct the databases themselves!
and decided this is a good time to finally migrate away from
1.3.25 to 1.8.11, which I normally wouldn't dream of right before needed
to do taxes, but needs must. After much trial and error, I've got the
server up and talking to Chrome through PSGI.
That's a good basis to build on.
I have gotten as far as
setup.pl, and tried migrating one of my company databases. The
migration crashed with:
"Failed to execute pre-migration check no_null_ac_amounts at
/usr/local/ledgersmb/tools/../lib/LedgerSMB/Scripts/setup.pm line 669."
"dbversion 1.5.30, company"
"Status: 500 Internal server error (PSGI.pm run_new)"
which says:
'There are NULL values in the amounts column of your
source database. Please either find professional help to migrate your
database, or delete the offending rows through PgAdmin III or psql'),
What it proposes is that you check the data in the acc_trans table for NULL values in the 'amount' column. A way to get rid of it (if it's not referenced from anywhere) would be to run the query "DELETE FROM acc_trans WHERE amount IS NULL". By "not being referenced from anywhere", I mean that the rows in acc_trans can themselves reference "invoice" rows or be referenced by "payment_link" rows or "cr_report_line" rows (off the top of my head) and probably others. When those lines refer to these rows, either the referencing rows are meaningless (likely this is the case for "invoice" rows). Or they need to be replaced by a functional equivalent (this is likely the case for "cr_report_line" rows). Links are supposed to be on the "entry_id" field in the "acc_trans" table.
I'm puzzled that you receive this internal server error instead of the message shown above. I've rewritten a large part of the upgrade logic for 1.8 with the exact purpose to solve problems like these I was seeing in earlier upgrades.
The starman log has a possibly relevant error : Failed to execute
bin/lsmb-request.pl (): Can't locate PatternLayout.pm in @INC (you may
need to install the PatternLayout module) (@INC contains:
/usr/local/ledgersmb/tools/../lib /usr/local/ledgersmb/tools/.. lib
/usr/lib/perl5/site_perl/5.26.0/x86_64-linux-thread-multi
/usr/lib/perl5/site_perl/5.26.0
/usr/lib/perl5/vendor_perl/5.26.0/x86_64-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.26.0
/usr/lib/perl5/5.26.0/x86_64-linux-thread-multi /usr/lib/perl5/5.26.0)
at /usr/lib/perl5/site_perl/5.26.0/Log/Log4perl/Util.pm line 51.
...propagated at /usr/local/ledgersmb/tools/../lib/LedgerSMB.pm
line 517.
cpan reports that PatternLayout.pm is up to date.
(/usr/lib/perl5/site_perl/5.26.0/Log/Log4perl/Layout/PatternLayout.pm)
What happens when you
$ perl -MLog::Log4perl::Layout::PatternLayout -E 'say "ok"'
?
It should say "ok", but I doubt it does.
However, I don't think it's all that important for the problem at hand.
PERL5LIB points to /usr/lib/perl5/site-perl/5.26.0/ Grasping at
straws, I added a path to /usr/local/ledgersmb/ with no change
I'm running Postgresql 13.2, Perl 5.26.0, and Apache 2.4.27 with reverse
proxy to starman running on port 5762. I have a "pg_dumpall" backup of
my databases, so I can experiment, but at the moment I'm stumped.
Hope the above helps a bit!
Regards,