Hello, everyone. I have /home LUKS encrypted and separate from /. Since the package versions used by Endeavour are more or less same as of Manjaro. I was thinking of just rewriting the root partition and keeping /home with all my configs as it is. And then later on installing any other missing packages.
Is there anything I should keep in mind before running the live USB?
How should I configure partitions, do I edit fstab after the installation?
Just split this post into a separate topic.
1 Like
Yeah, I should have created a new thread. Thank you for moving the query
2 Likes
Is only /home encrypted?
Or is the entire system encrypted? If yes, how? Multiple encrypted partitions, LVMonLUKS, LUKSonLVM, …?
What about /boot? Encrypted or not?
Hello, thanks for replying.
I did manual partition while installing.
/boot is not separate and there is no LVM stuff. I have a separate /home LUKS encrypted. / is not encrypted
Very unconventional 
.
I don’t know if calamares (the EOS installer) allows you to attach/choose a LUKS device as /home and then sets everything up for you automatically. I’d try that first. As long as you don’t format your /home this should be safe to try.
If that doesn’t work, you basically have 2 options.
A. To keep this type of setup, you’d
- do a normal unencrypted EOS install; you’d have to make sure to keep (= not delete or format) your existing encrypted /home partition by using the “Manual partioning” option
- from inside the new system you’d need to mount the encrypted /home by adding it to /etc/fstab so it gets mounted automatically at every boot
- Before you delete your old system, maybe take note of the following files
/etc/fstab
/etc/default/grub
/etc/crypttab
It’ll be easier to reproduce your old system with this information.
B. Go the “full disk encryption” route, by following one of the guides in the Wiki.You’d still have to make sure to keep (= not delete or format) your existing encrypted /home partition. Some of the guides would need some light “tweaking” if your encrypted /home is a partition on the same drive you’re installing to; not if its on a different drive. You’d
- just set up a new fully encrypted system and then
- copy your existing encrypted /home’s data to the new /home
- optionally delete the old encrypted partition and reclaim (add) its space to the new install
Think about it; do some Wiki reading and if you then need any help with option A or B along the way, feel free to ask.
And I thought while setting up that it was so simple and free of all the complications! 
Separate home for portability and convenience and encrypted for security.
I will try the first option and if it craps out then I’ll start over, I do have a backup. Thank you
As do i, for years. In older days i did this for the same rationale you wrote, but eventually learned that “undocumented behaviour” can ensue when you recycle this partition this way when changing / during next system installation. Essentially the issue afaik is legacy Plasma config files causing conflict craziness… & it can be unpleasant trying to troubleshoot.
Fwiw, this is the change i made a couple of years ago so that i could have half my cake to eat, given the whole cake could cause indigestion per earlier metaphor.
/boot/efias i came to prefer the GPT/UEFI combo//homewith LUKS encryption/datawith LUKS encryption
In this schema i keep only all the KDE system configs in /home. All the app configs & data live in… well yes duh; /data. I symlink them as appropriate back to the locations the apps expect to see them in /home [for the apps i can’t easily edit their data paths], or otherwise i do edit the individual apps’ data paths to point to my new locations in this non-home partition.
At those weirdo full-moon times when the urge to distro-hop overwhelms, i let the installer replace my initial three partitions, but only mount NOT format the data partition.
This schema seems to work nicely for me.
I run many of my apps in Firejail, which because of some limitations [its white & black lists only work on /home partition, not on /data] necessitates me tweaking & finessing the preceding, but that’s beyond the scope of your thread.
Good luck to you.
PS: You mentioned fstab. As long as you correctly point the installer to all the correct partitions, it will take care of fstab for you, including all the UUIDs etc.
PPS: This schema has been reliable when changing from an “Archie” to another “Archie”, coz their inherent “rollingness” delivers equivalent app package versions… though i would confirm this first. If changing from a non-Archie to an Archie or vice versa, you need to be more forensic in the pre-checks, coz if the non-Archie is also a non-roller its apps are highly likely to be older versions, & the corresponding app config files might differ.
If coming specifically from Manjaro to EOS, or to Arch itself, then if that MJ was Stable branch i personally would first change to Testing branch & update, then do the changeover.
7 Likes
Regarding your “unconventional” setup.
Don’t get me wrong, there’s absolutely nothing wrong with only encrypting /home or other important data. I was just wondering because most installers (like calamares for instance) and guides revert to full disk encryption as the default. You usually have to set your type of install up manually. I just don’t see that very often. 
From a security perspective I prefer to also have /boot and root encrypted so I personally always set up new systems in a full disk encryption scheme.
To get it up running as fast as possible I then install all of my needed packages in one go from a backuped list and rsync my /home backup.
But I usually only need to go through this when setting up new systems which then lack a preexisting encrypted /home anyway. I need a proper off-drive and off-site backup of important /home data anyway, so I don’t need to “bother” with reusing encrypted partitions.
Just out of curiosity: How do you manage the unlocking of these partitions? Multiple password entries, chain-unlocking via crypttab, …?
Thank you so much for your in depth reply.
Your partition scheme does seem more convenient. And regarding symlinking files, I assume you mean stuff like Music and Pictures and docs etc. to their respective positions under ~ ?
Yeah, I did do a manual setup a couple years back after I accidentally deleted my Arch user account and nuked it! I don’t think Manjaro had FDE back then, I could be wrong. I have been reading about various partition layouts and encryption schemes lately. How many passwords do you have to enter if you encrypt /boot as well? And does hibernate work?
Check here for some encryption schemes:
https://endeavouros.com/docs/encrypted-installation-2/
All the guides need only one password and have working hibernation.
3 Likes
I remain puzzled why you’ve now twice made this statement. With respect whilst it might not be your practice, it is IMHO far from unusual.
And so? I have no statistics on this, so i might be wrong, but i suspect that a majority of Arch, Arch-based, openSUSE Tumbleweed etc users are by their nature “fiddlers & tinkerers”, ie, users happy to not necessarily “go with the flow”, users who know what they want & know how to achieve it. As such, what’s the obstacle of a Calamares default? They, as do i, probably just click the “manual partition” radio button then setup their partition table specific to their needs, not someone else’s.
Then come look at all my installations & VMs. OK that’s cheekily fatuous of me, so more seriously, i have [as many of us also love] explored various distros & DEs in dozens of VMs over the past several years [it’s fun & also educational]. In the vast majority of these i was able to manually partition & create ext4 / with luks-/home [& in a tiny minority of these also luks-/data (these were when i tested the concept i later deployed “for real”)]. My basic point here being that all these installers support this, all the user has to do is bother to look.
On my own cognition initially i had no idea, so my first weeks of this were clunky with needing to enter my LUKS password twice during the boot. Later i sought help from the community in my then-distro’s forum, & received some magnificent help that i used & it worked fine for me. Atm i do not have time, but i promise you later today i shall find my notes & get you the info.
Yes correct, but more than that. Think also of Thunderbird, Firefox, Chromium, Vivaldi, CherryTree… yada yada.
4 Likes
I don’t want multiple passwords as i already have to decrypt the drive and then log in with a password. 2 is enough for me.
1 Like
@airmailsteam
I have installed the BTRFSonLUKs using the quick copy & paste version of the wiki by @2000 and it is working very nice.
Well, to be honest you find me somewhat stumped by the tone of your post.
I reread the thread and honestly don’t quite understand what got you so riled up.
But please accept my sincere apology if I at some point offended you or your views. This certainly wasn’t my intention!
(Now that I’ve gotten that off my chest, to prevent future misunderstandings, please believe me the following is meant in a non condescending way)
Thanks, but you don’t have to go looking for that info just on my behalf. I know how to achieve “chain-unlocking” and was only genuinely curious because AFAIK calamares doesn’t set this up for you.
3 Likes
Seeing as your system won’t boot without a password you could set up autologin to your desktop environment. That is, if you’re the only user on that system of course.
You will still be asked for your user password after wake up from suspend etc.
I am not & was not riled, i was surprised/puzzled, that’s all. It’s all good.
Ta i appreciate this coz i know i documented all that i did but finding it would have taken a little time, so that’s cool now knowing it’s not necessary.
Ditto here. The advice i was given & applied, was entirely terminal based work, after the event. Whilst i had found guidance [Arch Wiki] on this prior to receiving the forum help, i was fully floundering with its unfamiliar concepts & jargon … so the kind advice i picked up in that forum was like gold to me.
Ahhhh, this:
Just in case you assumed the “someone else” was some snarky dig at you, let me hasten to say that it was actually the Calamares / Ruby / Ubiquity et al designers i had in mind here, not you or anyone else in this thread.
2 Likes
I don’t have an issue with it. I’m just saying i wouldn’t want more than one password for the whole drive. 2 is enough and i probably wouldn’t do auto login.
1 Like
Thank you for this, I will be checking out the verbose version and go ahead from there. It is really well documented!
1 Like