[dm-crypt] LVM on LUKS: volumes missing

[dm-crypt] LVM on LUKS: volumes missing

[fauno]

[-- Attachment #1.1: Type: text/plain, Size: 671 bytes --]

Hi, maybe I'm too shocked but I couldn't find anything on this issue :)

I have a fully encrypted HD using the LVM on LUKS method from
ArchWiki[^0], with the LUKS header and key file on an external device.

Today I started having some disk failures (root remounted ro, xfs
partition giving errors), and after I decided to reboot to run fsck, I
can't find anything.

When the encrypted partition is opened, I don't see any errors, not even
on dmesg, but LVM can't find any volume.  They're just missing.

Is there anything I can do? Thanks!



[^0]:
https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#LVM_on_LUKS


-- 
.oÓ)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 585 bytes --]

[dm-crypt] LVM on LUKS: volumes missing

[fauno]

[-- Attachment #1.1: Type: text/plain, Size: 832 bytes --]

Hi, maybe I'm too shocked but I couldn't find anything on this issue :)

I have a fully encrypted HD using the LVM on LUKS method from
ArchWiki[^0], with the LUKS header and key file on an external device.

Today I started having some disk failures (root remounted ro, xfs
partition giving errors), and after I decided to reboot to run fsck, I
can't find anything.

When the encrypted partition is opened, I don't see any errors, not even
on dmesg, but LVM can't find any volume.  They're just missing.

Is there anything I can do? Thanks!

FWIW I had the same issue with another HD a few months back, though it
didn't had physical errors.  It didn't had anything important so I
wasn't worried.


[^0]:
https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#LVM_on_LUKS


-- 
.oÓ)




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 585 bytes --]

Re: [dm-crypt] LVM on LUKS: volumes missing

[Ondrej Kozina]

Hi fauno,

provided the driver was unlocked successfully it seems unrelated to 
cryptsetup/LUKS to me. Could we move the discussion to lvm mail list?

On 05/30/2016 11:54 PM, fauno wrote:
> Hi, maybe I'm too shocked but I couldn't find anything on this issue :)
>
> I have a fully encrypted HD using the LVM on LUKS method from
> ArchWiki[^0], with the LUKS header and key file on an external device.
>
> Today I started having some disk failures (root remounted ro, xfs
> partition giving errors), and after I decided to reboot to run fsck, I
> can't find anything.

Could you paste here output of pvscan -vvvv --cache 
/dev/mapper/insert_the_unlocked_device_name? Together with your 
/etc/lvm/lvm.conf file? If it's a device with rootfs we're talking about 
you will most probably have to extract /etc/lvm/lvm.conf file from 
initramfs image.

Well, generally, if disk sectors accommodating PV header are damaged, 
lvm2 won't recognise the device...

>
> When the encrypted partition is opened, I don't see any errors, not even
> on dmesg, but LVM can't find any volume.  They're just missing.
>
> Is there anything I can do? Thanks!
>
> FWIW I had the same issue with another HD a few months back, though it
> didn't had physical errors.  It didn't had anything important so I
> wasn't worried.

Ok, try same approach as above for this drive.

Regards
Ondrej

Re: [linux-lvm] [dm-crypt] LVM on LUKS: volumes missing

[Ondrej Kozina]

Hi fauno,

provided the driver was unlocked successfully it seems unrelated to 
cryptsetup/LUKS to me. Could we move the discussion to lvm mail list?

On 05/30/2016 11:54 PM, fauno wrote:
> Hi, maybe I'm too shocked but I couldn't find anything on this issue :)
>
> I have a fully encrypted HD using the LVM on LUKS method from
> ArchWiki[^0], with the LUKS header and key file on an external device.
>
> Today I started having some disk failures (root remounted ro, xfs
> partition giving errors), and after I decided to reboot to run fsck, I
> can't find anything.

Could you paste here output of pvscan -vvvv --cache 
/dev/mapper/insert_the_unlocked_device_name? Together with your 
/etc/lvm/lvm.conf file? If it's a device with rootfs we're talking about 
you will most probably have to extract /etc/lvm/lvm.conf file from 
initramfs image.

