[dm-crypt] Kernel panic, cannot mount root fs on unknown block (hd0, 0)

[dm-crypt] Kernel panic, cannot mount root fs on unknown block (hd0, 0)

[vaskez]

Several times I have set up virtual machines to test the cryptsetup 
software. I can create and remove the encrypted volumes just fine and 
mount them, however whenever I am finished setting up my system and 
reboot, my kernel panics, ends, then says that it cannot mount root fs 
on unknown block (hd0,0). I am sure that it is not a misconfiguration 
with the kernel, as I have built kernels for unencrypted systems and 
they have booted fine. Some information:

The encrypted volumes are created with:
cryptsetup -y -v -c serpent-xts-plain -s 512 -h sha512 create dmname 
device

Previous partition layouts was like such:
/dev/sda1 +b   Linux                  100M  (/boot) (not encrypted)
/dev/sda2      Linux Swap / Solaris   2G    (swap)
/dev/sda3      Linux                  10G   (root)
/dev/sda4      Extended
/dev/sda5      Linux                  2G    (/var)
/dev/sda6      Linux                  6G    (/home)

This last time the layout was like such:
/dev/sda1 +b    Linux                 100M  (/boot) (not encrypted)
/dev/sda2       Linux LVM             2G    (swap)
/dev/sda3       Linux LVM             10G   (root)
/dev/sda4       Extended
/dev/sda5       Linux LVM             2G    (/var)
/dev/sda6       Linux LVM             6G    (/home)

The distribution I am using is Gentoo with a custom (to test at one 
time) and modified i386_defconfig (every other time) kernel patched with 
GRSecurity.

This last time installing cryptsetup I made sure to install packages in 
a specific order, like installing cryptsetup before grub legacy and 
still got the same error. I had set root (hd0,0) in grub command line 
and setup (hd0) on the command line. At one time I had tested setup on 
(hd0,0), still the same error. When issuing grub-install /dev/sda in 
bash, it will say that df cannot read filesystems and that it cannot 
read a device map file, so I had to install grub in grub command shell.

I install cryptsetup from portage with USE="-thin" emerge -avtq 
cryptsetup. -thin does not install thin provisioning tools and the boost 
sys utils which I assume are very big because they take very long to 
install.

After installing cryptsetup, I configure /etc/crypttab (which does not 
exist) as follows:
swap   /dev/mapper/swap   /dev/urandom    
swap,cipher=serpent-xts-plain,size=512,hash=sha512
root   /dev/mapper/swap   none            
root,cipher=serpent-xts-plain,size=512,hash=sha512
var    /dev/mapper/swap   none            
var,cipher=serpent-xts-plain,size=512,hash=sha512
home   /dev/mapper/swap   none            
home,cipher=serpent-xts-plain,size=512,hash=sha512

/etc/fstab looks like:
/dev/sda1           /boot       ext2   noauto,noatime      0 2
/dev/mapper/swap    none        swap   sw                  0 0
/dev/mapper/root    /           ext4   defaults,relatime   0 1
/dev/mapper/var     /var        ext4   defaults,relatime   0 1
/dev/mapper/home    /home       ext4   defaults,relatime   0 0
/dev/cdrom          /mnt/cdrom  auto   noauto,user         0 0

I append the output of dmsetup tables to /etc/dmtab as the file says to 
do, and then configure /etc/conf.d/dmcrypt to the following lines:
target=swap
source='/dev/sda2'
key='/dev/urandom'
options='-c serpent-xts-plain -s 512 -h sha512'

target=root
source='/dev/sda3'
options='-c serpent-xts-plain -s 512 -h sha512'

target=var
source='/dev/sda5'
options='-c serpent-xts-plain -s 512 -h sha512'

target=home
source='/dev/sda6'
options='-c serpent-xts-plain -s 512 -h sha512'

I also add lvm and dmcrypt to the boot runlevel. Kernel parameters are 
set as follows:
kernel /boot/kernel cryptdevice=/dev/sda3:root 
crypto=sha512:serpent-xts-plain:512:0 root=/dev/mapper/root quiet

I have shifted and removed parts of these options in various ways 
possibly 15 or more different ways and nothing has worked.

After all of this none of it works. I reboot and get a kernel panic, and 
then it says: VFS: root fs cannot be mounted on unknown block (hd0,0). 
And yes I have set LVM and DM_CRYPT options etc in the kernel.

Re: [dm-crypt] Kernel panic, cannot mount root fs on unknown block (hd0, 0)

