Re: Device $dev is not a valid LUKS device.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Lol, whoops. I found out what was the cause of my problem. My mount
script wasn't functioning quite as it should, it tried to luksOpen the
iscsi device directly instead of the lvm volume. Argl.

Fixed my mount script, able to mount my backup volume after all. Nice.

Still, I think I'll make a backup of that header just to be sure, for
future use.

Kind regards,

Erik.


On 03/04/2013 03:18 PM, Erik Logtenberg wrote:
> Hi Arno,
> 
> Do you have some pointers on how I can investigate that?
> 
> In my previous setup, I had my luks device directly on top of my iscsi
> device. That worked great in the beginning, but after a power failure on
> the iscsi server, my volume was destroyed. Since the luks device was the
> only contents on the iscsi device, there was not much
> testing/investigating that I could do.
> 
> So I changed the setup: I created an LVM volume on my iscsi device, and
> the luks device inside the LVM volume. That way, I thought, I would at
> least know what part of the setup caused the malfunction. I mean, if the
> iscsi device itself would become corrupted, I wouldn't be able to
> activate the LVM volume anymore, but if dm-crypt were to make some
> mistake, I would expect to still be able to activate the LVM volume, but
> then not be able to read the luks volume.
> 
> Right? Well, it turns out I can still activate the LVM volume just fine,
> so apparently there are no media errors / overwritten headers, at least
> no overwritten LVM headers.
> But then, after I activated the LVM volume, dm-crypt can't read the luks
> volume. So apparently -only- the luks volume is damaged in some way.
> So... how can I investigate this further?
> 
> Kind regards,
> 
> Erik.
> 
> 
> On 03/04/2013 03:04 PM, Arno Wagner wrote:
>> Hi Erik,
>>
>> first, you can make a header-backup, see the FAQ. Second, you can 
>> investigate what destroys the header. The same thing could
>> well destroy a filesystem, RAID-superblock, etc.
>> Or put differently: Something is very, very wrong in
>> your set-up. Loss of the LUKS header can only happen if
>> einther the user does it (directly or indirectly) or
>> somethign is broken. 
>>
>> Arno
>>
>> On Mon, Mar 04, 2013 at 01:58:31PM +0100, Erik Logtenberg wrote:
>>> Hi all,
>>>
>>> I've been using dm-crypt for quite some years now, and every now and
>>> then I am very unpleasantly surprised by the message that my entire
>>> volume can no longer be read:
>>>
>>> Device /dev/disk/by-path/ip-foo.bar:mainstorage-lun-1 is not a valid
>>> LUKS device.
>>>
>>> In this case the iscsi server was rebooted while the volume was still
>>> mounted. The volume is used for making backups and no backups were
>>> currently made, so no actual writes got lost. Nevertheless after reboot
>>> it no longer recognizes my luks volume.
>>>
>>> I've had this kind of malice before and at that time was unable to fix
>>> it. So in the end I gave up, created a new luks volume and started from
>>> scratch.
>>>
>>> However I hope that is not how every future power failure is going to
>>> end up. Is there anything I can do to fix this volume or anything I can
>>> do to prevent such a simple event from causing such catastrophic results?
>>>
>>> Kind regards,
>>>
>>> Erik.
>>> _______________________________________________
>>> dm-crypt mailing list
>>> dm-crypt@xxxxxxxx
>>> http://www.saout.de/mailman/listinfo/dm-crypt
>>
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@xxxxxxxx
> http://www.saout.de/mailman/listinfo/dm-crypt
> 

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


[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux