This works! However, RAID1 works only if you disable the swapfile as btrfs-RAID1 is not compatible with swapfiles. So instead one creates an encrypted swap partition and adds this line to the /etc/crypttab: cryptswap UUID=${UUIDOFSWAPPARTITION} /dev/urandom swap,offset=1024,cipher=aes-xts-plain64,size=512
and this one to /etc/fstab:
I changed the post above with the steps to set up RAID1 that work for me on Manjaro. If you want to only have one prompt for the pass-phrase you should create an encrypted partition for boot (without RAID1) and a btrfs-raid1 for the root filesystem which are then both unlocked using keyfiles. Either way, works nicely. Hope to have the videos and guide up this week on my homepage.
If you ever have the need, it probably is too late.
Well. if you really insist on not encrypting, the following should work.
Follow steps #01 to #05 but adjust like described below:
#03
Don’t choose ‘Encrypt’.
#05
btrfsonluks=`sudo blkid -o device | grep luks`
automatically assigns the encrypted partition to the variable ‘btrfsonluks’. You won’t have this device, so
you’ll have to set the variable manually to your btrfs partition, e. g. /dev/sda2, like this
btrfsonluks=/dev/sda2
Continue with V-09 V-10
Then you can optionally continue with step #06, beginning with where it says max_snapshots=13
followed by #07 (optional)
Done!
Off-topic: Why one wouldn’t choose to encrypt their data is beyond me; . You won’t notice it performance-wise and you’ll just have to enter a single password once at boot. If a device is lost, stolen or confiscated by law enforcement you can rest assured that your or your companies data is secure as long as you chose a secure password.
By the way, this is for an old cheapo laptop that I plan to use at home only as a media player for my TV, thus it does not have any sensitive data on it. A few days ago, it did not reboot properly after a system update and I had to reinstall EOS, but with your setup, I guess I no longer need to reinstall .
For my other laptop of course I will follow your full HOWTO to make it secure with full encryption.
Thanks!
I’m trying not to get my hopes up too high, however having that said…
99% of everything I just read in this post made complete sense to me, so I think I may actually be learning a thing or two (finally) about how filesystems work, or at least, how btrfs works.
I tried a new install following your excellent guide with the current iso from July, but the resume parameter missed in the resulting grub. There was only the resume_offset parameter.
Thanks for letting me know! I’ll have a look into it.
Sadly, I won’t be able to check the July iso until the end of next week as I’m currently on vacation in Paris and my partner is enforcing a strict “no quick problem solving” regime …
As a quick fix it should suffice to add the following line
sudo sed -i "s#loglevel=3#resume=$btrfsonluks loglevel=3#" /mnt/btrfs/@/etc/default/grub
before or after
sudo sed -i "s/loglevel=3/loglevel=3 resume_offset=$offset/" /mnt/btrfs/@/etc/default/grub
in #05 of the first post, if the resume partition isn’t added automatically anymore.
I’m going to try it the encrypted way, what about other devices in the machine though? I have a data drive that holds my videos and music which I symlink to /home. Should I be using BTRFS for that as well and if so, how would I go about encrypting it as I don’t want to have to enter a password everytime I want to play a song from the drive?
You can unlock additional encrypted devices/partitions automatically during boot. These partitions need to be LUKS (dm-crypt) encrypted and can contain the filesystem of your choice (ext4, btrfs, zfs, …); so they needn’t be btrfs.
Note that you can’t encrypt a device while keeping it’s data. You would have to
backup your existing data partitions files
create/encrypt your data partition
choose a filesystem (e. g. ext4) and format
(re-)copy your backuped files to the encrypted partition
To have the partition automatically unlock during boot you could
create a random key-file stored on your encrypted /root
add this keyfile as a second password to your encrypted data partition
create a mapper in /etc/crypttab that can then be referenced in the fstab
mount the device in fstab (you could mount-bind or try a symlink like before)
This way you would only be asked for your encrypted root devices password once at boot and your data partition would be automatically “chain-unlocked” by the system.
You could still access your encrypted data device manually with the password you chose during creation, if you ever need to (e. g. data device is an external usb-drive and you plug it into another linux system).
If you need help in setting this up, feel free to ask.
@2000
I followed your guide here to try this as i don’t have any experience setting this up. I never bothered with it before as i found it to be just a little too involved. This does make it easy but not saying i understand all the ins and outs of it.
Anyway it shows no device for hibernation. I guess you have to set that up too? If i run hibernation it shuts off and its just a normal start up. I’m only doing this to try to understand it a bit. The encryption takes too long to decrypt on boot i find.
Edit: What is the difference with the verbose mode?
Yes, @csteinforth already noticed this in post #49. The July ISO doesn’t seem to add the resume device automatically anymore.
Quick fix if you haven’t installed yet: see post #50
Quick fix if you already installed EOS following the above guide:
get resume device info sudo blkid -o device | grep luks
( e. g. /dev/mapper/luks-7cb97d17-7dbc-44a1-831f-af49012345d7
add this resume device (resume=) to /etc/default/grub GRUB_CMDLINE_LINUX_DEFAULT="[...] resume=/dev/mapper/luks-7cb97d17-7dbc-44a1-831f-af49012345d7 resume_offset=[...]"
No difference, just a bit more information on what all those commands you copy & paste in the shorter version do.
This is one of the caveats to having an encrypted /boot. At this early in the boot process Grub takes its time to decrypt the root partition to get to the initramfs and kernel. This can’t be sped up AFAIK.
(Sort of) Off-topic question for @moderators:
The initial post being to old for me to edit, what would be the best way to update the guide so that users not reading 50+ posts get a working version? (Once I have the time to figure out what is actually going wrong, that is.)
If an edit isn’t possible a moderator could at least maybe flag the initial post as obsolete/outdated etc. This would be less frustrating for people not reading the whole thread.
No pencil for the initial post. I assume the forum software doesn’t allow editing a post after a certain time. That’s why I was asking how to address this issue.
I assumed the resume-offset was already correctly added to /etc/default/grub.
If not, this wiki entry describes how to get the resume-offset for btrfs.
For reference, here is my /etc/default/grub entry: GRUB_CMDLINE_LINUX_DEFAULT="cryptdevice=UUID=7cb97d99-7dbc-44a1-831f-af49044855d7:luks-7cb97d99-7dbc-44a1-831f-af49044855d7:allow-discards root=/dev/mapper/luks-7cb97d17-7dbc-44a1-831f-af49041234d7 resume=/dev/mapper/luks-7cb97d17-7dbc-44a1-831f-af49041234d7 loglevel=3 resume_offset=2626816 nowatchdog"
Your entry should be something like … GRUB_CMDLINE_LINUX_DEFAULT="quiet cryptdevice=UUID=c2711aa5-335d-45c6-ad4a-613eecc21422:luks-c2711aa5-335d-45c6-ad4a-613eecc21422 root=/dev/mapper/luks-c2711aa5-335d-45c6-ad4a-613eecc21422 resume=/dev/mapper/luks-c2711aa5-335d-45c6-ad4a-613eecc21422 loglevel=3 resume_offset=1840384"
the following should work.
. You won’t notice it performance-wise and you’ll just have to enter a single password once at boot. If a device is lost, stolen or confiscated by law enforcement you can rest assured that your or your companies data is secure as long as you chose a secure password.
.
. Vacation is vacation especially in those strange times.