[Heiko Rosemann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/22/2014 12:50 AM, vaskez@airmail.cc wrote:
> Several times I have set up virtual machines to test the cryptsetup
>  software. I can create and remove the encrypted volumes just fine
> and mount them, however whenever I am finished setting up my system
> and reboot, my kernel panics, ends, then says that it cannot mount
> root fs on unknown block (hd0,0). I am sure that it is not a
> misconfiguration with the kernel, as I have built kernels for
> unencrypted systems and they have booted fine. Some information:

You will need to setup an initramfs or modify the one provided with
the gentoo install to open your encrypted volumes (at least the root
volume). I do not remember how it is "supposed to be done" in gentoo,
but I do remember it's not as simple as installing software in the
right order.

A good starting point would be
http://wiki.gentoo.org/wiki/DM-Crypt_LUKS#Generating_an_initramfs -
and as this is really distro specific (or maybe systemd takes care of
it - I don't know, I won't be trying) it is really beyond the topic of
this list.

Good luck with your setup,
Heiko
- -- 
Mein PGP-Key zur Verifizierung: http://pgp.mit.edu

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlQftpAACgkQ/Vb5NagElAWsdgCfZmOaFuUE/DQdEby9jzrBexuX
Bj4AoLuIcwtEKhaAByqGiHVYFI8qLpnY
=vkDn
-----END PGP SIGNATURE-----

Re: [dm-crypt] Kernel panic, cannot mount root fs on unknown block (hd0, 0)

[Arno Wagner]

On Mon, Sep 22, 2014 at 07:41:39 CEST, Heiko Rosemann wrote:
> On 09/22/2014 12:50 AM, vaskez@airmail.cc wrote:
> > Several times I have set up virtual machines to test the cryptsetup
> >  software. I can create and remove the encrypted volumes just fine
> > and mount them, however whenever I am finished setting up my system
> > and reboot, my kernel panics, ends, then says that it cannot mount
> > root fs on unknown block (hd0,0). I am sure that it is not a
> > misconfiguration with the kernel, as I have built kernels for
> > unencrypted systems and they have booted fine. Some information:
> 
> You will need to setup an initramfs or modify the one provided with
> the gentoo install to open your encrypted volumes (at least the root
> volume). I do not remember how it is "supposed to be done" in gentoo,
> but I do remember it's not as simple as installing software in the
> right order.

The thing is that the kernel cannot open LUKS encrypted partitions
by itself. It needs user-space tools (cryptsetup) for that. That
means the system must be running and have a working root filesystem.
The initrd mechanism provides a temporary root filesystem for that 
use.

As I do not like initrds on my systems (too much hassle changing 
anything), I use a different approach: Non-encrypted root and 
anything I consider security-critical on encrypted partition(s). 

A common criticism of that set-up is that it allows an attacker 
to change things on the root partition, but the same applies to 
the initrd (and the kernel!) as well and hence the initrd approach
does not really offer better security. If you want to prevent that,
you have to use some variant of secure boot, for example placing
bootloader, kernel and initrd on an encrypted memory-stick with
keypad or the like. And you better verify the BIOS checksum as 
well, although that may not be enough if somebody put a blue-pill
in there. Fortunately such attacks are expensive and come with a
high risk of detection, so unless you are a known terrorist or 
crimnal master-mind, don't worry about these. 

Second thing is that a running system is far easier to attack and 
as soon as it is opened, disk-encryption does not offer any 
protection anymore....


Arno

 
> A good starting point would be
> http://wiki.gentoo.org/wiki/DM-Crypt_LUKS#Generating_an_initramfs -
> and as this is really distro specific (or maybe systemd takes care of
> it - I don't know, I won't be trying) it is really beyond the topic of
> this list.
> 
> Good luck with your setup,
> Heiko
> -- 
> Mein PGP-Key zur Verifizierung: http://pgp.mit.edu
> 
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] Kernel panic, cannot mount root fs on unknown block (hd0, 0)

[Sven Eschenberg]

On Mon, September 22, 2014 12:02, Arno Wagner wrote:
> On Mon, Sep 22, 2014 at 07:41:39 CEST, Heiko Rosemann wrote:
>> On 09/22/2014 12:50 AM, vaskez@airmail.cc wrote:
>> > Several times I have set up virtual machines to test the cryptsetup
>> >  software. I can create and remove the encrypted volumes just fine
>> > and mount them, however whenever I am finished setting up my system
>> > and reboot, my kernel panics, ends, then says that it cannot mount
>> > root fs on unknown block (hd0,0). I am sure that it is not a
>> > misconfiguration with the kernel, as I have built kernels for
>> > unencrypted systems and they have booted fine. Some information:
>>
>> You will need to setup an initramfs or modify the one provided with
>> the gentoo install to open your encrypted volumes (at least the root
>> volume). I do not remember how it is "supposed to be done" in gentoo,
>> but I do remember it's not as simple as installing software in the
>> right order.
>
> The thing is that the kernel cannot open LUKS encrypted partitions
> by itself. It needs user-space tools (cryptsetup) for that. That
> means the system must be running and have a working root filesystem.
> The initrd mechanism provides a temporary root filesystem for that
> use.

