# Encryption Questions

## StargateGamingGeek

I am making my first post on these Gentoo Forums here and just jumping right into the heavy questions. So here goes...

I am trying to figure out how to do some pretty interesting looking stuff with Gentoo and encryption mostly for the purpose of security on a laptop computer. I have been reading up on these forums and elsewhere on DM-crypt and Truecrypt and LVM2 and I have put together a "plan" so to speak but I think I may need some guidance on how to implement it.  My thought is to setup a single partition with some logical volumes inside so that from the outside everything looks like one big partition filled with random data. Inside that You would of course need a / partition and a SWAP partition (need there is up for debate with SWAP I understand but let's just take it as a given here). Those could be encrypted with DM-crypt and auto-mount/created during boot.  /boot itself could be contained on a USB Thumbdrive so that you don't have to have the unencrypted data on the drive to foil your deniability. Then you could have a partition for /home and other personal stuff encrypted using truecrypt. The thing I wondered about there was the possibility of setting that up to mount when you log-on to your user account. Anyone have any suggestions or critique of my "plan" or helpful advice on hwo to pull it off? I have managed to find good tutorials on how to setup Gentoo with this kind of setup without LVM2 or truecrypt. I can't find anything helpful in the way of instruction on how to setup LVM2 and dm-crypt together in this manner. And I haven't been able to find much of anything for setting up truecrypt. Any help or advice is appreciated.

----------

## guero61

Here's a bit I wrote about my exploits in this arena.  In short, you'll want LVM on top of cryptfs (I had an additional RAID-1 layer there).  To do it right, you may need an initrd, but you're already on your way there using a thumb drive.  I've long toyed with the idea of setting up an initrd that put a shim in before /sbin/init that would request a password and do the decryption for you, but I've just not had time to mess around with it.

What I really want is a bootloader that will do the password/decryption scheme, but that kinda goes beyond the scope of GRUB or LILO and more into the realm of xen or some other hypervisor.

One thing you should want to do is use LUKS - primarily because it's compatible with several open source cryptfs paradigms, including some for Windows.

----------

## StargateGamingGeek

What does all that really say? I got most of it but alot of it didn't make sense. That may be because of my lack of experience with LVM but here's my question for you. I was hoping to set it up so that you only have one visible partition and set the rest up using logical volumes inside the bigger physical volume. Resizing isn't an issue really I just wanted LVM for that because I seem to remember seeing a howto using encrypted volumes and LVM in a setup like that but I can't find it anymore.

----------

## guero61

This is how I did it; there are likely holes, so don't take any of this for perfect truth:

1.  cryptsetup luksFormat <my encrypted partition>

2.  cryptsetup luksOpen <my encrypted partition>

3.  edit /etc/lvm/lvm.conf & add "types = [ "device-mapper", 16 ]" (less outer quotes) to the devices block

4.  pvcreate /dev/mapper/<cryptvol>

5.  vgcreate -n VGCRYPT /dev/mapper/<cryptvol>

6.  Partition out your LVM w/lvcreate.

7.  Modify RC_VOLUME_ORDER in /etc/conf.d/rc to put LVM after cryptfs

8.  Edit /etc/conf.d/cryptfs to load your encrypted partition at boot

If that's still a bit confusing, I strongly suggest spending some time familiarizing yourself with cryptfs and LVM - each by itself is quite a technology to pick up and understand.

----------

## StargateGamingGeek

That is a bit clearer yes. That was kind of what I figured I'd end up having to do was find a spare drive and just install gentoo a bunch of times and mess with the process until I finally got it right the way I wanted it. Thanks for the help. I'll keep posting results as I get them. Anybody else has any advice please post. The way I see it there's a place for trial-and-error but why does it all have to be your error when others may have paved the way and can help you steer clear of the error? That is why I love forums like this. There is always someone who does done something at least close to what you want to do before or has seen someone that did.

----------

## Reikinio

Hi, 

Just to let you know, that you might be interested in a guide I wrote(see sig), it documents the process of setting up an encrypted Gentoo system using dm-crypt, crypsetup(luks). 

It's far from perfect, and it doesn't contain instructions for lvm since I didn't consider it necessary for my setup, but it does contain instructions for booting from usb-stick(although at the moment the gpg key has to reside on the initramfs, I'll try to change this in the future since I think it's silly).   

Anyway, see if you can find anything useful on it.

Bye

----------

## StargateGamingGeek

I was browsing around through an LVM tutorial and all the sudden I had one of those Eureka moments. I was re-reading the terminology involved with LVM and suddenly it clicked. Anyone who knows about LVM feel free to correct me if my epiphany was not complete but here goes:

What I'm looking for is setting up a real partition as the PhysicalVolume(PV) for LVM. Breaking that into three LogicalVolumes(LV's) which are basically "partitions". Making one of those SWAP and one / and the other /home. Then pass those LV's to DM-Crypt and create a mapping and a filesystem. The DM-Crpyt stuff I can do following Reikinio's Guide. The LVM stuff I'll need to find conrete instructions on but at least I have a Model for what I'm Looking for now. To DM-Crypt the LV's should be nothing more than partitions on a normal setup so there shouldn't be a problem there. So it would look like:

                              ----> LV1 --> DM-Crypt mapping --> filesystem --> /

                            /

