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" > <[email protected]> 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