I think in his case is is plain dmcrypt which does not invalidate your
point of course.

>
> As I do not like initrds on my systems (too much hassle changing
> anything), I use a different approach: Non-encrypted root and
> anything I consider security-critical on encrypted partition(s).

Which is not hassle free either, esp. on headless systems. On one hand
local mounts and fscking is done early, so cryptsetup should be even
before that point, then again it can be difficult to provide the key
remotely that early during boot. (I know KVMoIP is your friend here ;-) ).

>
> A common criticism of that set-up is that it allows an attacker
> to change things on the root partition, but the same applies to
> the initrd (and the kernel!) as well and hence the initrd approach
> does not really offer better security. If you want to prevent that,
> you have to use some variant of secure boot, for example placing
> bootloader, kernel and initrd on an encrypted memory-stick with
> keypad or the like. And you better verify the BIOS checksum as
> well, although that may not be enough if somebody put a blue-pill
> in there. Fortunately such attacks are expensive and come with a
> high risk of detection, so unless you are a known terrorist or
> crimnal master-mind, don't worry about these.

I agree, but pulling parts of /etc or /var onto crypto targets, while
leaving parts unencrypted is quite ugly. So many people would just encrypt
/ alltogether to save them from that hassle.

>
> Second thing is that a running system is far easier to attack and
> as soon as it is opened, disk-encryption does not offer any
> protection anymore....
>

Indeed

>
> Arno
>
>

Regards

-Sven

Re: [dm-crypt] Kernel panic, cannot mount root fs on unknown block (hd0, 0)

[Arno Wagner]

On Mon, Sep 22, 2014 at 21:07:58 CEST, Sven Eschenberg wrote:
> On Mon, September 22, 2014 12:02, Arno Wagner wrote:
[...]
> I think in his case is is plain dmcrypt which does not invalidate your
> point of course.

Possibly. As it does nit make much difference, I did nt make sure I\
got that right.

> >
> > As I do not like initrds on my systems (too much hassle changing
> > anything), I use a different approach: Non-encrypted root and
> > anything I consider security-critical on encrypted partition(s).
> 
> Which is not hassle free either, esp. on headless systems.  On one hand
> local mounts and fscking is done early, so cryptsetup should be even
> before that point, then again it can be difficult to provide the key
> remotely that early during boot. (I know KVMoIP is your friend here ;-) ).

Tell me about it. I have a headless firewall/fileserver in my
kitchen, and I got really fed up withhaving to carry it to
my desk whenever something stuck during boot. I finally 
installed a serial interface to be able to debug it with a 
laptop and minicom. I have given up on encryption during boot
for it, it just has an encrypted data partition that I mount
manually over ssh.

> > A common criticism of that set-up is that it allows an attacker
> > to change things on the root partition, but the same applies to
> > the initrd (and the kernel!) as well and hence the initrd approach
> > does not really offer better security. If you want to prevent that,
> > you have to use some variant of secure boot, for example placing
> > bootloader, kernel and initrd on an encrypted memory-stick with
> > keypad or the like. And you better verify the BIOS checksum as
> > well, although that may not be enough if somebody put a blue-pill
> > in there. Fortunately such attacks are expensive and come with a
> > high risk of detection, so unless you are a known terrorist or
> > crimnal master-mind, don't worry about these.
> 
> I agree, but pulling parts of /etc or /var onto crypto targets, while
> leaving parts unencrypted is quite ugly. So many people would just encrypt
> / alltogether to save them from that hassle.

I have only data encrypted. Nothing in /etc/ or /var/ needs extra 
protection IMO. The only thing besides data that I see as worthwhile
protecting are ssh private keys. Your needs may differ and I do
understand the argument. It is just important to remember that an
initrd is just as juicy a target for an attacker as a root 
partition and if you do it manually, the initrd is more
complicated. Of course I also have non-module kernels tailored
for my systems, so that removes another reason for an initrd.
 
Gr"usse,
Arno

> > Second thing is that a running system is far easier to attack and
> > as soon as it is opened, disk-encryption does not offer any
> > protection anymore....
> >
> 
> Indeed
> 
> >
> > Arno
> >
> >
> 
> Regards
> 
> -Sven
> 
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] Kernel panic, cannot mount root fs on unknown block (hd0, 0)

[Sven Eschenberg]

