Unable to retrieve last logical volume descriptor

[jthomme1]

Hello,
I am trying to use your tool to access a FileVault2 partition.

I have the EncryptedRoot.plist.wipekey as well as the password.

But when trying to access the volume from Linux, I get the following:

$: sudo fvdemount -v -e EncryptedRoot.plist.wipekey -p redacted /dev/sdc2 /mnt/tmp
fvdemount 20231029

Unable to open: /dev/sdc2.
libfvde_encrypted_metadata_read_type_0x0305: unable to retrieve last logical volume descriptor.
libfvde_encrypted_metadata_read_from_file_io_handle: unable to read metadata block type 0x0305.
libfvde_internal_volume_open_read: unable to read encrypted metadata 1.
libfvde_volume_open_physical_volume_files_file_io_pool: unable to read physical volume files from file IO pool.
mount_handle_open: unable to open physical volume files.

Do you have any clue what could be the problem?

I am thankful for any hints.

[joachimmetz]

The format is not fully know this might be unsupported format cases, can you provide debug output? See https://github.com/libyal/libfvde/wiki/Troubleshooting#verbose-and-debug-output

[jthomme1]

Here is the debug output. Let me know if I can do anything to help you.
stderr.txt
Thanks in advance for your time and effort.

[zzggbb]

I'm having the identical problem of @jthomme1:

$ sudo fvdemount -e EncryptedRoot.plist.wipekey -p REDACTED /dev/sde2 /mnt/fuse
fvdemount 20231128

libfvde_encrypted_metadata_read_type_0x0305: unable to retrieve last logical volume descriptor.
libfvde_encrypted_metadata_read_from_file_io_handle: unable to read metadata block type 0x0305.
libfvde_internal_volume_open_read: unable to read encrypted metadata 1.
libfvde_internal_volume_open_read: unable to read physical volume files from file IO pool.
Unable to open: /dev/sde2.
libfvde_encrypted_metadata_read_type_0x0305: unable to retrieve last logical volume descriptor.
libfvde_encrypted_metadata_read_from_file_io_handle: unable to read metadata block type 0x0305.
libfvde_internal_volume_open_read: unable to read encrypted metadata 1.
libfvde_volume_open_physical_volume_files_file_io_pool: unable to read physical volume files from file IO pool.
mount_handle_open: unable to open physical volume files.

Here is my debug output:
output.txt

[zzggbb]

@jthomme1 Did you ever figure out a way to mount your drive?

[jthomme1]

@jthomme1 Did you ever figure out a way to mount your drive?

Hey @zzggbb,
I think in the end I resorted to another MacOS machine (although I do not remember exactly as this was some time ago) and it just worked with the built-in mounting.

[Miriup]

@jthomme1 Did you ever figure out a way to mount your drive?

I have the same issue with my volume and have found out this happens because the metadata blocks on my volume aren't in the order libfvde expects. The real reason why libfvde expects a certain order is we haven't figured out yet how to determine what volume a payload block belongs to and in most configuratios we can just expect that the part that defines logical block mappings follows the block that defines physical block mappings. But in some cases this assumption seems not be true. In my case I enabled encryption as an afterthought and I can still see old metadata blocks indicating how the encryption has been applied incrementally. Maybe it's the same in your case. As a result the order of these metadata blocks is non linear and the above assumption doesn't work out.
The FVDE can act like a giant snapshot device which makes it non-trivial to figure this one out. Once we can properly support 2 logical volumes within a FVDE structure this ordering would not be an issue anymore.
I have started implement tools that would allow me to discover the information we do not have yet, but other priorities have taken over. Unless more priorities come up that I don't anticipate, I should be able to fix this in 2025.