Summary
On the stable variant (Bluefin, ghcr.io/projectbluefin/bluefin-nvidia:stable), both LUKS E2E channels consistently fail during the install step with SSH Permission denied, please try again. — even though debug-ssh-banner.service printed the same liveuser/live and root/root credentials, and the live-boot readiness check itself now succeeds quickly (see #129, which fixed a separate serial-log permission bug that was previously masking this).
dakota and lts use the identical password-setting code path in live/src/configure-live.sh (unconditional echo "liveuser:live" | chpasswd when DEBUG=1) and never hit this.
Evidence
From a stable (dev) LUKS E2E run (job 101973875494, after #129's serial-log fix):
08:22:28 Live environment ready (serial marker seen)
08:22:28-08:23:18 [luks-unlock] wait-live: brightness ramps 0.00 -> 127.68, "Live boot GUI stable"
08:23:21 Permission denied, please try again.
08:23:21 Image not in local store — fisherman will pull from network.
08:23:23 Permission denied, please try again.
08:23:23 error: Recipe `luks-install-qemu` failed on line 853 with exit code 5
Compare to a passing dakota (dev) run (job 101973875368) — the very next SSH command after "Live boot GUI stable" succeeds immediately, no permission-denied retries.
Next steps
- Confirm whether
stable's build actually reaches the chpasswd/PasswordAuthentication yes steps in configure-live.sh (check build logs for the stable variant specifically — it's the only variant sourced from ghcr.io/projectbluefin/bluefin-nvidia:stable rather than dakota's freedesktop-sdk base or lts's CentOS Stream base, so distro-specific PAM/nsswitch/authselect defaults might override or race with the drop-in).
- Check whether a Bluefin-specific firstboot/oneshot unit resets
/etc/shadow or re-locks the account after configure-live.sh already set it at build time.
Summary
On the
stablevariant (Bluefin, ghcr.io/projectbluefin/bluefin-nvidia:stable), both LUKS E2E channels consistently fail during the install step with SSHPermission denied, please try again.— even thoughdebug-ssh-banner.serviceprinted the sameliveuser/liveandroot/rootcredentials, and the live-boot readiness check itself now succeeds quickly (see #129, which fixed a separate serial-log permission bug that was previously masking this).dakotaandltsuse the identical password-setting code path inlive/src/configure-live.sh(unconditionalecho "liveuser:live" | chpasswdwhenDEBUG=1) and never hit this.Evidence
From a
stable (dev)LUKS E2E run (job 101973875494, after #129's serial-log fix):Compare to a passing
dakota (dev)run (job 101973875368) — the very next SSH command after "Live boot GUI stable" succeeds immediately, no permission-denied retries.Next steps
stable's build actually reaches thechpasswd/PasswordAuthentication yessteps inconfigure-live.sh(check build logs for thestablevariant specifically — it's the only variant sourced fromghcr.io/projectbluefin/bluefin-nvidia:stablerather than dakota's freedesktop-sdk base or lts's CentOS Stream base, so distro-specific PAM/nsswitch/authselect defaults might override or race with the drop-in)./etc/shadowor re-locks the account afterconfigure-live.shalready set it at build time.