On Mon, September 22, 2014 22:59, Arno Wagner wrote:
> On Mon, Sep 22, 2014 at 21:07:58 CEST, Sven Eschenberg wrote:
>> On Mon, September 22, 2014 12:02, Arno Wagner wrote:
> [...]
>> I think in his case is is plain dmcrypt which does not invalidate your
>> point of course.
>
> Possibly. As it does nit make much difference, I did nt make sure I\
> got that right.
>
>> >
>> > As I do not like initrds on my systems (too much hassle changing
>> > anything), I use a different approach: Non-encrypted root and
>> > anything I consider security-critical on encrypted partition(s).
>>
>> Which is not hassle free either, esp. on headless systems.  On one hand
>> local mounts and fscking is done early, so cryptsetup should be even
>> before that point, then again it can be difficult to provide the key
>> remotely that early during boot. (I know KVMoIP is your friend here ;-)
>> ).
>
> Tell me about it. I have a headless firewall/fileserver in my
> kitchen, and I got really fed up withhaving to carry it to
> my desk whenever something stuck during boot. I finally
> installed a serial interface to be able to debug it with a
> laptop and minicom. I have given up on encryption during boot
> for it, it just has an encrypted data partition that I mount
> manually over ssh.
>

You are lucky in a way, still physical access ;-). In this case having a
usb device with the key(s) is a viable option. Stick it in during boot and
pull it when the system is up. Works out of the box on some distros.

Well, maybe manually will win over laziness for me too. I am somewhat
fiddling on something like that currently.

BTW: Remeber the classic VT-10x Terminals? A modern portable variant would
be neat, I think. Like a netbook, but just a display controller+serial
chip, could be really flat and lightweight.

>> > A common criticism of that set-up is that it allows an attacker
>> > to change things on the root partition, but the same applies to
>> > the initrd (and the kernel!) as well and hence the initrd approach
>> > does not really offer better security. If you want to prevent that,
>> > you have to use some variant of secure boot, for example placing
>> > bootloader, kernel and initrd on an encrypted memory-stick with
>> > keypad or the like. And you better verify the BIOS checksum as
>> > well, although that may not be enough if somebody put a blue-pill
>> > in there. Fortunately such attacks are expensive and come with a
>> > high risk of detection, so unless you are a known terrorist or
>> > crimnal master-mind, don't worry about these.
>>
>> I agree, but pulling parts of /etc or /var onto crypto targets, while
>> leaving parts unencrypted is quite ugly. So many people would just
>> encrypt
>> / alltogether to save them from that hassle.
>
> I have only data encrypted. Nothing in /etc/ or /var/ needs extra
> protection IMO. The only thing besides data that I see as worthwhile
> protecting are ssh private keys. Your needs may differ and I do
> understand the argument. It is just important to remember that an
> initrd is just as juicy a target for an attacker as a root
> partition and if you do it manually, the initrd is more
> complicated. Of course I also have non-module kernels tailored
> for my systems, so that removes another reason for an initrd.

Of course all depends on your setup and need. Unfortunately configuration
data can be sensitive. Some daemons used to store credentials in /etc
(pppd ?, network filesystems?). If you run an MTA, you'd probably want to
secure the mailspool and maildirs (both usually in /var). With ssh private
keys you meant the host keys, I guess?

>
> Gr"usse,
> Arno
>

Regards

-Sven

Re: [dm-crypt] Kernel panic, cannot mount root fs on unknown block (hd0, 0)

[Arno Wagner]

On Tue, Sep 23, 2014 at 01:39:19 CEST, Sven Eschenberg wrote:
> On Mon, September 22, 2014 22:59, Arno Wagner wrote:
[...]
> > Tell me about it. I have a headless firewall/fileserver in my
> > kitchen, and I got really fed up withhaving to carry it to
> > my desk whenever something stuck during boot. I finally
> > installed a serial interface to be able to debug it with a
> > laptop and minicom. I have given up on encryption during boot
> > for it, it just has an encrypted data partition that I mount
> > manually over ssh.
> >
> 
> You are lucky in a way, still physical access ;-). In this case having a
> usb device with the key(s) is a viable option. Stick it in during boot and
> pull it when the system is up. Works out of the box on some distros.
> 
> Well, maybe manually will win over laziness for me too. I am somewhat
> fiddling on something like that currently.
> 
> BTW: Remeber the classic VT-10x Terminals? A modern portable variant would
> be neat, I think. Like a netbook, but just a display controller+serial
> chip, could be really flat and lightweight.

Indeed. But I guess the market is too small for that and a cheap 
netbook + usb-serial adapter and minicom work too well as replacement.

