Says "ok" so it (apparently?) doesn't think that PatternLayout.pm is actually missing.

Yes, that's what it means indeed. Did you run this with a PERL5LIB environment variable set? If so, we should make sure the same setting is available in the environment in which the Starman process runs.

I set the variable in the global "profile" file, so it's available to all users. What it should contain is a better question. Right now it contains the path to my Perl repository and the path to the root directory of ledgersmb (/usr/lib/perl5/site_perl/5.26.0/:/usr/local/ledgersmb/)

BTW, there's a CentOS/RH-based SysV init script here: https://github.com/ledgersmb/LedgerSMB/tree/master/doc/conf/sysvinit hopefully that helps to (quickly) build one for LFS. I'd be happy to include such an script in our repository for use by others or even just for reference.

The LFS boot scripts are much more "bare bones" but this will be an excellent starting point, thanks!

The "entry_id" column of table "acc_trans" is just sequential numbers, as far as I can tell. Maybe I misunderstand.

That's interesting. If there are no rows where "amount" is null in acc_trans, then why does this query fail:

select trans_id, chart_id, transdate from acc_trans WHERE amount IS NULL

This may be simpler than it looks. Trying to use it directly from psql, I'm running into an access problem.

vwren$ psql -h localhost -U lsmb_dbadmin -d sql_ledger_weld
Password for user lsmb_dbadmin:
psql (13.2)
Type "help" for help.

sql_ledger_weld=> select trans_id, chart_id, transdate from acc_trans WHERE amount IS NULL;
ERROR: permission denied for table acc_trans

The current owner of the database is the legacy "ledgersmb" user.

So why does this appear to be working when I give the user/password credentials in setup.pl? It can read the database and determine the version of it, and offer to update it.

Let me try changing the ownership of the database (REASSIGN OWNED) and see of that fixes anything. ...

Nope, not that simple. Still fails at the same spot in setup.pl even with all objects owned by lsmb_dbadmin, even though the command I tried above now works with all objects owned by lsmb_dbadmin. Looks like ownership doesn't make a difference. Darn it.

root# psql -h localhost -U lsmb_dbadmin -d sql_ledger_weld
Password for user lsmb_dbadmin:
psql (13.2)
Type "help" for help.

sql_ledger_weld=> select trans_id, chart_id, transdate from acc_trans WHERE amount IS NULL;
trans_id | chart_id | transdate
----------+----------+-----------
(0 rows)

Any database that was dumped from LedgerSMB 1.2, is supposed to be supported for the upgrade process. Due to lack of real life data, however, this goal is hard to achieve. Regularly, databases show up with migration issues (we're less likely to hear from successful migrations, unfortunately); by solving the migration issues that *are* reported to us, I hope to end up with a migration process that allows most people to migrate their databases without problems.

The one I provided to you started out life as an SQL_Ledger database, was converted for 1.2 and then for 1.3. "setup.pl" identifies it as a 1.3 database.
—Victor