[dm-crypt] Help! Command failed: /dev/sdd1 is not a LUKS partition

[dm-crypt] Help! Command failed: /dev/sdd1 is not a LUKS partition

[M Thomas Frederiksen]

[-- Attachment #1: Type: text/plain, Size: 2781 bytes --]

Hi Folks,

I have four disks.  I installed kubuntu 9.10 alt amd64, using /dev/sda,
/dev/sdb, and /dev/sdc.  I had long used /dev/sdd1 (single partition for the
whole disk) as luks.  I kept all my backups on that disk, and didn't touch
it at all during the instillation.  The installation program said that
/dev/sdd1 was LVM, which I thot was odd, however I've used LVM in the past,
so that partition was likely still marked LVM when I started using it as
straight luks.  I didn't use or set up LVM at all on any of the disks (hence
didn't go into the settup LVM part of the install program).

Post install when I run cryptsetup:

thomas@Aristotle:~$ sudo cryptsetup luksOpen /dev/sdd1 backup_crypt
Enter LUKS passphrase:
Command failed: /dev/sdd1 is not a LUKS partition
thomas@Aristotle:~$ sudo cryptsetup luksDump /dev/sdd1
Command failed: /dev/sdd1 is not a LUKS partition
thomas@Aristotle:~$ shoot me now
shoot: command not found

There are three things I can think of:

   1. The install program wrote out a new partition table, changing the
   partition type flag.
   2. The /dev/sdXs were named differently, and I've scribbled all over what
   was /dev/sdd1.
   3. Mandriva was unaffected by the problem, but Kubuntu is.

In the first case I think I have hope, what steps should I take?  In the
second case, I think I'm SOL.  I tried using the Mandriva Live CD, and got
the same result, so the second & third cases are ruled out.

===========
I have another weird, lessor problem:

At boot time, my new luks partition /dev/sda3, says "command failed, bad key
or options" for all three tries then boots (because it is opened and just
doesn't know it).  I tested this by not giving it the passphrase, in which
case it won't boot, but if I type the passphrase right the first time, and
blow off the other 2 tries, it boots.  I thot this might be a btrfs problem,
so post boot, I formatted an empty luks partition as btrfs, and tried
unlocking it.  No problem.  To get root btrfs, I followed the instructions
here: http://ubuntuforums.org/showthread.php?t=1389279

============
Last issue:

I've got more drives to add to btrfs, but how will it know it needs to
unlock the other drives to open the root partition? It's only unlocking
/dev/sda3 during boot, because /dev/sdb2 and /dev/sdc2 aren't being used
(even tho, I've got them in the crypttab). From the fstab

/dev/mapper/sda3_crypt / btrfs error=remount-ro,compress 0 1

it looks like it just needs the one. Also, they all have the same
passphrase, so I'd like to unlock them all at once... which mandriva did,
but kubuntu doesn't. Ideas?

-- 
Cheers,
~Thomas


Samuel Goldwyn<http://www.brainyquote.com/quotes/authors/s/samuel_goldwyn.html>
- "I'm willing to admit that I may not always be right, but I am never
wrong."

[-- Attachment #2: Type: text/html, Size: 4651 bytes --]

Re: [dm-crypt] Help! Command failed: /dev/sdd1 is not a LUKS partition

[Arno Wagner]

On Wed, Feb 10, 2010 at 12:00:39PM -0500, M Thomas Frederiksen wrote:
> Last issue:
> 
> I've got more drives to add to btrfs, but how will it know it needs to
> unlock the other drives to open the root partition? It's only unlocking
> /dev/sda3 during boot, because /dev/sdb2 and /dev/sdc2 aren't being used
> (even tho, I've got them in the crypttab). From the fstab
> 
> /dev/mapper/sda3_crypt / btrfs error=remount-ro,compress 0 1
> 
> it looks like it just needs the one. Also, they all have the same
> passphrase, so I'd like to unlock them all at once... which mandriva did,
> but kubuntu doesn't. Ideas?

There is no "drive unlocking", what happens is that a new
device is created which just happens to contain a decrypted
version of the encrypted one. They are not associated in any
way (except by an LVM mapping that is typically not understood
by applications).


So either there is a corresponding device in /dev/mapper or 
not, btrfs does not care where the device comes from. And 
if you have not done the cryptsetup, then there is no device 
in /dev/mapper and btrfs cannot use a non-existent device.

Arno

-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

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] Help! Command failed: /dev/sdd1 is not a LUKS partition

[M Thomas Frederiksen]

[-- Attachment #1: Type: text/plain, Size: 1638 bytes --]

On Wed, Feb 10, 2010 at 12:14, Arno Wagner <arno@wagner.name> wrote:

> On Wed, Feb 10, 2010 at 12:00:39PM -0500, M Thomas Frederiksen wrote:
>
> There is no "drive unlocking", what happens is that a new
> device is created which just happens to contain a decrypted
> version of the encrypted one. They are not associated in any
> way (except by an LVM mapping that is typically not understood
> by applications).
>
>
> So either there is a corresponding device in /dev/mapper or
> not, btrfs does not care where the device comes from. And
> if you have not done the cryptsetup, then there is no device
> in /dev/mapper and btrfs cannot use a non-existent device.
>

The point is that once the other volumes are added, btrfs will need three
devices in /dev/mapper:

   1. /dev/mapper/sda3_crypt
   2. /dev/mapper/sdb2_crypt
   3. /dev/mapper/sdc2_crypt

However, during the boot process, /dev/mapper/sda3_crypt is the only device
being created.  If I do a blkid, I get:

/dev/mapper/sda3_crypt: UUID="e0948aa0-efab-4449-938d-6d74b6ccbf93"
UUID_SUB="b3b1e4cc-ca0e-44ba-be35-32405b20025b" TYPE="btrfs"

So would I change the fstab from:

/dev/mapper/sda3_crypt / btrfs error=remount-ro,compress 0 1

to:

UUID_SUB=b3b1e4cc-ca0e-44ba-be35-32405b20025b / btrfs
error=remount-ro,compress 0 1

?  Would that be the same UUID_SUB for other /dev/mapper/sdX_crypts?  And
would grub / boot scripts be smart enough to figure out that it needs all
three device files?

-- 
Cheers,
~Thomas


Samuel Goldwyn<http://www.brainyquote.com/quotes/authors/s/samuel_goldwyn.html>
- "I'm willing to admit that I may not always be right, but I am never
wrong."

[-- Attachment #2: Type: text/html, Size: 2150 bytes --]

Re: [dm-crypt] Help! Command failed: /dev/sdd1 is not a LUKS partition

[Arno Wagner]

On Wed, Feb 10, 2010 at 12:43:55PM -0500, M Thomas Frederiksen wrote:
> On Wed, Feb 10, 2010 at 12:14, Arno Wagner <arno@wagner.name> wrote:
> 
> > On Wed, Feb 10, 2010 at 12:00:39PM -0500, M Thomas Frederiksen wrote:
> >
> > There is no "drive unlocking", what happens is that a new
> > device is created which just happens to contain a decrypted
> > version of the encrypted one. They are not associated in any
> > way (except by an LVM mapping that is typically not understood
> > by applications).
> >
> >
> > So either there is a corresponding device in /dev/mapper or
> > not, btrfs does not care where the device comes from. And
> > if you have not done the cryptsetup, then there is no device
> > in /dev/mapper and btrfs cannot use a non-existent device.
> >
> 
> The point is that once the other volumes are added, btrfs will need three
> devices in /dev/mapper:
> 
>    1. /dev/mapper/sda3_crypt
>    2. /dev/mapper/sdb2_crypt
>    3. /dev/mapper/sdc2_crypt
> 
> However, during the boot process, /dev/mapper/sda3_crypt is the only device
> being created.  If I do a blkid, I get:
> 
> /dev/mapper/sda3_crypt: UUID="e0948aa0-efab-4449-938d-6d74b6ccbf93"
> UUID_SUB="b3b1e4cc-ca0e-44ba-be35-32405b20025b" TYPE="btrfs"
> 
> So would I change the fstab from:
> 
> /dev/mapper/sda3_crypt / btrfs error=remount-ro,compress 0 1
> 
> to:
> 
> UUID_SUB=b3b1e4cc-ca0e-44ba-be35-32405b20025b / btrfs
> error=remount-ro,compress 0 1

Why would you, is /dev/mapper/sda3_not fine?
 
> ?  Would that be the same UUID_SUB for other /dev/mapper/sdX_crypts? 

I don't think so.

> And
> would grub / boot scripts be smart enough to figure out that it needs all
> three device files?

Grub is not involved. What your boot script does, I have no idea.

You may want to look at /etc/crypttab, that could give you the 
option to mount all three with the same passphrase. I have only 
used it to set up encrypted sawp, no idea what it can do in
addition (man crypttab for a description).


Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

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] Help! Command failed: /dev/sdd1 is not a LUKS partition

[M Thomas Frederiksen]

[-- Attachment #1: Type: text/plain, Size: 752 bytes --]

On Wed, Feb 10, 2010 at 13:08, Arno Wagner <arno@wagner.name> wrote:

>
> Why would you, is /dev/mapper/sda3_not fine?
>

It's fine at the moment.  But expect it not to work as soon as I add the
other volumes to my btrfs.  Remember btrfs has a built-in volume manager.


>
> > ?  Would that be the same UUID_SUB for other /dev/mapper/sdX_crypts?
>
> I don't think so.
>
> > And
> > would grub / boot scripts be smart enough to figure out that it needs all
> > three device files?
>
> Grub is not involved. What your boot script does, I have no idea.
>

Grub needs to know how to get the root device(s) setup.

-- 
Cheers,
~Thomas


Ted Turner <http://www.brainyquote.com/quotes/authors/t/ted_turner.html>  -
"Sports is like a war without the killing."

[-- Attachment #2: Type: text/html, Size: 1304 bytes --]

Re: [dm-crypt] Help! Command failed: /dev/sdd1 is not a LUKS partition

[Arno Wagner]

On Wed, Feb 10, 2010 at 05:23:32PM -0500, M Thomas Frederiksen wrote:
> On Wed, Feb 10, 2010 at 13:08, Arno Wagner <arno@wagner.name> wrote:
> 
> >
> > Why would you, is /dev/mapper/sda3_not fine?
> >
> 
> It's fine at the moment.  But expect it not to work as soon as I add the
> other volumes to my btrfs.  Remember btrfs has a built-in volume manager.
> 
> 
> >
> > > ?  Would that be the same UUID_SUB for other /dev/mapper/sdX_crypts?
> >
> > I don't think so.
> >
> > > And
> > > would grub / boot scripts be smart enough to figure out that it needs all
> > > three device files?
> >
> > Grub is not involved. What your boot script does, I have no idea.
> >
> 
> Grub needs to know how to get the root device(s) setup.

Grub just needs to find the kernel, load it and start
it. That is it. The rest is done by the kernel.
In particular Grub cannot set up any decryption. For that
reason when using encrypted root with Grub, you will
need a small partition that holds kernel, initrd and
Grub files including its configuration. 

The actual root device is passed to the kernel as
parameter, but it cannot be encrypted. What is passed
with encrypted root is the initrd, which contains
the initial root file system, which is a minimal but
working root filesystem with some essential tools and
some scripts. This initial root is then replaced by 
the decrypted root under control of the init system 
in the initrd, i.e. by some scripts in the initrd. 
Grubs job is done when it loaded the kernel and gave it 
its commandline. 

If you want encrypted boot, you need to use TrueCrypt
or the like, which has its own boot code and does not 
need Grub.

Arno

-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

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