SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
My configuration:
/dev/sda1 /dev/sda2 Windows partitions
/dev/sda3 /boot (ext2)
/dev/sda4 luks
inside luks LVM is used:
/dev/mapper/cryptvg-root
/dev/mapper/cryptvg-home
/dev/mapper/cryptvg-swap
system: Slackware 14.0, kernel 3.2.29 with initrd
The whole configuration was before without luks/LVM. Everything was on backup, partitions deleted and converted to LUKS/LVM, copied back from backup.
Everything works like before with kernel 3.2.29 (original one from Slackware) with the initrd made following the Readme from Slackware.
However, before I was using kernel 3.16.0 which worked fine too without any initrd. Now I need an initrd for the luks/LVM part, but I can't get it to work.
The initrd for 3.16.0 was made the same way like for 3.2.29, it boots and asks for the luks password. But after that it says it can't find /dev/mapper/cryptvg-root and mount it at /mnt and gives me a prompt.
There I see /dev/mapper/lukssda4 is created, however using lvm doesn't detect anything.
Do I miss something to be included in the initrd to have lvm work? Or any other ideas what could be the problem here?
and for 3.16.0:
mkinitrd -c -k 3.16.0 -f ext4 -r /dev/mapper/cryptvg-root -m ext4 -C /dev/sda4 -L -o /boot/initrd-3.16.0.gz
looking to initrd-tree for both, I can't see any difference. Both have the same modules included. Maybe something compiled into the kernel not as module is missing?
As I said, using 3.16.0 with the above initrd, I can put in the password, /dev/mapper/lukssda4 is created, lvm is in the initrd - but scanning for any volume doesn't find anything (lvm pvscan, lvm lvscan, lvm vgscan all report nothing found).
No, unfortunately I can't boot 3.16.0 - /root and /home are within the luks partition.
I haven't run mkinitrd_command_generator.sh on 3.16 before, only on 3.2.29 to see what it says but which was identical to the above command line I posted, which was originally taken from README_CRYPT.TXT which came with Slackware14.0 .
Since "cryptsetup luksOpen" works I assume that this part is fine. Also /dev/mapper/lukssda4 (or whatever is used with cryptsetup) is generated so dev-mapper should be ok too. Seems to me something LVM related is missing in the kernel since it can't find any volumes.
Do you know what is needed in the kernel to have LVM working? ("device-mapper support" and "crypt target support" are compiled in)
According to the diff of the two, there isn't a major difference between the 14.0 and 14.1 versions of mkinitrd_command_generator.sh; nothing that would impact LUKS use.
If you are using the generic kernel, it has all that is needed to get LVM up and running. (I'm booting Slackware61 14.1 with / mounted on a logical volume.)
When you get the prompt, what you see after running
Yes, with the generic 3.2.29 which comes with Slackware everything works fine.
I was also able to boot into 3.16 creating a minimal USB based root-file system based on the current system but with the 3.16 kernel and the initrd for 3.16 (but without unlocking luks in initrd since it's not used for /). Once booted to 3.16 from USB, I can use cryptsetup, vgscan --mknodes, vgchange -ay, then chroot to the original / on the LUKS/LVM and then using mkinitrd_command_generator.sh. The line returned is basically the same I used only includes some additional USB modules.
So I'm a bit puzzled now. Seems the kernel itself has everything in there otherwise I couldn't open the LVM after the USB boot, but using the initrd alone for unlocking lvm doesn't work.
Here the output of the commands you asked for after the emergency prompt when try to boot 3.16.0 with initrd and / on luks/lvm:
vgchange: "No volume goups found"
vgscan: "No volume groups found"
udevadm: No output
/sbin/pvscan: doesn't exist
lvm pvscan: "No matching physical volumes found"
in comparison from a running system:
vgchange: "3 logical volume(s) in volume group "cryptvg" now active"
vgscan: "Found volume group "cryptvg" using metadata type lvm2"
udevadm: no output
pvscan:
PV /dev/mapper/lukssda4 VG cryptvg lvm2 [417.63 GiB / 0 free]
Total: 1 [417.63 GiB] / in use: 1 [417.63 GiB] / in no VG: 0 [0 ]
As you mention that you use a custom kernel, did you compile it with the following configuration (taken from README_CRYPT.TXT)?
Quote:
A note on custom kernels
------------------------
If you want to compile your own custom kernel to work with LUKS encrypted
partitions, you need to enable at least the following two options in your
kernel configuration:
Multiple devices driver support (RAID and LVM) --->
<*> Device mapper support
<*> Crypt target support
This is equivalent to the following options in your .config file:
CONFIG_BLK_DEV_DM=y
CONFIG_DM_CRYPT=y
Do not compile these as module! They are required in your kernel.
Yes, with the generic 3.2.29 which comes with Slackware everything works fine.
I was also able to boot into 3.16 creating a minimal USB based root-file system based on the current system but with the 3.16 kernel and the initrd for 3.16 (but without unlocking luks in initrd since it's not used for /). Once booted to 3.16 from USB, I can use cryptsetup, vgscan --mknodes, vgchange -ay, then chroot to the original / on the LUKS/LVM and then using mkinitrd_command_generator.sh. The line returned is basically the same I used only includes some additional USB modules.
Yeah, the usb modules placed into the initrd are slightly different between 14.0 and 14.1. Like you, I don't think that's an important difference.
Quote:
So I'm a bit puzzled now. Seems the kernel itself has everything in there otherwise I couldn't open the LVM after the USB boot, but using the initrd alone for unlocking lvm doesn't work.
Here the output of the commands you asked for after the emergency prompt when try to boot 3.16.0 with initrd and / on luks/lvm:
vgchange: "No volume goups found"
vgscan: "No volume groups found"
udevadm: No output
/sbin/pvscan: doesn't exist
Sorry about that. I see that you figured out the workaround immediately.
Quote:
lvm pvscan: "No matching physical volumes found"
in comparison from a running system:
vgchange: "3 logical volume(s) in volume group "cryptvg" now active"
vgscan: "Found volume group "cryptvg" using metadata type lvm2"
udevadm: no output
pvscan:
PV /dev/mapper/lukssda4 VG cryptvg lvm2 [417.63 GiB / 0 free]
Total: 1 [417.63 GiB] / in use: 1 [417.63 GiB] / in no VG: 0 [0 ]
Everything was on backup, partitions deleted and converted to LUKS/LVM, copied back from backup.
I guess I'm a bit lost.
MEC75, under which kernel were you able to return your backed up stuff to the newly created LUKS/LVM partition(s)? Wouldn't that mean it did work at one point?
Also, it seems to me, if vgscan is saying "No volume groups found", then I'd believe it.
Are you super-sure you didn't skip a step someplace? I have been using this method for a long time now, and every so often upon recreating it (for a new install for example) I goof up.
I'm really interested in playing with a new kernel just for "fun" and :cough:Libre:cough:, and I have never been able to get this right without the stock kernel.
Sorry if I just muddied the waters...
Last edited by STDOUBT; 11-07-2014 at 11:17 PM.
Reason: brainfart
I can verify that kernel 3.16.2 runs LUKS and LVM in a very similiar setup, albeit I started with Slackware 14.1 not 14.0, although I did have 14.0 prior with the same setup as well. I followed the directions at http://alien.slackbook.org/dokuwiki/...kernelbuilding to copy the configuration and build the kernel. Here is my mkinitrd:
Though you probably don't need all that. I use a USB key to hold the keyfile, and there are two separate LUKS/LVM disks. Don't know if that helps much.
mirror v1.13.2
crypt v1.13.0
striped v1.5.1
linear v1.2.1
error v1.2.0
@STDOUBT: I'm sure I skipped no step to have a working LUKS/LVM working, because it works - only not with 3.16.
I had a long time ago a Slackware 14.0 installation with the default 3.2.29 kernel and switched to the most resent kernel at this time and later to 3.16.0. At this time it was just 2 partions, one for / and one for /home. All self compiled kernels have always been made via "make oldconfig" and then going through all items using "make menuconfig" and removing everything not needed for my system. Some days ago I decided to switch to only one LUKS partition (+a small boot) and using LVM inside for / and /home. Everything was backed up to USB, new installation started via original install DVD which uses 3.2.29 and where LUKS/LVM was working and setup, then after a minimal installation copied everything back from USB, chroot to /mnt, edit /etc/lilo.conf, created initrd for 3.2.29, install lilo to MBR, reboot. After that the system with 3.2.29 was working and booting. Then I did the same mkinitrd (see in previous comments) for 3.16.0, reconfigured lilo, run lilo, rebooted. But then after I can put in the password for LUKS, it says it can't mount /dev/mapper/cryptvg-root under /mnt, because no LVM volume is found - which doesn't mean it is not there, because with 3.2.29 the system boots. (and dm-crypt and LVM support is compiled into the kernel, not as module).
@mostlyharmless: Yes, since I don't need USB to boot the default install on the internal HD, I don't think it's needed. But just to try, I used your line and there is no change in what happens (except that more modules get loaded at startup time).
Do you know what's "mbcache" for?
The interesting thing is that if I boot this 3.16.0 kernel from an external device (/ not on LUKS/LVM, I made a USB disk bootable with the backup of / of the system to have the exact same installation except that the root-filesystem is on a physical partition) then I can later after login as root open the LUKS on the internal disk and then the LVM partitions. So something seems to be missing in the initrd or something compiled as module should be in the kernel (or vice versa?).
What I did before was using "gmake oldconfig" for 3.16.0 based on 3.2.29 and removing all not needed things from the kernel, keep only what's needed for my system. This was at a time when all / and /home was on physical partitions and all worked well. dm-crypt support and device-mapper were already compiled into the kernel. After switching to LUKS/LVM, the system stayed the same, only adding an initrd to 3.2.29 (which was still there from the original installation a long time ago and used as emergency system while testing new kernels) and to 3.16.0 - using the same command for both initrds.
Result: It was working instantly fro 3.2.29 but not for 3.16.0 and I tried to look through the different options using "gmake menuconfig" to get it to work - no success at all.
Since it has to work and it also works booting the same compiled kernel from USB and after login as root opening then the internal LUKS/LVM device, something was missing but I had no idea what.
Since I couldn't find it so far, I used another approach: Start from a clean 3.16.0 source tree, using gmake oldconfig based on 3.2.29 - and don't do anything else, only create a initrd after compiling and installing and reinstallation of lilo. That works!
So now, I will try to remove all modules not needed in 3.16.0 for my system and when I have a minimal configuration based on that, I can compare it with the previous one to see what was missing for having LVM working. (right now there is much too much in there and a diff of both configuration is not useful at all for that reason)
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.