[pkg-cryptsetup-devel] Bug#619010: FW: Re: Bug#619010: (no subject)

[Volker Schlecht]

Hi Jonas,

> that seems like something is fundamentally wrong. the source device
> /dev/sda2 should contain a luks container, not a ext3 filesytem, right?

Could this be due to me setting the FS type of the /dev/sda2 partition to ext3 in cfdisk when setting up my system initially?
(Note: I've been running with this setup for 2+ years, which would indicate to me an unusual robustness towards fundamental mistakes :-)) 

# cryptsetup status cryptRoot 
/dev/mapper/cryptRoot is active and is in use.
  type:  LUKS1
  cipher:  aes-cbc-essiv:sha256
  keysize: 128 bits
  device:  /dev/sda2
  offset:  1032 sectors
  size:    4191933 sectors
  mode:    read/write

# blkid  /dev/sda2 
/dev/sda2: UUID="013dabec-dd64-4fe0-8842-cd2f92f3348e" SEC_TYPE="ext2" TYPE="ext3" 

... and here comes the good part:

# blkid  -p /dev/sda2 
/dev/sda2: UUID="abf679d3-2a75-469f-b85a-e552aa7f1e6b" VERSION="256" TYPE="crypto_LUKS" USAGE="crypto" 

Seems blkid sees different things in my /dev/sda2 depending on whether I ask it to 'probe' or not... given that this is my notebook, I
really, really, really wonder if I'll ever have the problem that UUIDs are trying to solve on that machine :-)

regards,
Volker

> ----- Ursprüngliche Nachricht -----
> Von: jonas
> Gesendet: 14.04.11 00:43 Uhr
> An: Volker Schlecht
> Betreff: Re: FW: Re: [pkg-cryptsetup-devel] Bug#619010: (no subject)
> 
> On Thu, 14 Apr 2011 00:20:43 +0200, "Volker Schlecht"
> <vschlecht at gmx.net> wrote:
> > Hi Jonas,
> > 
> > your assumptions about my setup are spot-on.
> > As you correctly guessed, a regenerated initramfs breaks in the same manner. 
> > Diffing the two initrds yielded a significant difference in cryptroot
> > - the working version refers to /dev/sda2
> > instead of the uuid (I guess my old initrds were generated with
> > /etc/crypttab.old ... d'oh!)
> > 
> > What's interesting is that on a booted system I get 
> > 
> > # blkid /dev/sda2 
> > /dev/sda2: UUID="013dabec-dd64-4fe0-8842-cd2f92f3348e"
> > SEC_TYPE="ext2" TYPE="ext3"
> 
> Hey Volker, 
> 
> that seems like something is fundamentally wrong. the source device
> /dev/sda2 should contain a luks container, not a ext3 filesytem, right?
>  
> > Whereas in the rescue console /dev/sda2 has a different UUID. There's
> > "more robust" for ya...
> > 
> > I guess I'll manually switch /etc/crypttab back then. Might still be
> > interesting, how come the UUID is different between two boots...
> 
> the UUID cannot be different for the same device. And UUID is much more
> robust than /dev/sd* device names, which are not consistent between
> reboots (in case you add and/or remove harddisks, removable media). so
> you really should try to find the source of your problem, instead of
> changing back to fragile /dev/sd* device names.
> 
> Please check carefully which device you're talking about:
> 
> 1. check which device holds your root fs (should be
> /dev/mapper/cryptRoot)
> 
> 2. check which source device holds the encryptions 'cryptsetup status
> cryptRoot'
> 
> 3. check the uuid of that source device and compare it with
> '013dabec-dd64-4fe0-8842-cd2f92f3348e'
> 
> 4a. in case it's the same, you might have spotted a bug.
> 
> 4b. in case it differes, someone (presumably youself) messed up the
> setup. try to set the correct uuid for cryptRoot in /etc/crypttab and
> regenerate the initramfs.
> 
> greetings,
>  jonas