This is normal. The installer does not use any of the timezone settings you configure. This configuration is strictly for the system you are installing.

Why do you use the "change-rules"? After the chroot you should be able to just run "lilo" with that lilo.conf to let lilo install itself into the MBR of the hard disk.

Eric

Actually lilo did that not me.

Sounds like I should #change-rules

Just thought I'd post a link to a decent gentoo wiki explaining the use of LVM and LUKS in tandem. It looks like it'll take a little more legwork than just running the stock mkinitrd script with the right flags, but hey, that's why we're using Slackware, right?

http://gentoo-wiki.com/SECURITY_LVM_...ryptsetup-LUKS

Ok, so I've now gotten a slackware install with lvm on top of luks to work. It takes a little editing, but it can be done. Here's how:

First, you should follow Alien Bob's README for setting up luks, then go through setting up lvm on the mapped device from luks. For me, it was a little bit easier to use the luks device name as the vg name in setting everything up. Go through the rest of the setup and installation up until it's time to install lilo, and do the simple installation to the root device so that you get a basic lilo to edit later.

Now, create the chroot environment from the Alien Bob readmes, chroot into it, and run the mkinitrd command for setting up a luks encrypted device (with the -r pointing to the mapped device name). You'll also have to make sure to include -m dm_crypt, because for some reason that gets left out of the initrd-tree otherwise.

Now, you're going to have to do a little editing inside the initrd source tree. cd into /boot/initrd-tree, and edit the init script by cutting and pasting the portion that makes the encrypted partitions available above the part that initializes the LVM. You then need to edit the part of the luks script that says to point to wherever you configured the root device under lvm. For me, this was easy because I had configured my volume group to be named the same as my luks device, so all I had to do is edit the script like this: After you've made and saved the edit, run mkinitrd again without any flags. This will take the contents of /boot/initrd-tree and roll it up into a new initrd.gz. Now all you have to do is edit your /etc/lilo.conf and /etc/fstab to point to the right devices, run lilo, and you're good to go.

It should also be noted that rc.S also activates logical volumes before opening luks encrypted devices, so you might have to edit that as well. I'm not certain about that.

Any moves on that? There are really no fixed points for it either in initrd script, or in init scripts, where LVM is the first and cryptsetup is the second.

Actually, the way it's set up in 12.0 is under that assumption that you're either setting up one encrypted partition, or you're encrypting a logical volume. The way I set mine up, and the way I assumed the starter of this thread wanted theirs set up, was to encrypt a single partition, and then map the LVM on top of that encrypted partition. That takes a little more work, but it's really no more difficult than changing the order in the init script and then making sure your root device is put in correctly.

Okay, here's my Slack-LVM-LUKS tutorial if you're interested. I've done this with LUKS encrypted partitions only, and with LVM and LUKS. Without "changing the init script" (am I capable of that?), this works.

First, you must follow the README_LVM.TXT and setup your logical volume(s) first; then you can encrypt using README_CRYPT.TXT. (Until someone tells us how to do it the other way around).

Second, you must use the same kernel for your system as your install media. If not, when you reboot your initrd will not allow you to unlock your root filesystem. For example, yesterday I did a NFS install which I started with my -current CD-RW that had 2.6.23.15. But installing from my -current mirror on my server gave me 2.6.23.16 as the installed kernel. In my limited experience you must use the same kernel on the boot media as the one you install with the system.

Third, you must use a generic kernel rather than the huge kernels, because the initial RAM disk is too big to fit between the kernel and the 15M-16M memory hole with the huge ones.

Fourth, if you have an USB kbd and encrypt root, you won't be able to give the LUKS passphrase for root, because USB_HID will not have loaded at that time. The easiest option is to use a PS/2 kbd to enter the passphrase for root, after which the module will load and from then on you can use a USB kbd. Then before rebooting rebuild a kernel with USB_HID=m and put it in the new initrd.

bl0tt0's way of changing initrd's init script is not that hard, works for LVM created on previously encrypted partition and does not have so many limitations, which you have to remember.
And why do you think that huge kernel is not suitable? That warning, which LILO issues is for older computers, as far as I understand, so it is possible to forget about it.
What about USB-HID, you may also compile it into your kernel and not to insert it, regarding to as a module.

Try running lilo when you use a Slackware 'huge' kernel together with an initrd.
Lilo will refuse to install the loader. The kernel is just too big.

Eric