Well, generally, if disk sectors accommodating PV header are damaged, 
lvm2 won't recognise the device...

>
> When the encrypted partition is opened, I don't see any errors, not even
> on dmesg, but LVM can't find any volume.  They're just missing.
>
> Is there anything I can do? Thanks!
>
> FWIW I had the same issue with another HD a few months back, though it
> didn't had physical errors.  It didn't had anything important so I
> wasn't worried.

Ok, try same approach as above for this drive.

Regards
Ondrej

Re: [dm-crypt] LVM on LUKS: volumes missing

[Robert Nichols]

On 05/30/2016 04:54 PM, fauno wrote:
> Hi, maybe I'm too shocked but I couldn't find anything on this issue :)
>
> I have a fully encrypted HD using the LVM on LUKS method from
> ArchWiki[^0], with the LUKS header and key file on an external device.
>
> Today I started having some disk failures (root remounted ro, xfs
> partition giving errors), and after I decided to reboot to run fsck, I
> can't find anything.
>
> When the encrypted partition is opened, I don't see any errors, not even
> on dmesg, but LVM can't find any volume.  They're just missing.

Take a look at the decrypted volume with "hexedit -s". It should start 
out with mostly binary zeros with a little data including the ASCII 
string "LVM2" at the start of a few of the sectors. Starting at about 
the 10th sector there should be a lot of ASCII text. (It's a copy of the 
corresponding file in /etc/lvm/backup, though without the fancy formatting.)

If you're seeing random-appearing binary junk there, then the volume is 
not be decrypted properly. If it's just some of the early sectors that 
are clobbered and the text starting at the 10th sector is intact, then 
this should be recoverable.

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.

Re: [linux-lvm] [dm-crypt] LVM on LUKS: volumes missing

[fauno]

[-- Attachment #1.1: Type: text/plain, Size: 5083 bytes --]

On 31/05/16 04:53, Ondrej Kozina wrote:
> Hi fauno,
> 
> provided the driver was unlocked successfully it seems unrelated to
> cryptsetup/LUKS to me. Could we move the discussion to lvm mail list?

ok :)

> On 05/30/2016 11:54 PM, fauno wrote:
>> Hi, maybe I'm too shocked but I couldn't find anything on this issue :)
>>
>> I have a fully encrypted HD using the LVM on LUKS method from
>> ArchWiki[^0], with the LUKS header and key file on an external device.
>>
>> Today I started having some disk failures (root remounted ro, xfs
>> partition giving errors), and after I decided to reboot to run fsck, I
>> can't find anything.
> 
> Could you paste here output of pvscan -vvvv --cache
> /dev/mapper/insert_the_unlocked_device_name?

#libdm-config.c:863       Setting activation/monitoring to 0
#lvmcmdline.c:1093         Processing: pvscan -vvvv --cache
/dev/mapper/system
#lvmcmdline.c:1096         O_DIRECT will be used
#libdm-config.c:799       Setting global/locking_type to 1
#libdm-config.c:799       Setting global/wait_for_locks to 1
#locking/locking.c:242       File-based locking selected.
#libdm-config.c:768       Setting global/locking_dir to /run/lock/lvm
#libdm-config.c:863       Setting global/prioritise_write_locks to 1
#locking/file_locking.c:236       Locking /run/lock/lvm/P_global RB
#locking/file_locking.c:141         _do_flock /run/lock/lvm/P_global:aux WB
#locking/file_locking.c:51         _undo_flock /run/lock/lvm/P_global:aux
#locking/file_locking.c:141         _do_flock /run/lock/lvm/P_global RB
#pvscan.c:150     Using physical volume(s) on command line
#device/dev-cache.c:347         /dev/mapper/system: Added to device cache
#locking/file_locking.c:74       Unlocking /run/lock/lvm/P_global
#locking/file_locking.c:51         _undo_flock /run/lock/lvm/P_global
  Command failed with status code 5.

> Together with your
> /etc/lvm/lvm.conf file? If it's a device with rootfs we're talking about
> you will most probably have to extract /etc/lvm/lvm.conf file from
> initramfs image.