> >> > A common criticism of that set-up is that it allows an attacker
> >> > to change things on the root partition, but the same applies to
> >> > the initrd (and the kernel!) as well and hence the initrd approach
> >> > does not really offer better security. If you want to prevent that,
> >> > you have to use some variant of secure boot, for example placing
> >> > bootloader, kernel and initrd on an encrypted memory-stick with
> >> > keypad or the like. And you better verify the BIOS checksum as
> >> > well, although that may not be enough if somebody put a blue-pill
> >> > in there. Fortunately such attacks are expensive and come with a
> >> > high risk of detection, so unless you are a known terrorist or
> >> > crimnal master-mind, don't worry about these.
> >>
> >> I agree, but pulling parts of /etc or /var onto crypto targets, while
> >> leaving parts unencrypted is quite ugly. So many people would just
> >> encrypt
> >> / alltogether to save them from that hassle.
> >
> > I have only data encrypted. Nothing in /etc/ or /var/ needs extra
> > protection IMO. The only thing besides data that I see as worthwhile
> > protecting are ssh private keys. Your needs may differ and I do
> > understand the argument. It is just important to remember that an
> > initrd is just as juicy a target for an attacker as a root
> > partition and if you do it manually, the initrd is more
> > complicated. Of course I also have non-module kernels tailored
> > for my systems, so that removes another reason for an initrd.
> 
> Of course all depends on your setup and need. Unfortunately configuration
> data can be sensitive. Some daemons used to store credentials in /etc
> (pppd ?, network filesystems?). If you run an MTA, you'd probably want to
> secure the mailspool and maildirs (both usually in /var). With ssh private
> keys you meant the host keys, I guess?

No, the user keys. I have a "privilege hieracy" among my machines
and downwards login is via password-less ssh, i.e. via the user's
private key. On the other hand, I think it is important to keep the
attacker-model in mind. Somebody with physical access to a running
machine can get everything anyways, most simple (can be bought 
pre-packaged) if there is a firewire port, as that gives full
memory access. A bit harder, but likely possible is hot-plugging some
sort of PCI-E debugger. Then there is the old-fashioned (by now)
freezing of the memory and reading it externally. Hence a running
machine is not protected against a competent resouceful attacker
anyways. That leaves incompetent or resource-starved attackers
and non-running systems. On my Laptop, for example, I make sure
I notice access and I just protect the data if themachineis not
running. Of course I do not use hibernate/sleep modes, as there,
prepackaged attack kits are available as well. On my pgysical 
server, I have said data-partition which is not normally decrypted.
On my vserver-residing mail-servers, I have no encryption at all,
as the vserver-provider can get at everything anyways. I do encrypt
all sensitive email via PGP/GnuPG though.
 
I have to admit that I am always a bit puzzeled when people 
encrypt disks that are in a data-center and routinely mounted
and decrypted. That does not make much sense. Are they afraid 
somebody will be able to steal the physical disks out of their
servers? There are two possible valid reasons though for doing 
it: regulatory requirement and disk disposal. 
 
Gr"usse,
Arno   

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] Kernel panic, cannot mount root fs on unknown block (hd0, 0)

[Sven Eschenberg]

First of your problems are very distributzion specific.

The kernel complains that it cannot find the block device that was passed
via root= parameter (without root= it will probably use the first hd block
device it sees as fallback).

On Mon, September 22, 2014 00:50, vaskez@airmail.cc wrote:
> Several times I have set up virtual machines to test the cryptsetup
> software. I can create and remove the encrypted volumes just fine and
> mount them, however whenever I am finished setting up my system and
> reboot, my kernel panics, ends, then says that it cannot mount root fs
> on unknown block (hd0,0). I am sure that it is not a misconfiguration
> with the kernel, as I have built kernels for unencrypted systems and
> they have booted fine. Some information:
>
> The encrypted volumes are created with:
> cryptsetup -y -v -c serpent-xts-plain -s 512 -h sha512 create dmname
> device
>
> Previous partition layouts was like such:
> /dev/sda1 +b   Linux                  100M  (/boot) (not encrypted)
> /dev/sda2      Linux Swap / Solaris   2G    (swap)
> /dev/sda3      Linux                  10G   (root)
> /dev/sda4      Extended
> /dev/sda5      Linux                  2G    (/var)
> /dev/sda6      Linux                  6G    (/home)
>
> This last time the layout was like such:
> /dev/sda1 +b    Linux                 100M  (/boot) (not encrypted)
> /dev/sda2       Linux LVM             2G    (swap)
> /dev/sda3       Linux LVM             10G   (root)
> /dev/sda4       Extended
> /dev/sda5       Linux LVM             2G    (/var)
> /dev/sda6       Linux LVM             6G    (/home)
>
> The distribution I am using is Gentoo with a custom (to test at one
> time) and modified i386_defconfig (every other time) kernel patched with
> GRSecurity.
>
> This last time installing cryptsetup I made sure to install packages in
> a specific order, like installing cryptsetup before grub legacy and
> still got the same error. I had set root (hd0,0) in grub command line
> and setup (hd0) on the command line. At one time I had tested setup on
> (hd0,0), still the same error. When issuing grub-install /dev/sda in
> bash, it will say that df cannot read filesystems and that it cannot
> read a device map file, so I had to install grub in grub command shell.

