Interesting; it does indeed have a stale header of some kind:
zpalmer@thirtyseven:~$ sudo blkid /dev/sda7
/dev/sda7: UUID="b56e8430-2594-436a-9fba-b91617cdaa5e"
TYPE="crypto_LUKS"
zpalmer@thirtyseven:~$ sudo /sbin/wipefs /dev/sda7
offset type
----------------------------------------------------------------
0x0 crypto_LUKS [crypto]
UUID: b56e8430-2594-436a-9fba-b91617cdaa5e
But /dev/sda7 is a bcache backing volume.
zpalmer@thirtyseven:~$ sudo probe-bcache /dev/sda7
4b6ead1d-3341-407c-9e16-dd9e639268e4: UUID="" TYPE="bcache"
Doesn't bcache put its superblock in the first part of the block
device? How is it possible that the device looks like a bcache backing
volume and a LUKS encrypted volume at the same time? (For the record, I
know that the LUKS volume identified above is the stale one; when I used
LVM to move everything around, I created a fresh LUKS encrypted volume
which has a different UUID than the old one shown above.)
Thanks,
Zach
p.s.: Regarding the hibernation issue, I believe that a related bug has
already been reported to the Debian crew, who have sent at least some of
the information upstream to kernel development (see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=715019). I've added my
own information to that bug report, of course. If I can provide any
information that would be of assistance, please let me know.
Hello there. I'm not sure if this is the appropriate venue, so please
let me know if this information should be somewhere else. I have
configured a Debian 7.0 installation on a Dell Inspiron 17R SE laptop
to use a bcache root device. The previous known working configuration
for the laptop was:
/dev/sda (1TB HDD)
...
/dev/sda7 (used as LUKS encrypted volume)
/dev/mapper/sda7_crypt (used as LVM PV)
/dev/vg0/home
/dev/vg0/root
...
/dev/sda8 (used as ext3 /boot)
The new configuration is
/dev/sda (1TB HDD)
...
/dev/sda7 (used as bcache backing device)
/dev/bcache0 (used as LUKS encrypted volume)
/dev/mapper/bcache_crypt (used as LVM PV)
/dev/vg0/home
/dev/vg0/root
...
/dev/sda8 (used as ext3 /boot)
/dev/sdb (32GB SSD)
...
/dev/sdb3 (used as bcache caching device)
In order to get things booting, I also:
* Installed a Linux 3.10 kernel from wheezy-backports (3.10-0.bpo.2-686-pae)
* Obtained a copy of the bcache-tools source from the git repo and compiled it
* Constructed a Debian package for bcache-tools using checkinstall
* Because udev recognition wasn't enough at boot time, added a script
/etc/initramfs-tools/scripts/init-premount/z-bcache which looks like this:
Just addressing the udev part; could you check with wipefs (nondestructive with no flags)
that /dev/sda7 doesn't have an old non-bcache superblock?
There's been a transitional period when udev rules were stricter than what make-bcache
created, which will be fixed with the patch at https://github.com/g2p/bcache-tools/commits.
--
To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