this is the lvm.conf from the initramfs (removed comments)


config {
	checks = 1
	abort_on_errors = 0
	profile_dir = "/etc/lvm/profile"
}
devices {
	dir = "/dev"
	scan = [ "/dev" ]
	obtain_device_list_from_udev = 1
	external_device_info_source = "none"
	cache_dir = "/etc/lvm/cache"
	cache_file_prefix = ""
	write_cache_state = 1
	sysfs_scan = 1
	multipath_component_detection = 1
	md_component_detection = 1
	fw_raid_component_detection = 0
	md_chunk_alignment = 1
	data_alignment_detection = 1
	data_alignment = 0
	data_alignment_offset_detection = 1
	ignore_suspended_devices = 0
	ignore_lvm_mirrors = 1
	disable_after_error_count = 0
	require_restorefile_with_uuid = 1
	pv_min_size = 2048
	issue_discards = 0
}
allocation {
	maximise_cling = 1
	use_blkid_wiping = 1
	wipe_signatures_when_zeroing_new_lvs = 1
	mirror_logs_require_separate_pvs = 0
	cache_pool_metadata_require_separate_pvs = 0
	thin_pool_metadata_require_separate_pvs = 0
}
log {
	verbose = 0
	silent = 0
	syslog = 1
	overwrite = 0
	level = 0
	indent = 1
	command_names = 0
	prefix = "  "
	activation = 0
	debug_classes = [ "memory", "devices", "activation", "allocation",
"lvmetad", "metadata", "cache", "locking", "lvmpolld" ]
}
backup {
	backup = 1
	backup_dir = "/etc/lvm/backup"
	archive = 1
	archive_dir = "/etc/lvm/archive"
	retain_min = 10
	retain_days = 30
}
shell {
	history_size = 100
}
global {
	umask = 077
	test = 0
	units = "h"
	si_unit_consistency = 1
	suffix = 1
	activation = 1
	proc = "/proc"
	etc = "/etc"
	locking_type = 1
	wait_for_locks = 1
	fallback_to_clustered_locking = 1
	fallback_to_local_locking = 1
	locking_dir = "/run/lock/lvm"
	prioritise_write_locks = 1
	abort_on_internal_errors = 0
	detect_internal_vg_cache_corruption = 0
	metadata_read_only = 0
	mirror_segtype_default = "raid1"
	raid10_segtype_default = "raid10"
	sparse_segtype_default = "thin"
	use_lvmetad = 1
	use_lvmlockd = 0
	system_id_source = "none"
	use_lvmpolld = 0
}
activation {
	checks = 0
	udev_sync = 1
	udev_rules = 1
	verify_udev_operations = 0
	retry_deactivation = 1
	missing_stripe_filler = "error"
	use_linear_target = 1
	reserved_stack = 64
	reserved_memory = 8192
	process_priority = -18
	raid_region_size = 512
	readahead = "auto"
	raid_fault_policy = "warn"
	mirror_image_fault_policy = "remove"
	mirror_log_fault_policy = "allocate"
	snapshot_autoextend_threshold = 100
	snapshot_autoextend_percent = 20
	thin_pool_autoextend_threshold = 100
	thin_pool_autoextend_percent = 20
	use_mlockall = 0
	monitoring = 1
	polling_interval = 15
	activation_mode = "degraded"
}
dmeventd {
	mirror_library = "libdevmapper-event-lvm2mirror.so"
	snapshot_library = "libdevmapper-event-lvm2snapshot.so"
	thin_library = "libdevmapper-event-lvm2thin.so"
}



> Well, generally, if disk sectors accommodating PV header are damaged,
> lvm2 won't recognise the device...

:(


-- 
http://utopia.partidopirata.com.ar/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 585 bytes --]

Re: [dm-crypt] LVM on LUKS: volumes missing

[fauno]

[-- Attachment #1.1: Type: text/plain, Size: 869 bytes --]

On 31/05/16 09:52, Robert Nichols wrote:

> Take a look at the decrypted volume with "hexedit -s". It should start
> out with mostly binary zeros with a little data including the ASCII
> string "LVM2" at the start of a few of the sectors. Starting at about
> the 10th sector there should be a lot of ASCII text. (It's a copy of the
> corresponding file in /etc/lvm/backup, though without the fancy
> formatting.)
> 
> If you're seeing random-appearing binary junk there, then the volume is
> not be decrypted properly. If it's just some of the early sectors that
> are clobbered and the text starting at the 10th sector is intact, then
> this should be recoverable.
> 

i've tried reading `hexedit` both on the closed and opened partition and
everything seems to be random junk.  `strings` also can't find anything
resembling LVM data.


-- 
:{


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 585 bytes --]

Re: [dm-crypt] LVM on LUKS: volumes missing

[fauno]

[-- Attachment #1.1: Type: text/plain, Size: 994 bytes --]

On 31/05/16 11:54, fauno wrote:
> On 31/05/16 09:52, Robert Nichols wrote:
> 
>> Take a look at the decrypted volume with "hexedit -s". It should start
>> out with mostly binary zeros with a little data including the ASCII
>> string "LVM2" at the start of a few of the sectors. Starting at about
>> the 10th sector there should be a lot of ASCII text. (It's a copy of the
>> corresponding file in /etc/lvm/backup, though without the fancy
>> formatting.)
>>
>> If you're seeing random-appearing binary junk there, then the volume is
>> not be decrypted properly. If it's just some of the early sectors that
>> are clobbered and the text starting at the 10th sector is intact, then
>> this should be recoverable.
>>
> 
> i've tried reading `hexedit` both on the closed and opened partition and
> everything seems to be random junk.  `strings` also can't find anything
> resembling LVM data.

i'm guessing silence means no one wants to give me the bad news :P


-- 
:D


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 585 bytes --]

Re: [linux-lvm] [dm-crypt] LVM on LUKS: volumes missing

[Ondrej Kozina]

On 05/31/2016 03:17 PM, fauno wrote:
>
> #libdm-config.c:863       Setting activation/monitoring to 0
> #lvmcmdline.c:1093         Processing: pvscan -vvvv --cache
> /dev/mapper/system
> #lvmcmdline.c:1096         O_DIRECT will be used
> #libdm-config.c:799       Setting global/locking_type to 1
> #libdm-config.c:799       Setting global/wait_for_locks to 1
> #locking/locking.c:242       File-based locking selected.
> #libdm-config.c:768       Setting global/locking_dir to /run/lock/lvm
> #libdm-config.c:863       Setting global/prioritise_write_locks to 1
> #locking/file_locking.c:236       Locking /run/lock/lvm/P_global RB
> #locking/file_locking.c:141         _do_flock /run/lock/lvm/P_global:aux WB
> #locking/file_locking.c:51         _undo_flock /run/lock/lvm/P_global:aux
> #locking/file_locking.c:141         _do_flock /run/lock/lvm/P_global RB
> #pvscan.c:150     Using physical volume(s) on command line
> #device/dev-cache.c:347         /dev/mapper/system: Added to device cache
> #locking/file_locking.c:74       Unlocking /run/lock/lvm/P_global
> #locking/file_locking.c:51         _undo_flock /run/lock/lvm/P_global
>   Command failed with status code 5.

This is very strange pvscan -vvvv output. Reading upstream lvm2 code, it 
doesn't make much sense to me. Most notably I can't see full error path. 
Could it be that pvscan -vvvv output was cut off somehow?

Regards
O.

Re: [linux-lvm] [dm-crypt] LVM on LUKS: volumes missing

[fauno]

[-- Attachment #1.1: Type: text/plain, Size: 351 bytes --]

On 02/06/16 10:22, Ondrej Kozina wrote:

> This is very strange pvscan -vvvv output. Reading upstream lvm2 code, it
> doesn't make much sense to me. Most notably I can't see full error path.
> Could it be that pvscan -vvvv output was cut off somehow?
> 
> Regards
> O.

that's exactly as it was printed

-- 
http://partidopirata.com.ar


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 585 bytes --]

Re: [linux-lvm] [dm-crypt] LVM on LUKS: volumes missing

[fauno]

[-- Attachment #1.1: Type: text/plain, Size: 532 bytes --]

On 02/06/16 10:39, fauno wrote:
> On 02/06/16 10:22, Ondrej Kozina wrote:
> 
>> This is very strange pvscan -vvvv output. Reading upstream lvm2 code, it
>> doesn't make much sense to me. Most notably I can't see full error path.
>> Could it be that pvscan -vvvv output was cut off somehow?
>>
>> Regards
>> O.
> 
> that's exactly as it was printed

fwiw, on dm-crypt list i was suggested to read the opened device with
`strings` and `hexedit`, but i couldn't find any lvm2 info


-- 
http://partidopirata.com.ar


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 585 bytes --]

Re: [linux-lvm] [dm-crypt] LVM on LUKS: volumes missing

[Zdenek Kabelac]

Dne 2.6.2016 v 15:39 fauno napsal(a):
> On 02/06/16 10:22, Ondrej Kozina wrote:
>
>> This is very strange pvscan -vvvv output. Reading upstream lvm2 code, it
>> doesn't make much sense to me. Most notably I can't see full error path.
>> Could it be that pvscan -vvvv output was cut off somehow?
>>
>> Regards
>> O.
>
> that's exactly as it was printed
>

Hi

This was not a full lvm2 -vvvv trace output - unless you would be using
a modified lvm2 source code base.

'pvscan -vvvv --cache device  &>out'


Also please provide full lvm2 package version eventually reference to package
with sources (and extra patches) (link).

Regards


Zdenek

Re: [linux-lvm] [dm-crypt] LVM on LUKS: volumes missing

[fauno]

[-- Attachment #1.1: Type: text/plain, Size: 817 bytes --]

On 02/06/16 11:50, Zdenek Kabelac wrote:

> 
> Hi
> 
> This was not a full lvm2 -vvvv trace output - unless you would be using
> a modified lvm2 source code base.
> 
> 'pvscan -vvvv --cache device  &>out'
> 
> 
> Also please provide full lvm2 package version eventually reference to
> package
> with sources (and extra patches) (link).


i can't confirm the version now, but it was lvm2 from trisquel belenos
(ubuntu trusty, lvm2 2.02.98 it seems[^0]), the hd was running archlinux
with latest lvm2 from repos.  i can try later with a more modern lvm2.

the pvscan output was exactly that though, i just selected it from the
terminal i was using.  see it finished with error 5, perhaps that's why
it's incomplete?


thanks!


[^0]: http://packages.trisquel.info/belenos/lvm2

-- 
:D


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 585 bytes --]

Re: [linux-lvm] [dm-crypt] LVM on LUKS: volumes missing

[Zdenek Kabelac]

Dne 2.6.2016 v 17:09 fauno napsal(a):
> On 02/06/16 11:50, Zdenek Kabelac wrote:
>
>>
>> Hi
>>
>> This was not a full lvm2 -vvvv trace output - unless you would be using
>> a modified lvm2 source code base.
>>
>> 'pvscan -vvvv --cache device  &>out'
>>
>>
>> Also please provide full lvm2 package version eventually reference to
>> package
>> with sources (and extra patches) (link).
>
>
> i can't confirm the version now, but it was lvm2 from trisquel belenos
> (ubuntu trusty, lvm2 2.02.98 it seems[^0]), the hd was running archlinux
> with latest lvm2 from repos.  i can try later with a more modern lvm2.
>
> the pvscan output was exactly that though, i just selected it from the
> terminal i was using.  see it finished with error 5, perhaps that's why
> it's incomplete?
>
>
> thanks!
>


So in your case any usage of lvmetad seems rather irrelevant.
(it's been freshly deployed daemon in that age for testing...)

It's unclear where have you get use_lvmpolld in your config file
since I'm sure it's not been in 2.02.98  (introduced around 2.02.120)

So are you mixing usage of various lvm2 versions ?


What does     'vgscan -vvvv'  shows on decrypted partition?

Also please provide output of:

dmsetup table
dmsetup status

And yeah  2.02.98 is somewhat out-of-date....
(Make sure your systems' & initramdisk version are somewhat matching)

Regards

Zdenek

Re: [dm-crypt] LVM on LUKS: volumes missing

[Robert Nichols]

On 06/02/2016 07:57 AM, fauno wrote:
> On 31/05/16 11:54, fauno wrote:
>> On 31/05/16 09:52, Robert Nichols wrote:
>>
>>> Take a look at the decrypted volume with "hexedit -s". It should start
>>> out with mostly binary zeros with a little data including the ASCII
>>> string "LVM2" at the start of a few of the sectors. Starting at about
>>> the 10th sector there should be a lot of ASCII text. (It's a copy of the
>>> corresponding file in /etc/lvm/backup, though without the fancy
>>> formatting.)
>>>
>>> If you're seeing random-appearing binary junk there, then the volume is
>>> not be decrypted properly. If it's just some of the early sectors that
>>> are clobbered and the text starting at the 10th sector is intact, then
>>> this should be recoverable.
>>>
>>
>> i've tried reading `hexedit` both on the closed and opened partition and
>> everything seems to be random junk.  `strings` also can't find anything
>> resembling LVM data.
>
> i'm guessing silence means no one wants to give me the bad news :P

By any chance did you reboot into a kernel different from the one that 
was running before? If so, try the old kernel. In the past, there was a 
kernel change that affected a non-default LUKS option (whirlpool hash). 
It's a long shot, but so is anything else at this point.

Let's look at about the only other thing that's correctable, and that 
would be a damaged partition table that has the partition starting in 
the wrong place. Does the output from "fdisk -l" for that drive look 
reasonable? If you look at the sectors with "hexedit -s", does the 
randomness start with the sector where that partition is supposed to begin?

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.

Re: [dm-crypt] LVM on LUKS: volumes missing

[Arno Wagner]

One thing is that these problems are pretty hard to debug.
Another is that LVM massively complicates things.

Now, if the LUKS container opens cleanly, anything
in it should be decrypted correctly (if it is LVM
atop of LUKS) and decryption with the wrong key is
not actually a possibility. 

That also means you should be able to use LVM
recovery techniques (I assume they exist) on this.

Unfortunately, I cannot help you with LVM as I do not use 
it. I consider it a badly engineered, overly complicated 
thing that decreases reliablity and makes problem 
diagnostics very hard.  Unfortunately, it provides some
increases in convenience and that seems to be all most people
care about, atleast until they are confronted with the hard
realities of reliable engineering, namely that KISS
is more important than any other concern. As LVM
violates that (along with the new RAID superblock
formats, udev, systemd and some other engineering 
abominations that have found their way into mainstream
Linux recently) I do not tolerate LVM on any of my
systems. 

Regards,
Arno


On Thu, Jun 02, 2016 at 14:57:57 CEST, fauno wrote:
> On 31/05/16 11:54, fauno wrote:
> > On 31/05/16 09:52, Robert Nichols wrote:
> > 
> >> Take a look at the decrypted volume with "hexedit -s". It should start
> >> out with mostly binary zeros with a little data including the ASCII
> >> string "LVM2" at the start of a few of the sectors. Starting at about
> >> the 10th sector there should be a lot of ASCII text. (It's a copy of the
> >> corresponding file in /etc/lvm/backup, though without the fancy
> >> formatting.)
> >>
> >> If you're seeing random-appearing binary junk there, then the volume is
> >> not be decrypted properly. If it's just some of the early sectors that
> >> are clobbered and the text starting at the 10th sector is intact, then
> >> this should be recoverable.
> >>
> > 
> > i've tried reading `hexedit` both on the closed and opened partition and
> > everything seems to be random junk.  `strings` also can't find anything
> > resembling LVM data.
> 
> i'm guessing silence means no one wants to give me the bad news :P
> 
> 
> -- 
> :D
> 




> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt


-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] LVM on LUKS: volumes missing

[Robert Nichols]

On 06/03/2016 04:42 PM, Arno Wagner wrote:
> One thing is that these problems are pretty hard to debug.
> Another is that LVM massively complicates things.
>
> Now, if the LUKS container opens cleanly, anything
> in it should be decrypted correctly (if it is LVM
> atop of LUKS) and decryption with the wrong key is
> not actually a possibility.
>
> That also means you should be able to use LVM
> recovery techniques (I assume they exist) on this.
>
> Unfortunately, I cannot help you with LVM as I do not use
> it. I consider it a badly engineered, overly complicated
> thing that decreases reliablity and makes problem
> diagnostics very hard.

If the ASCII strings "LABELONE" and "LVM2" cannot be seen in the first 
few sectors of the volume, then that volume is either overwritten or not 
being decrypted correctly.  LVM keeps quite a bit of easily recognized 
ASCII data in the volume header.

In this case the fragile link seems to be the LUKS detached header, as I 
believe there is nothing to associate that header with a device and 
precise starting point for the payload. Yes, there is a check that the 
master key was reconstructed correctly. Now the question is what, if 
anything, does this key decrypt.

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.

Re: [dm-crypt] LVM on LUKS: volumes missing

[Arno Wagner]

On Sat, Jun 04, 2016 at 00:46:53 CEST, Robert Nichols wrote:
> On 06/03/2016 04:42 PM, Arno Wagner wrote:
> >One thing is that these problems are pretty hard to debug.
> >Another is that LVM massively complicates things.
> >
> >Now, if the LUKS container opens cleanly, anything
> >in it should be decrypted correctly (if it is LVM
> >atop of LUKS) and decryption with the wrong key is
> >not actually a possibility.
> >
> >That also means you should be able to use LVM
> >recovery techniques (I assume they exist) on this.
> >
> >Unfortunately, I cannot help you with LVM as I do not use
> >it. I consider it a badly engineered, overly complicated
> >thing that decreases reliablity and makes problem
> >diagnostics very hard.
> 
> If the ASCII strings "LABELONE" and "LVM2" cannot be seen in the
> first few sectors of the volume, then that volume is either
> overwritten or not being decrypted correctly.  LVM keeps quite a bit
> of easily recognized ASCII data in the volume header.
> 
> In this case the fragile link seems to be the LUKS detached header,
> as I believe there is nothing to associate that header with a device
> and precise starting point for the payload. Yes, there is a check
> that the master key was reconstructed correctly. Now the question is
> what, if anything, does this key decrypt.

That is the one thing with a detached header: As the sector
number goes into the decryption, decryption must start at the
right place. If it does, it will becorrect with LUKS. If not,
"random" data should result with XTS mode, I agree.

Now, in theory it would be possible to try each possible offset 
from the start of the device (depends on how the partition
for the LUKS container was created), until some (later) part
of the decrypted data has some deviation from uniform 
distribution in byte-counts.
 
Arno

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] LVM on LUKS: volumes missing

[fauno]

[-- Attachment #1.1: Type: text/plain, Size: 1328 bytes --]

On 04/06/16 05:06, Arno Wagner wrote:

>> If the ASCII strings "LABELONE" and "LVM2" cannot be seen in the
>> first few sectors of the volume, then that volume is either
>> overwritten or not being decrypted correctly.  LVM keeps quite a bit
>> of easily recognized ASCII data in the volume header.
>>
>> In this case the fragile link seems to be the LUKS detached header,
>> as I believe there is nothing to associate that header with a device
>> and precise starting point for the payload. Yes, there is a check
>> that the master key was reconstructed correctly. Now the question is
>> what, if anything, does this key decrypt.
> 
> That is the one thing with a detached header: As the sector
> number goes into the decryption, decryption must start at the
> right place. If it does, it will becorrect with LUKS. If not,
> "random" data should result with XTS mode, I agree.
> 
> Now, in theory it would be possible to try each possible offset 
> from the start of the device (depends on how the partition
> for the LUKS container was created), until some (later) part
> of the decrypted data has some deviation from uniform 
> distribution in byte-counts.

Hi! Thanks for all the feedback.  I ran out of time for recovering this,
but as soon as I can I'll get back with the results :)

-- 
:>


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 585 bytes --]