Grub is its own thing, does the bootloader load the kernel from an
encrypted fs? grub legacy? grub 2?

>
> I install cryptsetup from portage with USE="-thin" emerge -avtq
> cryptsetup. -thin does not install thin provisioning tools and the boost
> sys utils which I assume are very big because they take very long to
> install.

cryptsetup does not have any thin use flag afaik, lvm2 is the one using
thin provisioning ...
>
> After installing cryptsetup, I configure /etc/crypttab (which does not
> exist) as follows:
> swap   /dev/mapper/swap   /dev/urandom
> swap,cipher=serpent-xts-plain,size=512,hash=sha512
> root   /dev/mapper/swap   none
> root,cipher=serpent-xts-plain,size=512,hash=sha512
> var    /dev/mapper/swap   none
> var,cipher=serpent-xts-plain,size=512,hash=sha512
> home   /dev/mapper/swap   none
> home,cipher=serpent-xts-plain,size=512,hash=sha512

Gentoo does not really use crypttab, does it? instead it will use dmcrypt
in conf.d (for SYSVinit), might use crypttab for systemd though.

>
> /etc/fstab looks like:
> /dev/sda1           /boot       ext2   noauto,noatime      0 2
> /dev/mapper/swap    none        swap   sw                  0 0
> /dev/mapper/root    /           ext4   defaults,relatime   0 1
> /dev/mapper/var     /var        ext4   defaults,relatime   0 1
> /dev/mapper/home    /home       ext4   defaults,relatime   0 0
> /dev/cdrom          /mnt/cdrom  auto   noauto,user         0 0
>

fstab does not really matter when the kernel tries to mount the root
filesystem, fstab won't be needed until fscking or so...

> I append the output of dmsetup tables to /etc/dmtab as the file says to
> do, and then configure /etc/conf.d/dmcrypt to the following lines:
> target=swap
> source='/dev/sda2'
> key='/dev/urandom'
> options='-c serpent-xts-plain -s 512 -h sha512'
>
> target=root
> source='/dev/sda3'
> options='-c serpent-xts-plain -s 512 -h sha512'
>
> target=var
> source='/dev/sda5'
> options='-c serpent-xts-plain -s 512 -h sha512'
>
> target=home
> source='/dev/sda6'
> options='-c serpent-xts-plain -s 512 -h sha512'
>

Okay, so I presume you do use SYSVinit. Again, dmcrypt won't be needed
until the boot runlevel is reached, you problem starts WAY before this.

> I also add lvm and dmcrypt to the boot runlevel. Kernel parameters are
> set as follows:
> kernel /boot/kernel cryptdevice=/dev/sda3:root
> crypto=sha512:serpent-xts-plain:512:0 root=/dev/mapper/root quiet

Unfortunately you don't say anything about your initrd/initramfs, because
at some point during early boot you'll have to provide the passphrase.

You are telling the kernel to use /dev/mapper/root which in turns seems to
be missing when the kernel tries to mount it.

That being said, the other options are obviously for your initramfs which
in turn should run cryptsetup. These should be documented by the
initramfs/initrd generator used. The initramfs/initrd should usually drop
you to a rescue shell. This way you could check what actually happened
etc.

As your GRUB line does not include an initramfs, how do you actually
provide the masterkey to cryptsetup and run cryptsetup? Or did you
piggy-back the initramfs?

>
> I have shifted and removed parts of these options in various ways
> possibly 15 or more different ways and nothing has worked.
>
> After all of this none of it works. I reboot and get a kernel panic, and
> then it says: VFS: root fs cannot be mounted on unknown block (hd0,0).
> And yes I have set LVM and DM_CRYPT options etc in the kernel.

I hope I could help to look in the right place for the necessary
information etc.

Regards

-Sven

Re: [dm-crypt] Kernel panic, cannot mount root fs on unknown block (hd0, 0)

[vaskez]

Thank you for your replies. Creating an initramfs image did the trick. 
The only problems as of now are that the initramfs image fails to prompt 
for the passphrase to the root partition. It will drop me into a rescue 
shell, and from there I can use cryptsetup on the command line to 
decrypt the root partition, then I must exit and it will continue 
booting as normal. I hit OpenRC from there and the rest of my partitions 
prompt for a passphrase. I created an initramfs image with dracut with 
these options:
dracut -a "lvm dm crypt" -H --xz --strip initrd.img

I am still using these kernel paramters:
cryptdevice=/dev/sda3:root crypto=sha512:serpent-xts-plain:512 
root=/dev/mapper/root net.ifnames=0 quiet

