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.
As I just ordered a new ssd for my laptop I'm wondering if I should switch for a lvm installation.
As it is a laptop that you likely carry around I would think you should encrypt your harddisk, for which you need to use LVM. I do this consistently for laptops and works without problems.
I'm still on old fashioned spinning metal, but I've been a strong advocate for using LVM for years.
Advice:
Learn the concepts and commands, don't just follow some lvm install guide and think 'job done'.
Leave some unallocated space in your volume group to meet any future demands (like Richard has done).
Give your VGs and LVs consistent and meaningful names and don't use something like "vg00/lv00" (which I've actually seen from time to time -- I think it might be the default in certain distros installers).
If you do decide to use LUKS, backup the header and put it somewhere safe. You don't want to lose an entire disk simply because one sector gets corrupted.
Pros:
It's very flexible and adds an extra layer of abstraction (which can be useful.. i.e. device name independence).
Cons:
It adds an extra layer of abstraction (which you need to understand).
Certain user's 'Home directories' are actually stored under /srv/crypt/home and symlinked into place: dependent on whether the user is a "personal account" or something more functional which doesn't need encryption and just lives in /home (such as my 'build' user).
/tmp is on tmpfs.
Anyway, between what Richard and I have posted, I'm sure you can see the possibilities are endless and purely a matter of preference.
Thanks for your feedback and the time you took for your answer !
I'm thinking of this kind of parts / lvm :
Code:
/boot part 1 not crypted
/part 2
--/ crypted
--/home crypted
--/usr crypted
--/var crypted
--/var/run crypted
--/var/log/crypted
--/mnt/vm not crypted (img for vanilla slackware to test builds or Windows to run crap softs I can't have in slackware)
--/mnt/data not crypted (repos, build env)
--/mnt/multimedia not crypted (music, movies)
--/mnt/photos crypted (personnal pics)
--/mnt/backups crypted (phone and other backups
--swap crypted
--/tmp crypted
--/tmp/SBo tmpfs
--/tmp/build tmpfs
I will start with the allocated space taken on my actual install to evaluate what's needed for each.
Still wondering how much I should allocate to tmpfs for compiling (got 6go of ram) and how it really works...
Swap might be at least 6go to have hibernation but still have to dig how it works since I read that hibernation uses compression (have to find what would be the better ratio and how to configure that).
Fotunately I have a week before the drive is delivered :-)
To be able to use trim on a encrypted disk one needs to add the --allow-discards option to cryptsetup.
Here is a little script that adds this to the initrd-tree which mkinitrd uses:
Code:
#!/bin/bash
DIR=/tmp/fixinit
rm -rf $DIR
mkdir -p $DIR
cd $DIR
tar -xf /usr/share/mkinitrd/initrd-tree.tar.gz
sed -i 's#/sbin/cryptsetup ${LUKSKEY}#/sbin/cryptsetup --allow-discards ${LUKSKEY}#' init
tar czf /usr/share/mkinitrd/initrd-tree.tar.gz .
It's very flexible and adds an extra layer of abstraction (which can be useful.. i.e. device name independence).
I'll add that lvm makes it very easy to swap out hard drives. Create the new physical volume, add it to the volume group, run pvmove while the system is running to migrate everything off the old drive, remove the old physical volume from the volume group when it's done.
If you have a bay such that you can access the drives, you don't even have to power down while doing all that. Pretty neat when you need it.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
