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]
