test: the boot test asserts the database hooks and the cluster after first boot #17

Open

marcos-mendez wants to merge 1 commit from test/cluster-active-after-first-boot into main

marcos-mendez commented

2026-10-10 16:14:17 -03:00

(Migrated from github.com)

On the step 12 image (2026-10-09), postgresql@17-main started before keel-host-keys made the snakeoil certificate and stopped (FATAL: could not load server certificate file "/etc/ssl/certs/ssl-cert-snakeoil.pem"). 35pgsqlpass and 36pgsqlverify failed. Then 36pgsqlverify started the cluster again, so the cluster was active at the end, and the boot test failed only later, on the declared password.

Reproduced on the published layer in LXC, with keel-host-keys made 10 s slower: the same FATAL, the same two hook failures, the cluster active at the end. The cluster waits only for network.target, so it is a race between the network and keel-host-keys.

Change

After the first boot, tests/boot-test.sh now checks:

bt_db_hooks_verdict: 35pgsqlpass and 36pgsqlverify completed, from /var/log/inithooks.log. A cluster that is active at the end is not sufficient (see above).
bt_cluster_verdict: there is a cluster unit (systemctl list-units --all postgresql@*.service), and every cluster is active (running).

Seven new tests in tests/boot-test.bats; tests/lib/boot-test-lib.sh stays at 100 percent (173/173). This change is to tests only, so there is no changelog entry and no version bump.

Fix

Keel-Linux/inithooks#45 orders every postgresql@.service instance after keel-host-keys.service. With that drop-in in the same slow rootfs, both hooks complete and the cluster starts after the certificate exists. The appliance / boot-published-layer check boots the published layer upgraded from trixie-testing. Thus it fails until inithooks 2.3.6+keel26 is in the archive. It fails on main now for the same cause.

On the step 12 image (2026-10-09), `postgresql@17-main` started before `keel-host-keys` made the snakeoil certificate and stopped (`FATAL: could not load server certificate file "/etc/ssl/certs/ssl-cert-snakeoil.pem"`). `35pgsqlpass` and `36pgsqlverify` failed. Then `36pgsqlverify` started the cluster again, so the cluster was active at the end, and the boot test failed only later, on the declared password. Reproduced on the published layer in LXC, with `keel-host-keys` made 10 s slower: the same FATAL, the same two hook failures, the cluster active at the end. The cluster waits only for `network.target`, so it is a race between the network and `keel-host-keys`. **Change** After the first boot, `tests/boot-test.sh` now checks: - `bt_db_hooks_verdict`: `35pgsqlpass` and `36pgsqlverify` completed, from `/var/log/inithooks.log`. A cluster that is active at the end is not sufficient (see above). - `bt_cluster_verdict`: there is a cluster unit (`systemctl list-units --all postgresql@*.service`), and every cluster is `active (running)`. Seven new tests in `tests/boot-test.bats`; `tests/lib/boot-test-lib.sh` stays at 100 percent (173/173). This change is to tests only, so there is no changelog entry and no version bump. **Fix** Keel-Linux/inithooks#45 orders every `postgresql@.service` instance after `keel-host-keys.service`. With that drop-in in the same slow rootfs, both hooks complete and the cluster starts after the certificate exists. The `appliance / boot-published-layer` check boots the published layer upgraded from trixie-testing. Thus it fails until inithooks 2.3.6+keel26 is in the archive. It fails on main now for the same cause.

Some required checks are missing.

This branch is out-of-date with the base branch

You are not authorized to merge this pull request.

View command line instructions