Well, that looks ok. Assuming you actually have an /etc/inittab on lukssda4, I'm stumped.

1 members found this post helpful.

This is getting rather puzzling. I have managed to put echo statements in the init script (of the initrd.gz) - and I have found so far that the partition gets unlocked successfully and becomes available under /dev/mapper/lukssda4. It also gets mounted successfully under /mnt. Yet at the end, init still complains that there is no inittab file. Strange.

Edit: Right - I've also checked that at the end of the init script /mnt and /mnt/sbin contain the right stuff.

Geeeez - I had one more look in /etc - and what do you know - no inittab! How is it possible for a brand new install not to have an inittab in place? Does it get created during a particular step of the setup, which might have gone wrong? I'm having a hard time deciding right now if I should jump out of the window, or the laptop should be the one to follow that route :-)

Aargh, sorry for this mess. I'm going to start a new install from scratch and see what happens. I still don't understand why there is no inittab in there.

/etc/inittab comes from package sysvinit-scripts. Of course it should be installed (you made a full installation, didn't you?) unless there be a problem with the media source of the packages.

Right - I've done a full re-installation. Now there is an /etc/inittab (and I've used the same install media as before - go figure!). But now initrd refuses to mount /dev/mapper/lukssda4 - although it is there. I'll reboot with the boot usb stick and investigate further. I am absolutely dreading now Slackware installs involving dm-crypt and initrd. I don't think there is anything else in Linux with which I have had so much trouble - every single time. I'll keep you posted.


Edit: The error is:
And yet I get a prompt below the error, and I can check that the /dev/mapper/lukssda4 exists. If I try to mount it manually, it fails with the same error message. If I start the laptop from the boot/install usb stick, I can mount /dev/mapper/lukssda4 without any problem. What is the difference between the full environment and that of initrd - which might cause it to be unable to mount /dev/mapper/lukssda4?

When it fails to mount from the initrd prompt, did you try vgscan --mknodes and vgchange -ay first?

BTW @Gazl or someone more knowledgable, I saw the thread re the -root option in RC1 after installing 14.1 with the old fashioned cryptvg name. Seems to work ok, but should I anticipate any problems? My mkinitrd:

mkinitrd -c -k 3.10.17 -f ext4 -r /dev/cryptvg/root -m mbcache:jbd2:ext4:ext2:vfat -C /dev/sda3:/dev/sdb1 -L -u -o /boot/initrd.gz -K UUID=D6FB-3C21:/EFI/Slackware/keyfile

(Sorry if it's a hijack, I was kind of wondering what the general answer to the original OP question was, as the README still mentions cryptvg and not lukssdx)

Isn't vgscan used for LVM? I don't use LVM, just straightforward encrypted partitions.

Ahh, I see, I got thrown by the -L. Still the error message is the same I'd expect if you were using LVM and hadn't done vgscan etc. Weird that you can see it, but not mount it with that error message.

@mh, There are currently three known issues:

1. dmsetup isn't included in the initrd. If you use -L then this won't happen to you.
2. the -r option of mkinitrd gets overridden by the root= from the lilo.conf, so an old style mkinitrd such as "mkinitrd -r cryptroot" won't take effect.
3. USB keyboard owners are having to include some new modules in their initrd that they didn't use to need. (there's been a couple of threads about that)

In your case you've gone for a encrypted lvm setup which does neither of the first two, so you should* be fine.


(*) I say "should" because I really have no idea what's going on with xj25vm's system. He shouldn't be experiencing anywhere near this level of difficulty.

Just a small extra note. I have tried to mount a non-encrypted partition (after the error message, which follows inputting the passphrase). I can't even mount /dev/sda1, which is my ext4 formatted boot partition. Something really strange is going on. As /bin/mount is a link to busybox, I have to assume there is something screwy with busybox - as I can mount those partitions normally - but that's just a supposition.

Edit: The above got me thinking and I've searched online for those mount errors in relation to busybox. It turns out that that is busybox's unhelpful way of telling you that you don't have the right kernel module loaded. I went back to my initrd-tree folder and lo' and behold, it didn't have any kernel modules there. This has clearly been a long troubleshooting session. I've re-run mkinitrd, this time checking the initrd-tree directory - and finally I have managed to boot all the way to the login prompt.

I really, really dread having to ever do this again - as mkinitrd with dm-crypt always seems to find some new way of breaking. I am keeping notes every time - and yet it still ends up being a headache.

Thanks again to everybody who contributed.

1 members found this post helpful.