dm-verity snapshot restore

[Bogdan Chifor]

Hello,

I am using cuttlefish crosvm and trying to do a restore from snapshot. Sometimes, I can see that device is being rebooted after successful restore from snapshot with the following dm-verity error:

[ 2723.241203] libprocessgroup: Still waiting on process(es) to exit for cgroup /sys/fs/cgroup/uid_1020/pid_606 after 0 ms^M
[ 2723.246324] libprocessgroup: Removed cgroup /sys/fs/cgroup/uid_1020/pid_606^M
[ 2723.247391] binder: undelivered death notification, 000070afa0f2b110^M
[ 2723.247770] binder: send failed reply for transaction 100142 to 744:911^M
[ 2723.249311] init: Sending signal 15 to service 'vendor.confirmationui_default' (pid 572) process group...^M
[ 2723.255775] ACPI: PM: Preparing to enter system sleep state S5^M
[ 2723.256553] kvm: exiting hardware virtualization^M
[ 2723.256801] reboot: Restarting system with command 'dm-verity device corrupted'^M
[ 2723.257067] reboot: machine restart^M

or

[ 861.316061] device-mapper: verity-fec: 254:0: FEC: recursion too deep [ 861.316322] device-mapper: verity: 254:0: metadata block 172300 is corrupted [ 861.348338] ACPI: PM: Preparing to enter system sleep state S5 [ 861.349098] kvm: exiting hardware virtualization [ 861.349285] reboot: Restarting system with command 'dm-verity device corrupted' [ 861.349498] reboot: machine restart

Do you happen to experience anything similar?

Best regards,

Bogdan Chifor.

[Bogdan Chifor]

Yes, using cvd suspend and then cvd snapshot_take. In most cases the snapshot can be resumed.

I don't have any overlays (starting the cvd with -use_overlay=false), so all the dm-verity partitions should be read-only, unless I am missing something. Between snapshot take and restore, disk files are not changed.

On Fri, Jul 25, 2025 at 1:00 AM Frederick Mayle <fma...@google.com> wrote:

Can you share how you are performing the snapshot and restore steps? Are you using cuttlefish's snapshot_util_cvd command?

My first guess for a dm-verity error is that the underlying disk image contents changed between when the snapshot and restore happened. The disk image contents aren't part of the snapshot (except for cuttlefish's copy-on-write overlays). Cuttlefish does some basic checks to detect if the disk image changed, but might not catch everything.

--
You received this message because you are subscribed to the Google Groups "crosvm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to crosvm-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/crosvm-dev/8aabae76-0a57-4745-85ba-5d5c386c7d7an%40chromium.org.

[Frederick Mayle]

Can you share how you are performing the snapshot and restore steps? Are you using cuttlefish's snapshot_util_cvd command?

My first guess for a dm-verity error is that the underlying disk image contents changed between when the snapshot and restore happened. The disk image contents aren't part of the snapshot (except for cuttlefish's copy-on-write overlays). Cuttlefish does some basic checks to detect if the disk image changed, but might not catch everything.

On Thu, Jul 24, 2025 at 10:32 AM Bogdan Chifor <chiforb...@gmail.com> wrote:

--

[Frederick Mayle]

I'm not sure about the status of `cvd suspend/snapshot_take`. I know `snapshot_util_cvd --subcmd=snapshot_take --auto_suspend --snapshot_path=$SOME_PATH` should work.

> I don't have any overlays (starting the cvd with -use_overlay=false), so all the dm-verity partitions should be read-only

I'm not familiar with how CF behaves when overlays are off. My vague memory is that it would just modify the underlying disk images and we never tested how it interacts with snapshotting.

dm-verity is readonly in general IIUC, so I think you are right they shouldn't be modified unless done so outside the VM. OTOH, other disk images, like those used for the /data/ partition, will almost certainly be modified if you let the vCPU run after snapshotting, or restore the snapshot multiple times. Our workaround for that was to snapshot the overlays.