Sorry I have no complete solution for you, only a suggestion for a workaround at the end and some things I found out while poking around.
I was looking for how to mount the encrypted.block
file I found but I can't find details except this bug report. There are no details about the encrypted storage in disk-format either but it looks like a very similar question has been asked before in Mount encrypted ChromeOS partition in Chrubuntu. I ran file
on the encrypted.block
file after mounting the stateful partition, but it just said data
on my GalliumOS install. It looks like the encrypted storage on the stateful partition just uses ecryptfs in a particular way that I haven't seen before (though I do use ecryptfs for more than just per user encrypted home directories). It could also be possible that TPM is used to decrypt the partition, which would make sense, but I'm not sure about that.
Here are the important parts from mount with ecryptfs_sig and ecryptfs_fnek_sig edited:
/dev/mmcblk0p1 on /mnt/stateful_partition type ext4 (rw,nosuid,nodev,noexec,relatime,seclabel,commit=600,data=ordered)
/dev/mmcblk0p1 on /home type ext4 (rw,nosuid,nodev,noexec,relatime,seclabel,commit=600,data=ordered)
/dev/mapper/encstateful on /mnt/stateful_partition/encrypted type ext4 (rw,nosuid,nodev,noexec,relatime,seclabel,discard,commit=600,data=ordered)
/dev/mapper/encstateful on /var type ext4 (rw,nosuid,nodev,noexec,relatime,seclabel,discard,commit=600,data=ordered)
/dev/mapper/encstateful on /home/chronos type ext4 (rw,nosuid,nodev,noexec,relatime,seclabel,discard,commit=600,data=ordered)
/dev/mmcblk0p1 on /usr/local type ext4 (rw,nodev,relatime,seclabel,commit=600,data=ordered)
/home/.shadow/0b00d80cb6b214a4a8f2d0094a1de796a15a9623/vault on /home/.shadow/0b00d80cb6b214a4a8f2d0094a1de796a15a9623/mount type ecryptfs (rw,nosuid,nodev,noexec,relatime,seclabel,ecryptfs_sig=1234567890abcdef,ecryptfs_fnek_sig=f1234567890abcde,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs)
/home/.shadow/0b00d80cb6b214a4a8f2d0094a1de796a15a9623/vault on /home/chronos/user type ecryptfs (rw,nosuid,nodev,noexec,relatime,seclabel,ecryptfs_sig=1234567890abcdef,ecryptfs_fnek_sig=f1234567890abcde,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs)
/home/.shadow/0b00d80cb6b214a4a8f2d0094a1de796a15a9623/vault on /home/user/0b00d80cb6b214a4a8f2d0094a1de796a15a9623 type ecryptfs (rw,nosuid,nodev,noexec,relatime,seclabel,ecryptfs_sig=1234567890abcdef,ecryptfs_fnek_sig=f1234567890abcde,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs)
/home/.shadow/0b00d80cb6b214a4a8f2d0094a1de796a15a9623/vault on /home/chronos/u-0b00d80cb6b214a4a8f2d0094a1de796a15a9623 type ecryptfs (rw,nosuid,nodev,noexec,relatime,seclabel,ecryptfs_sig=1234567890abcdef,ecryptfs_fnek_sig=f1234567890abcde,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs)
/home/.shadow/0b00d80cb6b214a4a8f2d0094a1de796a15a9623/vault on /home/root/0b00d80cb6b214a4a8f2d0094a1de796a15a9623 type ecryptfs (rw,nosuid,nodev,noexec,relatime,seclabel,ecryptfs_sig=1234567890abcdef,ecryptfs_fnek_sig=f1234567890abcde,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs)
And here is the output of lsblk:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 1 7.5G 0 disk
└─sda1 8:1 1 7.5G 0 part /media/removable/SANDISK
loop0 7:0 0 581.6M 0 loop
└─encstateful 253:1 0 581.6M 0 dm /mnt/stateful_partition/encrypted
loop1 7:1 0 402.3M 1 loop /opt/google/containers/android/rootfs/root
loop2 7:2 0 48.8M 1 loop /opt/google/containers/android/rootfs/root/vendor
loop3 7:3 0 4K 1 loop /opt/google/containers/arc-removable-media/mountpoints/container-root
loop4 7:4 0 4K 1 loop /opt/google/containers/arc-sdcard/mountpoints/container-root
loop5 7:5 0 4K 1 loop /opt/google/containers/arc-obb-mounter/mountpoints/container-root
zram0 252:0 0 2.8G 0 disk [SWAP]
mmcblk0rpmb 179:48 0 4M 0 disk
mmcblk0boot0 179:16 0 4M 1 disk
mmcblk0boot1 179:32 0 4M 1 disk
mmcblk0 179:0 0 29.1G 0 disk
├─mmcblk0p1 179:1 0 2G 0 part /mnt/stateful_partition
├─mmcblk0p2 179:2 0 16M 0 part
├─mmcblk0p3 179:3 0 2G 0 part
├─mmcblk0p4 179:4 16M 0 part
├─mmcblk0p5 179:5 2G 0 part
├─mmcblk0p6 179:6 16M 0 part
├─mmcblk0p7 179:7 23G 0 part
├─mmcblk0p8 179:8 16M 0 part /usr/share/oem
├─mmcblk0p9 179:9 512B 0 part
├─mmcblk0p10 179:10 512B 0 part
├─mmcblk0p11 179:11 8M 0 part
└─mmcblk0p12 179:12 16M 0 part
On second thought there is something you can try: dump the entire disk including the partition table (you may use gnome-disks from live media), get another computer and a spare disk to run ArnoldTheBbat's Chromium OS special builds, check that it runs without flaws and then copy your stateful partition (usually the biggest partition) over the stateful partition of this test setup. This should work in theory to recover your files, but I don't know which bug you have run into here.