/hda--->LVM(PV)-<------> LV2 --> DM-Crypt mapping --> filesystem --> SWAP

                            \

                              ----> LV3-->TBD

The only missing link comes from LV3 which is /HOME. I want to try and encrypt it using truecrypt. I think I can manage to auto-mount /HOME at user log-in using PAM once I get it setup. I just have to find out some stuff about using truecrypt in this kind of scenario first. Like I said any sort of opinion or experience that might be helpful here is appreciated.

----------

## Clansman

Hi everyone.

I've been on to this issue for some months now, but I don't think there is (yet?) an elegant solution. I don't know what happens under the hood, but from the user's perspective, the elegant solution is one like OSX'.

You see, most of the filesystems are practically of no use for others (unless you're not careful where you put your data). What really REALLY matters is users's data - homedirs.

The perfect solution would be to have filesystem level encryption to support dinamic size and encryption keys/algorithms per user. The perfect solution is to say: "this subtree is from now on secured with encryption algorithm XYZ, hashing algorithm ZYX, the key is stored _here_, use _this_ password (or login's) and put a recovery key _there_", and that's it! no loopback volumes of fixed size, no global encryption, no different complicated setup for desktops/servers/etc., no fixed algorithms/keys, ...

Man, when (not if, I'm a believer) Linux gets there, there will be much rejoycing  :Very Happy: 

Care to comment?

Cheers guys,

----------

## guero61

The difference is what your expectations are.  If you trust the system to never be touched, never be compromised and only want to protect users' data, then yes - only encrypting /home is a reasonable approach.

However, if you're paranoid (like me) and want to assume that at any point in time someone has been able to take your drive[s] out and image them or replace system binaries with trojaned ones, then full-disk encryption is the only viable approach (no, tripwire can be circumvented too at that point - don't go there).  We're talking fully hostile environment here, with pwn4ge intent - not stealing data.

My perfect solution would be a hardware drive controller that requires a dongle and takes a boot-time password (during POST) before the OS even starts.  I might still encrypt some files therein, but the intent is to completely mask what's on the drive and prevent any tampering whatsoever, short of destroying the data.  If such a thing exists and is reasonably priced, someone please point me there.

----------

## Clansman

Maybe my proposal isn't appropriate for state secrets or something like that. It's just a very effective and elegant solution for a very common problem (that most people aren't aware of).

I couldn't care less if someone stole my wireless shared key by stealing my laptop, but I'd pissed (and eventually fired) if my personal and professional information would be compromised. Guess where that is? /home, of course.

Anyway, experience taught me that security is inversely proportional to usability (just look at all the work you guys are having to encrypt the whole filesystem with 1 key and 1 algorithm). So the best solution is allways, but I mean ALLWAYS a compromise. What good is a uber-secure server if you can't use it?

Consider the situation where you use different linux desktops or servers and you have your home in an USB drive. It would great if my proposed scheme was possible! The only information that matters is what's in the USB drive and no thief can use it. At the same time, all desktops would be able to mount and use my home directory before my credentials  :Smile:  remember that encryption is at filesystem level so the mount procedure would be transparent.

Well, I'm just thinking out loud.

Cheers,

----------

## StargateGamingGeek

Actually most of this stuff when fully implemented will be as simple as you are wanting. Once you get it setup you can have it so with one password at boot you get everything mounted except /home. Then with your user password you can access the credentials and mount /home. If you store the credentials for all that mounting on a USB thumbdrive and password protect them and probalby GPG encrypt them you made them secure and added another authentication facotr to the mix meaning that now you have Two-Factor-Authentication as opposed to single-fact-authentication. That is better for security because it means you can trust that you are who you say you are with higher reliability. Your points about setting it up are valid of course but once it's setup right you can do this all as easy as you want to. In fact if you don't mind the compromise to security you can have it decrypt everything except /home just by having the USB Token plugged in at the right time but you sacrifice the two-factor-authentication for that decryption which can be an issue if you are concerned about the security of things that may accidentally get out of your /home partition. But like I said your points on setup are fully valid and are something that is being worked on by many as we speak. DM-Crpyt is something that is built into the kernel as is LVM2 it just needs a simpler list of commands to set it up. Or more likely to be able to satisfy you a GUI. However most people that use Linux and especially the kind paranoid/tech-savvy enough to do something like this aren't going to be afraid of doing some work at a command prompt. In fact many would prefer to do it themselves at a prompt than to trust that someone else had done it right in a script and remove a possible weakness in the implementation by doing the setup themselves.

----------

## Clansman

 *StargateGamingGeek wrote:*   

> Actually most of this stuff when fully implemented will be as simple as you are wanting. Once you get it setup you can have it so with one password at boot you get everything mounted except /home.

 

Already too much, but if set optional, becomes acceptable.

 *Quote:*   

> Then with your user password you can access the credentials and mount /home.

 

Not of interest due to the fixed size nature of mounts. What'd be interesting would be to be able to use (not mount!) /home/pjlv after login, by using user's credentials to enable transparent encrypt/decrypt to/from that folder.

 *Quote:*   

> If you store the credentials for all that mounting on a USB thumbdrive and password protect them and probalby GPG encrypt them you made them secure and added another authentication facotr to the mix meaning that now you have Two-Factor-Authentication as opposed to single-fact-authentication. That is better for security because it means you can trust that you are who you say you are with higher reliability.

 

Yes, I know and I use such methods in specific situations, but come on! that's not at all practical for everyday use. And where would you carry your gpg keys if you want to use your gpg-encrypted usb drive in different computers?

 *Quote:*   

> Your points about setting it up are valid of course but once it's setup right you can do this all as easy as you want to.

 

I've yet to see the technology to do such on Linux. That's my point!

 *Quote:*   

> But like I said your points on setup are fully valid and are something that is being worked on by many as we speak. DM-Crpyt is something that is built into the kernel as is LVM2 it just needs a simpler list of commands to set it up. Or more likely to be able to satisfy you a GUI.

 

But dm-crypt/LVM work on a mountpoint basis and that's not practical. Again the mountpoints.

 *Quote:*   

> However most people that use Linux and especially the kind paranoid/tech-savvy enough to do something like this aren't going to be afraid of doing some work at a command prompt. In fact many would prefer to do it themselves at a prompt than to trust that someone else had done it right in a script and remove a possible weakness in the implementation by doing the setup themselves.

 

Of course. However I also identify myself as a security guy/tech-savvy/geek. Some of my data is kept on CDs, encrypted with one pwd protected GPG key and signed with another - no gui to do that (that I know of). Some of my professional transactions are made upon truecrypt CDs with password protected keys distributed in separate medium (there's a gui for that  :Smile: . 

I don't mind rolling up my sleeves and getting to work, hacking shell scripts or some perl/python code or even C, but I think about technology in a way that it must help me do stuff better and faster and not the other way around!

Cheers,

----------

## guero61

There's only one misnomer I'd care to address:

 *Clansman wrote:*   

> due to the fixed size nature of mounts

 

Fixed mount sizes are only an artifact of improper implementation.  If you implement your LVM on top of cryptfs (as I have), flexibility is regained.  The lower on the stack your encryption is, the more flexible your storage options - hence my desire for a disk controller w/hardware encryption.  Take, for example, how one of my systems is stacked:

```

 XFS    XFS    XFS

  |      |      |

  ---------------

         |

        LVM 

         |  

      cryptfs

         |

    ---RAID-1---

    |          |

   120G       120G

```

I have two 120G drives that I wanted mirrored (one is external on USB-2.0), encrypted, and running LVM for disk allocation.  Since cryptfs is the chokepoint (we all assume, but is it really?), I can't expand this specific setup beyond 120G, but I have a very reliable, very flexibly manageable secure storage setup - I call it 'VGSAFE', and store all of my documents, pictures, and such that I can't stand to lose but don't want anyone else to have.

BTW - I'm not sure where it is because it doesn't entirely interest me, but I've seen a HOWTO floating around describing how to use PAM and loop-AES to automount encrypted home directories.

----------

## StargateGamingGeek

I get the feeling you are just ignoring some of the stuff I said. I fully agreed with your points on how it needs to be made less complicated to do. I pointed out that alot of people feel safer doing it the hard way but I don't mean to imply that that is how it should be done at all. As I said again it is something that must be customized in implementation to the setting where it is used. Not everyone can deal with having a password to mount root and a passwor to mount /home so you can do away with that. Also GPG is only one option for how that can be secured. You can leave it in the clear really. It's about how paranoid you want to be. Again it comes back to customized implementation. Certificates could provide the same functionality without the need for keys to be encrypted. But I wonder about your comments on using your GPG encrypted USB token on multiple computers. Mainly why are you using the same keys on multiple computers? That's not such a good idea. And if you are moving data on the Token then a different solution may be required. Say a self extracting encrypted file with a password on it. That would be portable and encrypted and growable. If you want a "mount" solution that isn't size limiting and want to grow your stuff then consider loop-AES which allows you to setup a file as a filesystem and should as a result allow you to expand it as needed. I'm not sure if you can expand that however so you would have to check. The point is that you have options. That is one of the main reasons I was drawn to opensource, the options. There isn't just one way you can do something but alot of different ways to do it that can be made to work for your specific situation. If some of this stuff won't work for you there is no need to complain about how that's not right or whatever just look around and find something that is right for you. The options are out there and all you have to do is look for them. If a GUI is what you require then you could use some of your time and coding skills and help write one. Complaining is not something that will help get you anywhere. 

Going back to your original post about your scheme here's some ideas:

You could keep the /home on an external harddrive giving you the size you want and keep the keys and the static software on a usb thumbdrive and use that to acess your /home.

Or you could keep a large loop file on whatever you use for storage and have a digital certifacte in the clear on the storage medium and your encryption program. I know the winblows version of truecrypt can run in traveller mode so you never have to install it but can still access it from any computer maybe the linux version has a similar feature? Even if it doesn't there are similar products that might. I'm sure there is a way to implement the scheme of which you spoke it just may not be entirely seemless in setup. At this stage that is something you just have to accept. Encryption in linux hasn't gotten to the point where it is fully integrated and seemless. It is still something that has to be done almost hacked together. But the more people use it and help refine the programs and systems involved the sooner it will be ready to be integrated so that it can be seemless.

----------

## Clansman

Sorry if I seemed to ignore you. That was not the purpose. Also I wasn't clear on some points either, but you all got the general point and your last comments show that you understood the idea.

The method of having lvm on top of cryptfs is nice and makes sense, but what if I want to expand my VGs, is there a way to create another cryptfs on another md device with the same key and then do some more PVs there? I'd say it can.

I'm thinking in investing some time onto it for my laptop. Since I'm the only user, I'll probably mount /home on an lvm on top of cryptfs. --> Time to investigate!

Again thanks for the comments.

Cheers,

----------

## Carlo

Be sure to have read this article, before you choose a crypto implementation.

----------

## guero61

@Carlo

I appreciate that article - haven't seen it before.  I wonder, though, if it's not a bit irrelevant since it specifically states, "dm-crypt in kernels prior to 2.6.10" - if dm-crypt was fixed then and since most of us are using 2.6.16 series kernels, we should be okay using it...  The other stuff doesn't count *as much*, since we're (SGG & I) are primarily discussing full-disk encryption w/dm-crypt.  I'll have to dig more before I commmit a whole-disk installation to this.

@Clansman

I don't see any reason you couldn't do that very thing - in fact, doing that makes a nice end-around on the [assumed] cryptfs chokepoint.

Does anyone have any specific documentation (I'll look myself) that dm-crypt filesystems cannot be expanded?

----------

## Clansman

Thanks. That's very nice reading!

Cheers,

----------

## StargateGamingGeek

I have a question mainly for guero but anybody is welcome to answer. You mentioned having put the crypto layer first then lvm would that still allow you to have a single large partition and then slice it up into smaller partitions using LVM? And could you then add another layer of crypto ontop of the lvm layer in order to have swap with a random key and other things like that?

Also I found an article talking about dm-crypt and various things and the reason I mention it is because of an interesting idea brought up in the comments. Namely that you could create a temporary mapping with dm-cryt using a long key generated from /dev/random and then write ti that mapping with /dev/zero and fill it with random data quickly. It seems like it might work aybody tried anything like that or know of a reason why it will or won't work?Last edited by StargateGamingGeek on Thu Jun 15, 2006 3:16 pm; edited 1 time in total

----------

## guero61

 *Quote:*   

> 
> 
> would that still allow you to have a single large partition and then slice it up into smaller partitions using LVM?
> 
> 

 

Precisely - see the above diagram.

You could add N levels of indirection, but once you have a layer of crypto between you and the disk, additional encrypted stuff is primarily overhead and not so necessary.  I've not done full-disk yet (getting ready to), but I personally will probably make a separate physical swap partition and then use cryptfs to set up encrypted swap there - less overhead, since performance is somewhat key on swap space.

swap --> cryptfs --> disk

vs.

swap --> [cryptfs] --> lvm --> cryptfs --> disk

----------

## StargateGamingGeek

@guero  That's great to hear it will make my life a bit easier. I wonder how much difference that would make to swap? and would you gain much in the way of security? over un-encrypted swap I'm sure you'd be more secure just by having  the encryption layer either way. I might have to try it in different setups and check the speed gained/lost. I was really liking the security idea of just having a partition filled with "random" data and no visible OS and having unencrypted external /boot so as maybe to gain some plausible-deniability. Give them the whole "I was messing with some crypto stuff just for kicks and nuked my data partition" type scenario.

----------

## guero61

 *Carlo wrote:*   

> Be sure to have read this article, before you choose a crypto implementation.

 

Researched it a bit - the weakness discussed is specifically weak IVs, the same weakness that makes statistical attacks against WEP so effective.  Reason being was that older cryptoloop implementations didn't use IVs at all (ECB) and dm-crypt was intended to provide backward compatibility.  However, dm-crypt by default uses 'plain', which is better (than ECB), and as is evident from the cryptsetup-luks man page, you can specify 'essiv' as your IV generation mode and avoid the [specific] watermark weakness.  Evidently, ESSIV was introduced in 2.6.10, hence the mention of that specific version.

All that said, it seems dm-crypt is resizable, and that online; so, kids, use a recent kernel and specify ESSIV with the '-c' argument, and we should be safe from all the bears that have been brought out thus far.

----------

## Carlo

guero61: The article gets updated regularly and quoting the relevant part

 *Quote:*   

> Although kernel 2.6.10 includes a patch that adds a new IV mode "encrypted sector|salt IV" that improves the security of dm-crypt (according to the author of the patch), loop-aes's crypto implementation is still stronger than recent dm-crypt:
> 
>  *Quote:*   Jim MacBaine wrote:
> 
> > Since then, dm-crypt has obviously caught up.
> ...

 

the implementation is still considered problematic. It may be safe enough for local use, but apart from that it's still possible to select absolutely unsafe encryption, so (as always) you should know what you do.  :Wink: 

----------

## guero61

guero61 smacks himself

Note to self: re-read 3x before posting any synopsis.    :Rolling Eyes: 

----------

## troymc

I've been running something similar for a while.

```

hda1 --> dm-crypt --> swap pri=1

hdb1 --> dm-crypt --> swap pri=1

hda2 -->|

        | --> RAID1 --> dm-crypt --> /tmp [ext2]

hdb2 -->|  

hda3 -->|

        | --> RAID1 -->  / [reiserfs]

hdb3 -->|  

sda1 -->|

sdb1 -->|

sdc1 -->| --> RAID5 --> dm-crypt --> LVM

sdd1 -->|

sde1 -->|

```

I would like to encrypt / as well, but I need the server to come up unattended and I have not found out a solution to that yet. [/tmp & swap use random keys]

Thanks for that info guero61 & Carlo! I've had this up & running for awhile so I will need to check to see if I'm affected by that weakness. I know I'm not using essiv in my cipher, so I'm pretty sure that I have some work to do. I don't know if I'm willing to switch crypto implementations so I'll just have to hope that they get it fixed before the NSA comes after me.   :Shocked: 

troymc

----------

## StargateGamingGeek

I am back with a few more questions. First I was wondering as I finally near the time to do this for real if the Gentoo discs available for download contain the kernel modules that would be required? Basically does Gentoo come with support for LVM, DM-Crypt, various ciphers, whatever else would be required for this type of install, compiled into the kernel or as modules? If it doesn't can I get those on a thumbdrive or something so I have them to load into the kernel for the install? Cause even though it would work I don't want to have to install this to a drive compile a proper custom kernel and make my own livecd to install from. As always any help is appreciated, and I tried to look for a listing of the stuff that came in the kernels before I posted but couldn't find anything.

----------

## troymc

 *StargateGamingGeek wrote:*   

> First I was wondering as I finally near the time to do this for real if the Gentoo discs available for download contain the kernel modules that would be required? Basically does Gentoo come with support for LVM, DM-Crypt, various ciphers, whatever else would be required for this type of install, compiled into the kernel or as modules?

 

Yes, most of it will be modules. Just check in the /lib/modules/`uname -r`/kernel/drivers/... directories for the correct names.

The RAID modules are called raid0, raid1, raid5, etc.

The dm-mod module will be needed for LVM & dm-crypt.

The dm-crypt module will be needed for dm-crypt.

The cipher modules should be auto-loaded as needed.

And, all the filesystem modules should be available as well.

troymc

----------

## StargateGamingGeek

Thanks for the prompt reply troy. That is very reassuring. I think I'm ready to give this a shot now.

----------

## troymc

 *StargateGamingGeek wrote:*   

> Thanks for the prompt reply troy. 

 

It's a *very* slow day at work. The data center here is dead. I'm having trouble just staying awake.   :Confused: 

 *StargateGamingGeek wrote:*   

> That is very reassuring. I think I'm ready to give this a shot now.

 

Good luck!  And let us know how it turns out.

troymc

----------

## StargateGamingGeek

I will be sure to keep you all posted, that almost feels like a horrible pun or something.

----------

## 1clue

 *guero61 wrote:*   

> The difference is what your expectations are.  If you trust the system to never be touched, never be compromised and only want to protect users' data, then yes - only encrypting /home is a reasonable approach.
> 
> However, if you're paranoid (like me) and want to assume that at any point in time someone has been able to take your drive[s] out and image them or replace system binaries with trojaned ones, then full-disk encryption is the only viable approach (no, tripwire can be circumvented too at that point - don't go there).  We're talking fully hostile environment here, with pwn4ge intent - not stealing data.
> 
> My perfect solution would be a hardware drive controller that requires a dongle and takes a boot-time password (during POST) before the OS even starts.  I might still encrypt some files therein, but the intent is to completely mask what's on the drive and prevent any tampering whatsoever, short of destroying the data.  If such a thing exists and is reasonably priced, someone please point me there.

 

I realize that this is way later than the post I'm responding to, but your idea has a hole in the logic.

If you've booted off your encrypted drive, then somebody intrudes on the running system they still have access to your drive.  Any malware that writes to your drive will automatically go through the encryption layer of your mount, write the files in a usable form in spite of your encryption, and the malware will function as designed.  Your setup would prevent some thief from stealing your laptop and getting data out, but it wouldn't prevent a runtime intrusion.

You would still want to have a hardened system, in addition to your encrypted filesystems.  I've thought about using a smart card to hold a drive encryption key and then chain that to my pants, but it does exactly nothing to protect you from a network vulnerability.

----------

## StargateGamingGeek

I'm back to post progress and ask a couple questions I think will come up during the install. First the progress: I had to spend some time defragging and shrinking and partitioning the drive first cause I needed to preserve the windows install and have a shared FS as well. That took a while but I got it done. After that I ran a badblocks check overnight. I have it running dd if=/dev/urandom right now. Once that finishes I'll be ready to see just how far the rabbit hole goes.  And now the question. Using LVM2 for / I will need to build that into an initrd or initramfs from what I've read. The guide on DM-Crypt w/ LUKS I am using uses and initramFS but the only guide for LVM2 / I found uses an initrd. I am hoping someone can help me to merge the two. As I will need the init's from both guides to boot the system.

----------

## StargateGamingGeek

I always feel bad replying to my own forum posts but here goes. I have made much progress and am at step 7 in the handbook, Kernel Configuration. This brings me to a question that maybe someone here can help me with about initramfs. I need the functionality from Reikinio's guide, which is one of the primary resources I've been using, to get DM-Crypt working properly at startup but I also need to include support for LVM and get both setup and working from the same initramfs. Anyone have experience with that or could quide me n the right direction as to what I would have to add? Thanks for the help you have all provided so far.

UPDATE:

After looking around further it seems like all I should have to do is add a couple of lines of code to the /init to activate the VG and then to mount the / LV. Has anyone tried that or soemthing similar or just know if it would work? Once that's done the /etc/fstab should be able to handle the rest right?

----------

## StargateGamingGeek

And to make this even more fun the network connection on my laptop won't work so i'm doing all this networkless. Any help would be appreciated as I'm starting to get a bit frustrated with this thing. I'm at the point of making the initramfs and much to my dismay I'm starting to wonder if gen-kernel with the luks support will create an init that will allow me to boot the system. Anybody has any helpful information please let me know.

----------

## troymc

Hey, sounds like you're making good progress.

If you are going to use his instructions on creating a initramfs, then you'll need to make a couple of changes/additions.

1st, you'll need to include either a statically built lvm2 binary or it and all its libraries. (I recommend static.)

2nd, you'll need to modify his init script & add your vgscan & vgchange -ay commands right before his umount commands.

You might also have device issues, depending on whether your device nodes are static or you are running udev.

troymc

----------

## StargateGamingGeek

Thanks that's what I was hoping for. Just have to find a static LVM2 somewhere I can download or figure out how to staticly compile it from the liveCD cause like I said the net connection on the laptop isn't working right for some reason. And would you reccomend static dev nodes or udev and what might be the issues involved with both? Unfortunately most of my previous experience with Linux was pre-compiled distro's and this is one of my first ventures into the world of source-based distro's.

UPDATE:

As I was looking around for a convenient pre-compiled lvm2 I found this page. Anyway on to the question I was reading around and I saw this:

 *Quote:*   

> The root partition (if it isn't also the boot partition) may be a logical volume.  However this means the kernel must access the root partition before it can load any (e.g., LVM) kernel modules.  Thus the modules for LVM must be compiled into the kernel.  This is rarely the case with standard distributions!  (There is a similar issue with SCSI drivers, as most kernels only compile in the IDE drivers.)  For this reason, as well as allowing a filesystem to be accessed by another operating system (yes there are ext2 drivers available for Windows), some system administrators prefer to make the root filesystem on a regular partition rather than on a logical volume.  Note in this case you can make a single root+boot partition.
> 
> The solution to using a logical volume for your root filesystem (as it is with SCSI) is either to build a custom kernel with the correct drivers compiled in, or to make sure the system loads a RAM disk initially, known as initrd, which contains all the correct modules.  This RAM disk then loads the system as normal, and goes away.  Creating a ramdisk on Linux is simple using the mkinitrd script.  Just run this command (as root). You need to know the kernel version, and then you must update grub.conf to use the ramdisk: 

 

Now from the look of that it seems as though I could get away without a lvm binary is that true? And if it's not which files do I need to add to the initramfs? Also I thought in that article but it may have been somewhere else that I read that LVM2 was compiled static by default or something anyone know on that either? Thank you all so much for putting up with my questions and supplying your help.

----------

## StargateGamingGeek

I know it's the 4th of July and most of you in the US will be busy but maybe someone can help me out here. I hate to seem pushy or anything and I'm sorry for that but this install has taken a few days so far without a reboot cause I don't want to lose anything. I think pretty much the last thing I need to figure out is if I can get by with just LVM compiled into the kernel and copy /sbin/lvm to /sbin of my initramfs or do I need to have more than that? If I need something else then I may be in for some trouble as a result of not having a working network connection for my laptop right now for some reason. I do have a second USB thumbdrive aside from the one I'm using as /boot so I can download things from my desktop and transfer them but I tried that with LVM and it seems to be unable to find some dependencies which is odd as it has LVM working just doesn't appear to be static.

----------

## StargateGamingGeek

Well back now with what may be a somewhat obligatory Futurama paraphrase of: "News Everyone". Normally good but this is at best mediocre. I got through everything finally and finished up. Bad news is I can't get my USB thumbdrive to boot into the system. When I reboot with it in the USB port nothing happens. I mean nothing black screen while it's probing devices to boot from them it goes to wondows. To make sure it wasn't a BIOS problem I have everything in my boot options above the harddrive and it's not picking it up so that's not it. I tried it on a different BIOS which can boot USB so that's not it. I must have done something wrong with extlinux is all I can think of. Anyone have any ideas on a small bootloader I can run off a USB thumbdrive? The thumbdrive is 256MB and it still needs to have room for the kernel and the initramfs and eventually the gpg keys. Speaking of the kernel, while I'm on the subject of that during the instructions in Reikinio's guide he said to do 

```
 cp kernel /mnt/usb/vmlinuz
```

 while in /usr/src/linux. I am unsure as to whether that is meaning the folder kernel or vmlinux which I have seen in various other distros being booted like it was the kernel. I did both plus the Handbooks 

```
cp arch/x86_64/boot/bzImage /boot/<kernel-version>
```

. I have all three in the proper places on the thumbdrive and I have proper entries for all three in the extlinux.conf. It's likely that may be causing at least part of the problem but until I could figure out which of the three I needed I figured it was safer to have all three. I suppose if I had to that I could install a bootloader on the mbr of the harddrive and have it point to the stuff on the thumbdrive but I didn't think there should be any cause to do that. Anyway thank you all for your help and patience.

<sits back and tries to wait patiently for help>

----------