Are there other parameters that I should be using? Perhaps something 
from dracut? I do not know of kernel parameters that can be accepted by 
the kernel or where to find them, I have only used what has been shown 
from Arch Linux wiki on dm-crypt plain.

Also whenever I halt my system it will print 30 some lines of ioctl 
complaining about the root fs is still in use, then quit. I do not think 
this is much a problem, because it will skip it and umount the other 
filesystems, then mount root as ro and finally shutdown. Do you think 
that this is a problem? If so, how would I be able to stop it?

> First of your problems are very distributzion specific.
> 
> The kernel complains that it cannot find the block device that was 
> passed
> via root= parameter (without root= it will probably use the first hd 
> block
> device it sees as fallback).
> 
> On Mon, September 22, 2014 00:50, vaskez@airmail.cc wrote:
>> Several times I have set up virtual machines to test the cryptsetup
>> software. I can create and remove the encrypted volumes just fine and
>> mount them, however whenever I am finished setting up my system and
>> reboot, my kernel panics, ends, then says that it cannot mount root fs
>> on unknown block (hd0,0). I am sure that it is not a misconfiguration
>> with the kernel, as I have built kernels for unencrypted systems and
>> they have booted fine. Some information:
>> 
>> The encrypted volumes are created with:
>> cryptsetup -y -v -c serpent-xts-plain -s 512 -h sha512 create dmname
>> device
>> 
>> Previous partition layouts was like such:
>> /dev/sda1 +b   Linux                  100M  (/boot) (not encrypted)
>> /dev/sda2      Linux Swap / Solaris   2G    (swap)
>> /dev/sda3      Linux                  10G   (root)
>> /dev/sda4      Extended
>> /dev/sda5      Linux                  2G    (/var)
>> /dev/sda6      Linux                  6G    (/home)
>> 
>> This last time the layout was like such:
>> /dev/sda1 +b    Linux                 100M  (/boot) (not encrypted)
>> /dev/sda2       Linux LVM             2G    (swap)
>> /dev/sda3       Linux LVM             10G   (root)
>> /dev/sda4       Extended
>> /dev/sda5       Linux LVM             2G    (/var)
>> /dev/sda6       Linux LVM             6G    (/home)
>> 
>> The distribution I am using is Gentoo with a custom (to test at one
>> time) and modified i386_defconfig (every other time) kernel patched 
>> with
>> GRSecurity.
>> 
>> This last time installing cryptsetup I made sure to install packages 
>> in
>> a specific order, like installing cryptsetup before grub legacy and
>> still got the same error. I had set root (hd0,0) in grub command line
>> and setup (hd0) on the command line. At one time I had tested setup on
>> (hd0,0), still the same error. When issuing grub-install /dev/sda in
>> bash, it will say that df cannot read filesystems and that it cannot
>> read a device map file, so I had to install grub in grub command 
>> shell.
> 
> Grub is its own thing, does the bootloader load the kernel from an
> encrypted fs? grub legacy? grub 2?
> 
>> 
>> I install cryptsetup from portage with USE="-thin" emerge -avtq
>> cryptsetup. -thin does not install thin provisioning tools and the 
>> boost
>> sys utils which I assume are very big because they take very long to
>> install.
> 
> cryptsetup does not have any thin use flag afaik, lvm2 is the one using
> thin provisioning ...
>> 
>> After installing cryptsetup, I configure /etc/crypttab (which does not
>> exist) as follows:
>> swap   /dev/mapper/swap   /dev/urandom
>> swap,cipher=serpent-xts-plain,size=512,hash=sha512
>> root   /dev/mapper/swap   none
>> root,cipher=serpent-xts-plain,size=512,hash=sha512
>> var    /dev/mapper/swap   none
>> var,cipher=serpent-xts-plain,size=512,hash=sha512
>> home   /dev/mapper/swap   none
>> home,cipher=serpent-xts-plain,size=512,hash=sha512
> 
> Gentoo does not really use crypttab, does it? instead it will use 
> dmcrypt
> in conf.d (for SYSVinit), might use crypttab for systemd though.
> 
>> 
>> /etc/fstab looks like:
>> /dev/sda1           /boot       ext2   noauto,noatime      0 2
>> /dev/mapper/swap    none        swap   sw                  0 0
>> /dev/mapper/root    /           ext4   defaults,relatime   0 1
>> /dev/mapper/var     /var        ext4   defaults,relatime   0 1
>> /dev/mapper/home    /home       ext4   defaults,relatime   0 0
>> /dev/cdrom          /mnt/cdrom  auto   noauto,user         0 0
>> 
> 
> fstab does not really matter when the kernel tries to mount the root
> filesystem, fstab won't be needed until fscking or so...
> 
>> I append the output of dmsetup tables to /etc/dmtab as the file says 
>> to
>> do, and then configure /etc/conf.d/dmcrypt to the following lines:
>> target=swap
>> source='/dev/sda2'
>> key='/dev/urandom'
>> options='-c serpent-xts-plain -s 512 -h sha512'
>> 
>> target=root
>> source='/dev/sda3'
>> options='-c serpent-xts-plain -s 512 -h sha512'
>> 
>> target=var
>> source='/dev/sda5'
>> options='-c serpent-xts-plain -s 512 -h sha512'
>> 
>> target=home
>> source='/dev/sda6'
>> options='-c serpent-xts-plain -s 512 -h sha512'
>> 
> 
> Okay, so I presume you do use SYSVinit. Again, dmcrypt won't be needed
> until the boot runlevel is reached, you problem starts WAY before this.
> 
>> I also add lvm and dmcrypt to the boot runlevel. Kernel parameters are
>> set as follows:
>> kernel /boot/kernel cryptdevice=/dev/sda3:root
>> crypto=sha512:serpent-xts-plain:512:0 root=/dev/mapper/root quiet
> 
> Unfortunately you don't say anything about your initrd/initramfs, 
> because
> at some point during early boot you'll have to provide the passphrase.
> 
> You are telling the kernel to use /dev/mapper/root which in turns seems 
> to
> be missing when the kernel tries to mount it.
> 
> That being said, the other options are obviously for your initramfs 
> which
> in turn should run cryptsetup. These should be documented by the
> initramfs/initrd generator used. The initramfs/initrd should usually 
> drop
> you to a rescue shell. This way you could check what actually happened
> etc.
> 
> As your GRUB line does not include an initramfs, how do you actually
> provide the masterkey to cryptsetup and run cryptsetup? Or did you
> piggy-back the initramfs?
> 
>> 
>> I have shifted and removed parts of these options in various ways
>> possibly 15 or more different ways and nothing has worked.
>> 
>> After all of this none of it works. I reboot and get a kernel panic, 
>> and
>> then it says: VFS: root fs cannot be mounted on unknown block (hd0,0).
>> And yes I have set LVM and DM_CRYPT options etc in the kernel.
> 
> I hope I could help to look in the right place for the necessary
> information etc.
> 
> Regards
> 
> -Sven

