From 2fb17559a4b7ffbad99ccc992e289fd9f56aff03 Mon Sep 17 00:00:00 2001 From: Kevin Wang Date: Mon, 26 Jan 2026 15:21:14 +0000 Subject: [PATCH] Fix encrypted ZFS persistence issue Problem: VMs with encrypted ZFS storage were reformatting the disk on every reboot, even with KMS or local key provider enabled. Root cause: The is_disk_initialized() check required both LUKS header AND zpool detection for encrypted ZFS (line 1057-1058). However, zpool import is attempted on the raw encrypted device (/dev/vdb1) before LUKS is opened, which always fails since the ZFS pool is inside the LUKS container. Solution: For any encrypted filesystem (ext4 or ZFS), only check for LUKS header presence, since the actual filesystem can only be detected after opening LUKS. This aligns encrypted ZFS handling with encrypted ext4, which was already using this approach. Testing: Verified that ext4 encrypted storage persists correctly with KMS key provider. ZFS testing pending after build completes. --- dstack-util/src/system_setup.rs | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/dstack-util/src/system_setup.rs b/dstack-util/src/system_setup.rs index 09da697b..e7701124 100644 --- a/dstack-util/src/system_setup.rs +++ b/dstack-util/src/system_setup.rs @@ -1053,11 +1053,12 @@ impl<'a> Stage0<'a> { } }; - // For encrypted ZFS, need both LUKS header AND zpool to exist - let initialized = if opts.storage_encrypted && opts.storage_fs == FsType::Zfs { - has_luks && has_fs + // For encrypted filesystems, we can only detect the filesystem after LUKS is opened + // So we rely on LUKS header presence as the indicator for both ext4 and ZFS + let initialized = if opts.storage_encrypted { + has_luks } else { - has_luks || has_fs + has_fs }; if !initialized {