StartOS 0.4.0.1 transient LUKS unlock failure after OS-level reboot — Diagnostic Mode, second diagnostic restart succeeds

StartOS Support
1

StartOS 0.4.0.1, x86_64 DIY server.

The server was fully operational. I issued a normal sudo reboot over SSH. On the following boot, StartOS entered Diagnostic Mode with:

Disk Management Error: No key available with this passphrase.

The failure occurred while opening the StartOS data drive (start_core::disk::main::mount_fs, cryptsetup luksOpen).

The same boot also logged early networking errors:

Error: Could not process rule: No such file or directory
add table ip startos

followed by:

NetworkManager returned no devices. Retrying...

No disk repair, LUKS modification, filesystem repair or password reset was performed.

I then selected Restart Server from the StartOS Diagnostic Mode UI. The next boot completed normally.

After the successful boot:

  • both LUKS volumes opened normally;

  • both Btrfs filesystems mounted normally;

  • btrfs device stats reports zero write/read/flush/corruption/generation errors on both volumes;

  • systemctl --failed reports 0 failed units;

  • all 10 StartOS service containers are running;

  • SSH, StartOS UI, Nextcloud and WireGuard connectivity are all operational.

Therefore the LUKS passphrase failure appears transient and reproducible only on the first boot after the OS-level reboot.

Since StartOS 0.4.0.1 includes the startos-restart.service graceful teardown path for host-level reboots, could this be a remaining shutdown/startup race?

I can provide the complete journal from the failed boot and the shutdown journal from the preceding boot.

2

Hi @yan, please do share the journals, specifically the shutdown journal from the prior boot (looking for whether startos-restart.service actually completed teardown before the reboot fired) and the full failed-boot journal from before the LUKS error through the nftables/NetworkManager errors.

3

Hi — I recovered the relevant systemd journal data from the incident. I’ll refer only to the native StartOS/systemd sources and boot IDs below.

One security note first: I cannot safely share the complete raw system journal unredacted. While reviewing it, I found that startd DEBUG logging contains unrelated sensitive application data in plaintext, including administrator credentials/tokens and SMTP credentials. Some values that are masked at the UI/application level are still present unmasked in the system journal.

For that reason, the entries below are copied from the journal but limited to the relevant shutdown/boot sequences. I can provide any additional time window you need after sanitizing it.

All times below are UTC.

StartOS build

From:

/usr/lib/startos/VERSION.txt
/usr/lib/startos/GIT_HASH.txt

VERSION
0.4.0.1

GIT HASH
fdb27c73db6ef280eae42dc6b01fd16de0c9b175

The relevant installed systemd unit is:

/usr/lib/systemd/system/startos-restart.service

with:

[Unit]
Description=StartOS graceful restart
DefaultDependencies=no
After=startd.service lxc.service lxc-monitord.service
Before=shutdown.target reboot.target kexec.target
Conflicts=reboot.target kexec.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
ExecStop=/usr/bin/start-cli server restart
TimeoutStopSec=120

1. Shutdown journal immediately preceding the failed boot

The persistent systemd boot immediately preceding the incident is:

Boot ID: a3895beeffc545e9935f0cc3bd746c8b
First entry: 2026-08-16 08:44:24 UTC
Last entry:  2026-08-21 14:37:14 UTC

This is therefore the journal corresponding to the shutdown you asked about.

The reboot was initiated with sudo reboot:

Aug 21 14:37:04 aeon sudo[781247]:
  start9 : TTY=pts/0 ; PWD=/home/start9 ; USER=root ;
  COMMAND=/usr/sbin/reboot

Aug 21 14:37:04 aeon systemd-logind[876]:
  The system will reboot now!

Aug 21 14:37:04 aeon systemd-logind[876]:
  System is rebooting.

Aug 21 14:37:04 aeon systemd[1]:
  Stopping startos-restart.service - StartOS graceful restart...

startd then performs the application/container teardown. Representative completion events include:

Aug 21 14:37:08 aeon startd[864]:
  ... Le service pour tor s'est terminé

Aug 21 14:37:08 aeon startd[864]:
  ... Le service pour jellyfin s'est terminé

Aug 21 14:37:08 aeon startd[864]:
  ... Le service pour filebrowser s'est terminé

Aug 21 14:37:08 aeon startd[864]:
  ... Le service pour nextcloud s'est terminé

Aug 21 14:37:08 aeon startd[864]:
  ... Le service pour gitea s'est terminé

The end of the StartOS teardown is:

Aug 21 14:37:11 aeon startd[864]:
... RpcContext est arrêté

Aug 21 14:37:11 aeon systemd[1]:
startos-restart.service: Deactivated successfully.

Aug 21 14:37:11 aeon systemd[1]:
Stopped startos-restart.service - StartOS graceful restart.

Aug 21 14:37:11 aeon systemd[1]:
Stopping startd.service - StartOS Daemon...

Aug 21 14:37:11 aeon systemd[1]:
Stopping lxc-monitord.service - LXC Container Monitoring Daemon...

Aug 21 14:37:11 aeon systemd[1]:
Stopping lxc.service - LXC Container Initialization and Autoboot Code...

Aug 21 14:37:11 aeon systemd[1]:
lxc-monitord.service: Deactivated successfully.

Aug 21 14:37:11 aeon systemd[1]:
Stopped lxc-monitord.service - LXC Container Monitoring Daemon.

Aug 21 14:37:11 aeon systemd[1]:
lxc.service: Deactivated successfully.

Aug 21 14:37:11 aeon systemd[1]:
Stopped lxc.service - LXC Container Initialization and Autoboot Code.

Immediately afterwards there is one potentially relevant LXCFS shutdown anomaly:

Aug 21 14:37:11 aeon lxcfs[878]:
  Running destructor lxcfs_exit

Aug 21 14:37:11 aeon systemd[1]:
  lxcfs.service: Main process exited, code=exited, status=1/FAILURE

Aug 21 14:37:11 aeon fusermount[782683]:
  /bin/fusermount: failed to unmount /var/lib/lxcfs: Invalid argument

Aug 21 14:37:11 aeon systemd[1]:
  lxcfs.service: Failed with result 'exit-code'.

Aug 21 14:37:11 aeon systemd[1]:
  startd.service: Deactivated successfully.

Aug 21 14:37:11 aeon systemd[1]:
  Stopped startd.service - StartOS Daemon.

The system does not reach the actual reboot target until roughly two seconds later:

Aug 21 14:37:13 aeon systemd[1]:
  Reached target shutdown.target - System Shutdown.

Aug 21 14:37:13 aeon systemd[1]:
  systemd-reboot.service: Deactivated successfully.

Aug 21 14:37:13 aeon systemd[1]:
  Finished systemd-reboot.service - System Reboot.

Aug 21 14:37:13 aeon systemd[1]:
  Reached target reboot.target - System Reboot.

So from the ordering in the system journal, startos-restart.service completed successfully at 14:37:11, before startd/LXC were stopped and about two seconds before reboot.target was reached at 14:37:13.

The lxcfs.service failure above occurred after startos-restart.service had already reported successful completion, but I included it in case it is relevant to the shutdown path you are investigating.

2. Failed boot / Diagnostic Mode

This is where there is an important limitation in what survived.

The journalctl --list-boots output saved immediately after recovery was:

IDX BOOT ID                          FIRST ENTRY                 LAST ENTRY
 -5 b92f36e0e32446d6be88b4fe888498b7 Sun 2026-08-09 20:37:22 UTC Sun 2026-08-09 21:05:48 UTC
 -4 0af9bd20cc234372916b481b4fee8e8f Sun 2026-08-09 21:06:50 UTC Mon 2026-08-10 07:28:10 UTC
 -3 196c667de2044673885d7453b2f2e1a2 Mon 2026-08-10 07:28:40 UTC Mon 2026-08-10 13:31:49 UTC
 -2 1bc085c02afc4b85857d36d96a28280b Mon 2026-08-10 13:45:32 UTC Sun 2026-08-16 08:43:44 UTC
 -1 a3895beeffc545e9935f0cc3bd746c8b Sun 2026-08-16 08:44:24 UTC Fri 2026-08-21 14:37:14 UTC
  0 2bc6cec1f86d4ccf8f43d112d980065b Fri 2026-08-21 15:04:34 UTC Fri 2026-08-21 15:24:09 UTC

There is no persisted boot ID between the shutdown at 14:37:14 and the recovered boot beginning at 15:04:34.

That missing interval is the boot which entered StartOS Diagnostic Mode.

On the Diagnostic Mode console I directly observed the terminal disk-management failure during cryptsetup luksOpen:

Disk management error - Aucune clé disponible avec cette phrase secrète

and there were also early nftables/NetworkManager errors during that boot.

However, because that Diagnostic Mode boot does not appear in journalctl --list-boots, I do not have a persistent systemd journal containing the exact sequence from before the LUKS error through those nftables/NetworkManager messages.

I don’t want to substitute similar messages from another successful boot and accidentally give you a false chronology.

After selecting Restart Server once from Diagnostic Mode, the next boot is:

Boot ID: 2bc6cec1f86d4ccf8f43d112d980065b
First entry: 2026-08-21 15:04:34 UTC

and that boot successfully opened the same LUKS volumes and returned StartOS to normal operation. No Repair, Rebuild, Forget Disk, LUKS header modification, keyslot modification, or password reset was performed between the failed boot and this successful boot.

If Diagnostic Mode or the initramfs stores its volatile journal somewhere other than the normal persistent systemd journal, please tell me the expected StartOS location and I can check whether anything from that failed boot is still recoverable.

And if you need a larger contiguous section from boot ID a3895beeffc545e9935f0cc3bd746c8b, give me the desired timestamp range and I can provide a sanitized extract.