You are not logged in.
Pages: 1
Hello everybody,
after crash of one of my HDs I decided to install Devuan Ascii from scratch to a new SSD. The system has another HD which uses LVM and is partly encrypted. This old HD had a Debian system which was successfully upgraded to Devuan-Ascii quite a while ago. Now I like to install the whole system from scratch (to SSD) and the other HD will be used to serve /home (which is currently in an LVM-group and encrypted).
The aim of my installation is as follows:
boot (no LVM, not crypted)
root (LVM)
tmp (LVM, crypted)
swap (LVM, crypted)
home (LVM, crypted)
usr (LVM)
opt (LVM)
var (LVM
var/tmp (LVM)
var/log (LVM)
home (on old HD: LVM and crypted)
I use devuan_ascii_2.0.0_amd64_dvd-1.iso per dd on a USB Stick. After booting, installer is running and guides me through. Everything fine so far, until the process of enabling LVM, crypto and partitioning starts. I've tried it several times but still I don't have a glue of how I can get my partition scheme with LVM and crypto like above. I use graphical expert install and that lets me choose some stuff, but in the main installer during partitioning I get somehow lost. The process does not give ma a feedback of how to make what at first and what follows.
So a little help is needed: After setup for boot-partition - do I have to define LVM for the rest of the SSD, setting up volume-group and logical volumes and the crypted parts? Or vice versa or something in between? What is my way?
And afterwards I like to use the existing home partition. Best would be if I could use the hidden files in /home on the SSD and the data in /home on the HD. I think the speedy SSD gives some advantage here. Means home would be stretched over two physical devices with LVM and crypto. Is that possible? What are the steps for enabling that?
Have a wonderful day and thanks in advance for your wonderful help.
Walter
Offline
I believe it's possible to do what you want, but you might need to do some of it manually. I've done encrypted lvm installs before, but I've never done it with an existing lvm that had data on it. See these two threads (and some of the links in them):
https://dev1galaxy.org/viewtopic.php?id=674
https://dev1galaxy.org/viewtopic.php?id=2323
The procedure in the debian-installer for encrypted lvm is not at all intuitive. It goes something like this:
Make an encrypted volume from a partition.
Use the encrypted volume for lvm.
Create the logical volumes inside the lvm and assign mountpoints and filesystems for them.
For reference, here's a video of making an encrypted partition, without lvm. The "4" on the end of the file name is because it took me four attempts to get it right, even though I've done it many times. This will give you a sense of the logic used in the installer.
http://distro.ibiblio.org/refracta/misc … rypt-4.ogv
Offline
Hi Walter,
you have selected a very complex and granular setup. Is that really required? I have setup ASCII encrypted on a SSD (what is the difference to a hard disk?) with:
- efi as vfat
- boot 2048 Mbyte ext4
- system partition 64 GByte luks encrypted, LVM contained with two logical volumes for swap and /
- home on separate drive, luks encrypted
Is simple, no problems to be expected with one of the granular partitions to run full. Requires one password for the system and one for home. home on the separate drive was mounted past the installation.
You can naturally setup a LVM with 9 logical volumes and separately encrypt tmp, swap and home.
BTW: if you mount your hard disk containing your old home to /home on the SSD, the data on the mount point are no more accessible. You only will see the hard disk data there.
Regards, rolfie
Offline
Hello,
@rolfie
True its a granular setup. I remember working that out with the help of some security docs and thoughts about maintenance. More than 10 years ago (I still have entries in the history of packet manager from 2008). I suspect in the meanwhile the kernel and some other security implementations are far more advanced than at that time. But honestly I am not up to date. To me it makes sense to reduce the granularity, too. Especially because there were no big changes in the partition sizes during all the time. /Usr and /var could be a big bigger, and for opt there is no single file stored. So yes, thank you for reminding me, although I know there is a more or less religious discussion about that..
There is a predefined setup in the installer for /, /home, /var, /tmp and swap. I need to think about and maybe this would be a solution, but somehow I have a good feeling for a separate /usr-partition. Anyway that would reduce the stuff and makes it less complex.
About the home: I like to go for installing home on the SSD as well. After the bulk installation of SW, I would move all the hidden files to the old home. Then move /home to the old HD and ready (in between I will check if I could use the old hidden files as well). Thats my plan. And I think there will be one password only - that for /home. /swap and /tmp will use random keys. I will start that tomorrow.
@fsmithred
thank you very much, but I do have questions on that.
1) Make an encrypted volume from a partition.
2) Use the encrypted volume for lvm.
3) Create the logical volumes inside the lvm and assign mountpoints and filesystems for them.
Is this process meaning that I create a partition with a dedicated size outside LVM for the crypted ones. And in turn that lets me not change the size later on? Lets say my system wants more swap (which is crypted) - how would I achieve this? Inside LVM its very easy, but if the partition is fixed in total size by the setup during the encryption process, there is no advantage. Or do I misunderstand this?
Anyway guys - thank you very much for your time, patience and thoughts so far - very helpful.
Have a wonderful day.
Walter
Offline
If your lvm is inside an encrypted partition, you can still change the sizes of the logical partitions inside it. This way, everything is encrypted and you enter one password for the whole system. If you want to make the lvm bigger than the physical partition that contains it, you would add other drives/partitions to the volume group and then extend the logical partitions within.
If you're concerned about excessive writes to the ssd, then you probably want to keep it separate from the existing lvm, so it doesn't get used for any of your more active partitions. (When you add drives to a volume group, the combined space is seen as a single container, and data gets written to all parts of it.)
Offline
Guys,
I spent this morning with trying to reach my partition scheme with no success. I can't remember to have so many troubles with the installation 10 years ago.
OK - what I did was to follow the guideline of fsmithred and the movie was very helpful. Thanks again! Although I wanted to have two different crypted volumes /tmp and /swap. During the definition process inside the installer, suddenly I had two crypted /swap volumes. I suspect a bug here. Another painful situation is reached when I realize on the main partition manager screen with the overall view - it's impossible to make steps back. If an encrypted volume is created, there is no way inside the installer to withdraw it. I used a rescue pen drive to delete the bad partition scheme and started from scratch - I stopped counting it.
I am open for different installation methods and thinking about creating a preseeding config. Do you think with that method I would reach my partition scheme?
Have a wonderful day!
Offline
Caveat and disclaimer: I hate the debian-installer enough that I maintain my own installer.
Take a look at my post with examples of raid/lvm/luks with refractainstaller. I don't know how to do such a complex setup with d-i, but I'm pretty sure you could do it similar to one or more of my examples.
https://dev1galaxy.org/viewtopic.php?id=2323
If you want your home spread over both disks, then you need to have both disks (or at least part of each disk) included in the volume group (or in a raid array). Then data will be written to both disks (striped). That may increase performance.
If you then want /var, /tmp and swap to be only on the spinning disk, they need to be in a separate lvm or raid array (or not in the volume that includes /home.) The same would be true if you wanted them to only be on the ssd. If you're ok with them being spread over both disks like your home, then one volume group will suffice.
Offline
Caveat and disclaimer: I hate the debian-installer enough that I maintain my own installer.
I understand why are you doing that. I m thinking about all these old windows users and the simple process of installation. If they get confronted with this no wonder that they hesitate to switch over...and by the way just to be sure I pulled out my spinning drive for that process (lucky me). All in all not very amusing...
If you want your home spread over both disks, then you need to have both disks (or at least part of each disk) included in the volume group (or in a raid array). Then data will be written to both disks (striped). That may increase performance.
Aha - thats not exactly what I wanted to achieve. My idea was to get the hidden files of /home on the SSD and the other ones on the HD. So yes, /home will be spread, but I would like to have it in a way, that the often accessed conf-files are on the speedy SSD. The solution you explained does not provide an advantage, so I drop that idea for the moment.
If you then want /var, /tmp and swap to be only on the spinning disk, they need to be in a separate lvm or raid array (or not in the volume that includes /home.) The same would be true if you wanted them to only be on the ssd. If you're ok with them being spread over both disks like your home, then one volume group will suffice.
That I do not quite understand. I would like to have everything except /home on the SSD and /home exclusively on the spinning drive. To make that clear - I know during the installation process I have to setup a /home on the SSD as well. But this one I will not use further. I will try to use the "old" hidden-files from the spinning drive after bulk installation of user-sw to the SSD. If this does not work I will move the hidde-files of the fake /home on the SSD to the spinning drive. Or do I run into trouble here? There might be some manual work, but I think that is not so painful like the installer-partition part.
Offline
Aha - thats not exactly what I wanted to achieve. My idea was to get the hidden files of /home on the SSD and the other ones on the HD. So yes, /home will be spread, but I would like to have it in a way, that the often accessed conf-files are on the speedy SSD.
That could possibly be accomplished with some creative symlinking.
I would like to have everything except /home on the SSD and /home exclusively on the spinning drive. To make that clear - I know during the installation process I have to setup a /home on the SSD as well. But this one I will not use further. I will try to use the "old" hidden-files from the spinning drive after bulk installation of user-sw to the SSD. If this does not work I will move the hidde-files of the fake /home on the SSD to the spinning drive. Or do I run into trouble here? There might be some manual work, but I think that is not so painful like the installer-partition part.
I think you can get away with two or three partitions. Root filesystem and optional /boot partition on the ssd and /home on the spinning disk. Install everything to the ssd first, with /home as part of the root partition. Then manually edit fstab (and crypttab, I guess) to use the spinning disk as home. Move the new /home to /home.bak or something, so you keep the new config files in case you need them. And maybe make a backup copy of the old config files, in case they get lost or changed. Using the old config files with the new system may or may not work properly in all cases. It'll be trial and error until you get everything the way you want.
I forgot about swap. You want it encrypted. You could either use a swapfile inside an encrypted root partition, or you could make a new lvm on the ssd that includes the swap.
Offline
Hooray - got it guys!!!! What a ride...
OK, for all of you who want to go for something different than the partitioning tool with its predefined settings suggests (raid excluded - LVM/crypto only) during installation. Following an example of achieving this volume scheme on an USB pen drive:
lsblk creates:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sdb 8:16 1 57,3G 0 disk
├─sdb1 8:17 1 476M 0 part /boot
├─sdb2 8:18 1 1K 0 part
├─sdb5 8:21 1 28,9G 0 part
│ ├─vg01-root 254:0 0 9,3G 0 lvm /
│ ├─vg01-usr 254:1 0 14G 0 lvm /usr
│ └─vg01-var 254:2 0 5,6G 0 lvm /var
└─sdb6 8:22 1 14G 0 part
└─sdb6_crypt 254:3 0 14G 0 crypt
├─vgc-home 254:4 0 4,7G 0 lvm /home
├─vgc-tmp 254:5 0 3,7G 0 lvm /tmp
├─vgc-swap 254:6 0 1,9G 0 lvm [SWAP]
└─vgc-var_log 254:7 0 3,7G 0 lvm /var/log
The volumes /, /usr and /var are not crypted, but managed by LVM. The volumes /home, /tmp, swap and /var/log are crypted and managed by LVM. /boot is out of the box and a separate partition (not LVM-managed, not crypted). I tried quite many ways of achieving the scheme, but find one way only. Don't know if there is another option, if yes I would be happy to hear about, because I still have the challenge to include the old /home-volume which resides on another drive with all the data. Mounting is OK, but I have to give the password phrase two times, which bothers me.
Lets go...
First of all choose Manual Partitioning
Then the definition of the boot partition like this will result in a created boot partition.
Then a physical partition for LVM is required (see sdb5 above). The definition of the LVM Partition delivers this.
Now its time to create a partition for the crypted volumes. I choosed to not delete the data for a shorter installation time. The definition of the crypted volume leads to this.
I did not use the whole space on the pen drive for later choices
Now the crypted device needs to be configured and the changes to be written to disk with a brave "yes". Then choose to create crypted devices and select the defined crypted partition from the list. Then finalize and enter the passphrase when prompted and the result is this.
Now - the trick!: the crypted volume needs to be defined as physical volume for the Logical Volume Manager:
Oh holy crazyness...
Then follows the configuration of the LVM. First of all changes have to be written to disk (choose yes). For a quick check select a view of the config details. There are two (2) physical volumes!
Now volume groups needs to be setup. I start with a volume group for the crypted ones and name it vgc. Then I select the corresponding physical device. Be sure to select a device with a name something like "crypt". Then a volume group for the non-crypted ones which I call vg01 is using a device like this. Again check the config details.
Then logical volumes needs to be created:
group name size (cautionary tale)
vg01 root 10G
vg01 usr 15G
vg01 var 6G
vgc home 5G
vgc tmp 4G
vgc swap 2G
vgc var_log 4G
And the final LVM declaration is this. Go ahead and finalize this step. Now all the volumes are created and need a file system declaration, mount-point an so on. Now check the created LVM volumes step by step and setup each of them. Following one example for the logical volume root of the volume group vg01. Select the LVM root volume line and setup filesystem, mountpoint and other stuff. Repeat these steps for the volumes: /usr, /var, /home, /tmp and /var/log. For swap do it like this.
The final result. Now take over all the changes with a and the changes will be written to disk. DONE!
Maybe this is of help for someone. In any case do a backup in advance. I was a bit paranoid and built out my drives and made this with two pen drives only. Enjoy!
Walter
Offline
Pages: 1