second ignition and filesystem reuse-semantics: LUKS breaks reuse

[aanno]

Describe the enhancement

filesystem reuse

I want to reuse filesystem(s) with coreos. For testing this, I tried a second ignition by providing 'ignition.firstboot' as kernel parameter on boot.

The relevant documentation that this scenario might be possible is:

• force Ignition
  • recreate /boot/ignition.firstboot file or
  • start with kernel parameter ignition.firstboot
  • details: firstboot support on read-only root file systems
• some rules for running ignition more than once
  • don't use 'wipe*'
  • use LUKS only with 'key_file' (no clevis nor tpm!)
  • don't use RAID
  • don't use append
  • When writing files in persistent storage, set overwrite to true to avoid Ignition failures
• Filesystem-Reuse Semantics

problems running ignition more than once

At present LUKS hinders the second ignition with the following error:

Jan 04 19:28:45 ignition[1509]: Ignition failed: creating crypttab entries: adding luks related files: error creating /sysroot/etc/luks/luks-backup: error creating file "/sysroot/etc/luks/luks-backup": A file exists there already and overwrite is false
Jan 04 19:31:08 systemd[1]: ignition-remount-sysroot.service: Failed with result 'exit-code'.
Jan 04 19:31:08 systemd[1]: Failed to start ignition-remount-sysroot.service - Remount /sysroot read-write for Ignition.

In addition after this problem, the (installed) coreos is no longer useable:

Please enter passphrase for disk var (luks-var): (press TAB for no echo)

Even if you've got a backup of the /etc/luks/* file, providing them leads to

an 04 19:56:31 ignition[1539]: Ignition failed: creating crypttab entries: adding luks related files: error creating /sysroot/etc/luks/luks-backup: error creating file "/sysroot/etc/luks/luks-backup": A file exists there already and overwrite is false

proposed solution/enhancement

Allow LUKS reuse. Overwrite should be true for path containing /sysroot/etc/luks. Otherwise, filesystem reuse is not possible when using LUKS.

System details

I tried this with:

• fedora-coreos-41.20241122.3.0
• on libvirt (virt-manager)

Additional information

No response