Re: [dm-crypt] Kernel panic, cannot mount root fs on unknown block (hd0, 0)

[Sven Eschenberg]

On Thu, September 25, 2014 21:25, vaskez@airmail.cc wrote:
> Thank you for your replies. Creating an initramfs image did the trick.
> The only problems as of now are that the initramfs image fails to prompt
> for the passphrase to the root partition. It will drop me into a rescue
> shell, and from there I can use cryptsetup on the command line to
> decrypt the root partition, then I must exit and it will continue
> booting as normal. I hit OpenRC from there and the rest of my partitions
> prompt for a passphrase. I created an initramfs image with dracut with
> these options:
> dracut -a "lvm dm crypt" -H --xz --strip initrd.img
>
> I am still using these kernel paramters:
> cryptdevice=/dev/sda3:root crypto=sha512:serpent-xts-plain:512
> root=/dev/mapper/root net.ifnames=0 quiet
>
> Are there other parameters that I should be using? Perhaps something
> from dracut? I do not know of kernel parameters that can be accepted by
> the kernel or where to find them, I have only used what has been shown
> from Arch Linux wiki on dm-crypt plain.

As you use dracut, please consult the dracut documentation and/or
mailinglist, as the remaining problems depend solely on that bloatware.

FYC:
http://fedoraproject.org/wiki/Dracut/Options#Dracut_kernel_command_line_parameters

The parameters you use (except for root=) are NOT kernel parameters.

If I had to guess: Dracut is not as distribution agnostic as it cliams and
thus does not even try to start your crypto target.

>
> Also whenever I halt my system it will print 30 some lines of ioctl
> complaining about the root fs is still in use, then quit. I do not think
> this is much a problem, because it will skip it and umount the other
> filesystems, then mount root as ro and finally shutdown. Do you think
> that this is a problem? If so, how would I be able to stop it?

The gentoo openrc init scripts are quite fatal in that they try to
'shutdown' everything, including LVMs, dmcrypt targets etc. they did not
necessarily start. Tracking what was setup during boot is quite
cumbersome, when most utils provide switches to shutdown just everything
they can find.

That being said: If there's no entry for your root device in
/etc/conf.d/dmcrypt you won't get a message during start that it is
already configured, and the script will not try to close the mapping (this
is actually dracut's job). Similiar things apply to LVMs/mounts etc.

Regards

-Sven