I'm running Ubuntu 14.04 (64bit). Long story short, I've compiled a custom kernel and now I'm running into some issues with my encrypted hard drive.

When I boot my machine and attempt to start the new kernel, it starts loading and reports:

Reading all physical volumes, this may take a while ...
   No Logical Volume Groups found
   No Logical Volume Groups found

While compiling the new kernel, I've taken my current kernel configuration (from /boot/config-$(uname-r) as the base so all modules that were in use during the compilation should also be available with the new kernel.

I'm a little stumped at where to start debugging. A colleague suggested I take a look at the initrd-images for both kernels. I've unpacked both images but have had little luck in determining what might be wrong. The size is quite different:

The new initrd:

emikkva@slartibartfast:/tmp/15$ ll init.img
-rw-rw-r-- 1 emikkva emikkva 18278400 july 18 18:01 init.img

And the old one:

emikkva@slartibartfast:/tmp/15$ ll ../13/init.img 
-rw-rw-r-- 1 emikkva emikkva 77744640 heinä 18 18:02 ../13/init.img

But the only differences are (both images unpacked):

emikkva@slartibartfast:/tmp/15$ diff -r . ../13
Binary files ./init.img and ../13/init.img differ
Only in ../13/lib: firmware # This might be a problem?
Only in ../13/lib/modules: 3.13.0-32-generic
Only in ./lib/modules: 3.15.0-rc8+

grub boot parameters are identical for both kernels. Using the old kernel works just fine.

I understand I've got little information to offer here but I will of course update the question with anything that might be relevant according to comments and answers.


lsblk output:

emikkva@slartibartfast:~$ lsblk
NAME                           MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                              8:0    0 238,5G  0 disk  
├─sda1                           8:1    0   243M  0 part  /boot
├─sda2                           8:2    0     1K  0 part  
└─sda5                           8:5    0 238,2G  0 part  
  └─sda5_crypt (dm-0)          252:0    0 238,2G  0 crypt 
    ├─ubuntu--vg-root (dm-1)   252:1    0 222,3G  0 lvm   /
    └─ubuntu--vg-swap_1 (dm-2) 252:2    0  15,9G  0 lvm   [SWAP]


emikkva@slartibartfast:~$ sudo pvs
  PV                     VG        Fmt  Attr PSize   PFree
  /dev/mapper/sda5_crypt ubuntu-vg lvm2 a--  238,23g    0 

dmsetup ls --tree:

emikkva@slartibartfast:~$ sudo dmsetup ls --tree
ubuntu--vg-swap_1 (252:2)
 └─sda5_crypt (252:0)
    └─ (8:5)
ubuntu--vg-root (252:1)
 └─sda5_crypt (252:0)
    └─ (8:5)


Checking the configuration file as per suggested by @derobert:

emikkva@slartibartfast:~/airlied-linux$ grep -i 'config_crypto_aes\|config_dm_crypt\|config_crypto_xts\|config_crypto_sha256\|config_crypto_sha512' .config

The configuration for the new kernel was identical, except for that _SSE3 -ending options, they were commented out.

Current crypto-algorithm in use seems to be aes-xts-plain64 according to the output of dmsetup table sda5_crypt.

  • What's your encryption set up---is the encryption below LVM (e.g., the partition the physical volume is on is encrypted) or above LVM (e.g., the logical volume is encrypted)? If the former, can you confirm crypto setup succeeded?
    – derobert
    Commented Jul 18, 2014 at 18:05
  • Probably dumb question, but why a custom kernel? Commented Jul 18, 2014 at 18:06
  • @derobert I'm not sure. It's the default settings from the ubuntu installation process.
    – msvalkon
    Commented Jul 18, 2014 at 18:15
  • @msvalkon That's probably encryption under LVM then, but not sure. lsblk, pvs, or dmsetup ls --tree from the working kernel should let us know.
    – derobert
    Commented Jul 18, 2014 at 18:18
  • @derobert edited the outputs to the question.
    – msvalkon
    Commented Jul 18, 2014 at 18:23

1 Answer 1


So, the reason was that I had compiled the kernel like so:

make oldconfig
make -j6
sudo make install

I was wondering why my previous (official ubuntu repo) initrd was 28m in size while the new one was 8m. I had not installed the modules!


sudo make INSTALL_MOD_STRIP=1 modules_install 
sudo make install

fixed it. Now the HD crypto is initialized correctly and LVM does not break. Thanks to @derobert for helping out.

  • 1
    BTW: since you're running a Debian-derived distro, you can probably use make deb-pkg (instead of make install/make modules_install) and then install the resulting packages.
    – derobert
    Commented Jul 21, 2014 at 15:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .