On Tue, Mar 8, 2016, at 15:06, Frank Steinmetzger wrote: > On Wed, Mar 09, 2016 at 12:02:23AM +0100, Frank Steinmetzger wrote: > > > > If you would like to get rid of the /run/lvm/lvmetad.socket error just > > > start lvm with "service lvm start". I still get the error when starting > > > up but it still works. > > > > I noticed that and quickly found /etc/init.d/lvmetad, but since I'm doing > > only the setup on this PC, I don't realler bother. > > I would actually prefer a simple partition table within the luks > container. > I have no real need for the flexibility of LVM and it would only embiggen > the required initramfs and make the boot process more complex. > But folks on IRC told me was not possible. > > -- > Gruß | Greetings | Qapla’ > Please do not share anything from, with or about me with any social > network. > > There are things of which I do not even talk to myself.
Frank, I can attest that it is possible to have an encrypted root without involving LVM. I have done this on Gentoo and other distros many times. In fact, it can be a bit easier to deal with if you don't need the LVM flexibility within your dm-crypt container and truly it is one less thing to forget about when you are setting up your initrd/grub config. You are doing things in a reasonable order it seems to me. First you create the partition table, then you luksFormat the partition which is to be encrypted (presumably leaving /boot unencrypted), and then you run pvcreate on the encrypted partition (although if you do not wish to use lvm, you should just run mkfs on the dm-crypt device in /dev/mapper). LVM can be nice, though, as it lets you have a multitude of logical volumes all within a single encrypted disk partition (otherwise maybe you would have everything on one partition and your system would fail if /var got full, or you would have several separately encrypted partitions which could cause other troubles). Generally you can ignore those lvmetad messages as they don't necessarily stop the command from succeeding. Could you send us the output of "stat `readlink -f /dev/mapper/lvm`" (or in your first example, "stat `readlink -f /dev/mapper/tp`")? I am interested to see that the file exists and has the correct attributes after you perform your `cryptsetup luksOpen` operation. The files in /dev/mapper are symlinks to /dev/dm-* devices, this will resolve the symlink and then run stat on the real underlying dm-* device. Hope this helps, Max -- 0x7D964D3361142ACF
