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

[jonas]

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