You are not logged in.
Pages: 1
I am planning to drop my Windows and stay only with Arch and dedicate myself more seriously to learn Linux. I believe I could move and resize my ext4 to get the space I will free with Windows, but I would like to try to user btrfs and maybe encrypt it for the sake of science.
For the encryption I plan on use the command like this:
cryptsetup --cipher aes-xts-plain64 --hash sha512 --use-random --type luks2 --verify-passphrase luksFormat /dev/sdx
cryptsetup luksOpen /dev/sdx mappername
I have a few questions about the encryption:
1) is that command alright, is there any other good options I should turn on/change in there?
2) If I forget the passphrase/key, the data is as good as gone, right?
3) Is there a way to make it auto decrypt? (reading the passphrase/key from somewhere and still be safe, is there any options here?
(I know I would have to put btrfs on modules, and encrypt before filesystems in mkinitcpio and so on)
On the partition scheme I plan to format with
mkfs.btrfs --checksum xxhash /dev/mapper/mappername
It seems XXHASH is almost as fast as the default checksum, but prevents the data corruption far more. Does anyone use it? Any other worth options when formating?
Now the partition scheme:
@
@home
@etc
@games
@.snapshot
@swap
Well, having a separete home I already have the experience it is awesome and if we reinstall Arch it gets all the configuration as we left them. I feel like doing the same with ETC, but I tried it once with ext4 and I couldnt make it stay on a separate partition and load properly, might be because the FSTAB is within it, is there any workaround here to have something like this work? I can redo this each reinstall anyway.
Games is about leaving steam stuff and lutris there.
1) Is there any better partition scheme?
2) Is there any better way to do it if we think about snapshots? (some stuff that would be good to snapshot and those that shouldnt, and thus should be in a subvol of its own)
3) restoring snapshot might break the system, is there any folders or files I should make sure to snapshot together so I dont break the system when restoring?
4) any other advices?
5) Is there any benefit to do a subvol for each folder in / ? (except lib, lib64, bin and sbin that are symlinks) (Is tmp any special folder, it "shines" differently in fish terminal)
6) I plan to mount the subvols with mount /dev/mapper/mappername / -o noatime,space_cache=v2,compress=zstd:3,ssd,discard=async,subvol=@ - any other options I should use?
Bonus question: is there a way to use only one wine prefix in steam? I guess I can 'lose' 500mb for each game haha.
Last edited by Soultrigger (2023-09-06 11:38:11)
Offline
Encrypting your install is always useful regardless of the reason.
is that command alright, is there any other good options I should turn on/change in there?
That command looks fine and should produce a working luks volume but if I remember correctly it is the exact same as the defaults.
If I forget the passphrase/key, the data is as good as gone, right?
Yes if you forget all passphrases/keys you are permanently locked out of your system.
Is there a way to make it auto decrypt? (reading the passphrase/key from somewhere and still be safe, is there any options here?
You can create a keyfile as described in Device_encryption#Keyfiles, store it on -for example- a removable drive and use it to automatically unlock the encrypted volume at boot. For that you must pass a kernel parameter as described in System_configuration#cryptkey. It will still prompt you for a passphrase if the key can't be found for whatever reason.
Is there any better partition scheme?
For your partition layout I recommend putting at least /var/cache and /var/log onto separate subvolumes so they are not deleted/copied when creating/restoring snapshots. I also wouldn't put /etc onto a separate subvolume because it contains the fstab and afaik without that your system won't be able to find out what other subvolumes/partitions to mount.
restoring snapshot might break the system, is there any folders or files I should make sure to snapshot together so I dont break the system when restoring?
Thats why you should have one subvolume for the entire root (excluding things that you dont want to or shouldn't roll back such as /var/cache and log as well as your home folder)
5. The only benefit would be being able to snapshot and rollback each folder separately, but if you have to roll back chances are your system is borked in more than one place. It's imo better to just make subvolumes to exclude what you don't want to snapshot.
I plan to mount the subvols with mount /dev/mapper/mappername / -o noatime,space_cache=v2,compress=zstd:3,ssd,discard=async,subvol=@ - any other options I should use?
These options look fine most of them are the default anyway. noatime can improve performance under read intensive work-loads. The compression is up to you I guess. Consider following the recommendations at Security
Bonus question: is there a way to use only one wine prefix in steam? I guess I can 'lose' 500mb for each game haha.
I don't really play video games, but I don't see a technical reason why you couldn't just symlink all the prefixes to a single location. At the same time each game probably has some unique configurations that might be broken by that. I don't think that is a good idea.
Offline
cryptsetup --cipher aes-xts-plain64 --hash sha512 --use-random --type luks2 --verify-passphrase luksFormat /dev/sdxis that command alright, is there any other good options I should turn on/change in there?
That command looks fine and should produce a working luks volume but if I remember correctly it is the exact same as the defaults.
$ cryptsetup --help
....
Default compiled-in device cipher parameters:
loop-AES: aes, Key 256 bits
plain: aes-cbc-essiv:sha256, Key: 256 bits, Password hashing: ripemd160
LUKS: aes-xts-plain64, Key: 256 bits, LUKS header hashing: sha256, RNG: /dev/urandom
LUKS: Default keysize with XTS mode (two internal keys) will be doubled.sha512 replaces the default of sha256 in both cases the key size will be 512. /dev/random replaces /dev/urandom which use the same pool since 5.6 with the difference being /dev/random will block until it has been initialized.
Offline
Thanks for your answers, they were awesome and elightening since to think subvol as what you dont want to snapshot and I thought it was the other way around. I will also research what you linked. I did read some stuff on ecryption and it seems to be a rabbit hole, so many options, so many validations and implications. It will be fun.
Is there any better partition scheme?
For your partition layout I recommend putting at least /var/cache and /var/log onto separate subvolumes so they are not deleted/copied when creating/restoring snapshots. I also wouldn't put /etc onto a separate subvolume because it contains the fstab and afaik without that your system won't be able to find out what other subvolumes/partitions to mount.
About this I run a quick test on a VM and I put /etc on @etc. I pacstraped the packages, genfstab, arch-chroot and so on to make the base install and be able to reboot. After I was done I copied the fstab to / and then umount /etc, after that I copied the fstab to /etc (that is now a clean directory unmounted), after rebooting it turns out the system reads the fstab in /etc and mounts @etc on top of it, replacing the clean directory with just fstab with the full configuration files in @etc.
I didnt install a DE or something that would let me test further, but I will do so soon. The only negatives I see is to have to umount etc to update the fstab in the "clean" etc whenever I change the fstab.
Before this VM, I did try to make one with encryption, but It seems I failed. Do you know if Qemu/KVM supports encryption so I can further test?
It is awesome to reinstall arch, there is always something that changes, like I had a hook for bootctl update, but now there is a systemd service for that. Also when I first installed or there was no way to secure boot or just the manual ultra hard genius way, but now we got sbctl and it is so easy.
I like to research from time to time and see how noob I am haha
Offline
cryptsetup --cipher aes-xts-plain64 --hash sha512 --use-random --type luks2 --verify-passphrase luksFormat /dev/sdxScarletFire wrote:is that command alright, is there any other good options I should turn on/change in there?
That command looks fine and should produce a working luks volume but if I remember correctly it is the exact same as the defaults.
$ cryptsetup --help .... Default compiled-in device cipher parameters: loop-AES: aes, Key 256 bits plain: aes-cbc-essiv:sha256, Key: 256 bits, Password hashing: ripemd160 LUKS: aes-xts-plain64, Key: 256 bits, LUKS header hashing: sha256, RNG: /dev/urandom LUKS: Default keysize with XTS mode (two internal keys) will be doubled.sha512 replaces the default of sha256 in both cases the key size will be 512. /dev/random replaces /dev/urandom which use the same pool since 5.6 with the difference being /dev/random will block until it has been initialized.
I did understand what you said, but it didnt seem like you expressed what you think is better... Should I change anything?
Offline
I am marking this as solved, since it pointed me in the right direction and I am satisfied with the help.
The "mounted etc" that I described before, while it will allow to load the system with a mounted etc when the system shutdowns it umount the etc before it updates some files in /etc which will make the system try to update such files forever. So since I dont know how to make /etc dismount as the last thing in shutdown (which I think is possible), the mounted etc project is scrapped. Just so I dont leave bad advice on this forum.
Before I leave, I changed the open command from the original post to:
cryptsetup --allow-discards --perf-no_read_workqueue --perf-no_write_workqueue --persistent luksOpen /dev/root main
It just add performance increased options for ssds and make them persistent.
Offline
Pages: 1