/etc/openswap.conf.pacnew

Support System Updates
, ,
1

During update, I got notified that /etc/openswap.conf.pacnew exists now. Without the empty lines and comments and with UUIDs censored, the diff looks like this:

< swap_device=/dev/disk/by-uuid/cb4b194c-d…-4…-8…-2…4…9…
< crypt_swap_name=luks-cb4b194c-d…-4…-8…-2…4…9…
> swap_device=/dev/disk/by-uuid/2788eb78-0…-4…-9…-e…c…7…
> crypt_swap_name=cryptswap
< keyfile_device=/dev/mapper/luks-5f8bee24-4…-4…-a…-7…5…7…
< keyfile_filename=crypto_keyfile.bin
> unlock_method="password"
> keyfile_device=
> keyfile_filename=
> keyfile_block_number=
> keyfile_length=4096
> keyfile_device_mount_options="--options=ro,noload"

The swap device name is completely different, so that seems wrong. But the other changes look like they might be intended. Do I need to apply those changes? Is this just an example file that for some reason got released publicly or should I actually care about some of this? I have not tried rebooting yet since the update, I’ll do that a few minutes after making this post. My main partition and swap are encrypted and I enter a password at the beginning of the boot process. I’ve set that up with the regular Manjaro installer when installing the system.

I also got the warning “you are using potentially dangerous unlock_method keyfile” during the update, followed by links that talk about hibernation. I never voluntarily use hibernation or standby, since things always break with it anyway (and have been on all operating systems I’ve used so far, so I’ve given up on it), so if that issue only breaks hibernation, I don’t care.

2

Do not replace your file - but merge the new content while preserving your changes.

I don’t know the background for the changes but they must be important.

New options as been added and they are commented in detail in the new configuration file.

The openswap is used when your system is encrypted and configured for hibernation.

I have not had the time to dig into the details - the from the comments I read that using a keyfile may introduce dataloss - I am guessing the dataloss could be in conjunction with btrfs or Nvidia but it is a guess.

Ensure your swap partition can be unlocked using your encyption phrase.

I suggest you read the comments and the link to the Arch Wiki - then act accordingly.

Swap suspend — The Linux Kernel documentation
dm-crypt/Swap encryption - ArchWiki

 $ cat /etc/openswap.conf
## cryptsetup open $swap_device $crypt_swap_name
## get uuid using e.g. lsblk -f
swap_device=/dev/disk/by-uuid/2788eb78-074d-4424-9f1d-ebffc9c37262
crypt_swap_name=cryptswap

## unlock_method can be either password, keyfile or keyfile_raw
## keyfile will use the keyfile_device and keyfile_filename to unlock the swap
## keyfile_raw will use the keyfile_device and keyfile_block_number to unlock the swap
## password will prompt for the password to unlock the swap
## if unlock_method is not set, then method is keyfile if keyfile_device and keyfile_filename are set
## otherwise it is password
unlock_method="password"
####### WARNING: There is a risk of data loss when using unlock_method="keyfile"
## You should double-check keyfile_device_mount_options,
## and note that this method is potentially dangerous regardless.
## https://docs.kernel.org/power/swsusp.html
## https://wiki.archlinux.org/title/Dm-crypt/Swap_encryption#busybox-based_initramfs


## keyfile_device is the device that contains the keyfile
## set it to the device that contains the keyfile
## e.g. /dev/mapper/root-device
####### THIS OPTION IS MANDATORY IF unlock_method IS keyfile OR keyfile_raw
keyfile_device=

## keyfile_filename is the path to the keyfile on the keyfile_device
## e.g. /etc/swap.key
####### THIS OPTION IS MANDATORY IF unlock_method IS keyfile
keyfile_filename=

## keyfile_block_number is the block number of the keyfile on the keyfile_device
## e.g. 12345
## on the ext4 filesystem, you can get the block number using
## debugfs $keyfile_device
## extents $keyfile_filename
## the relevant block number will appear under the Physical column in the output
####### THIS OPTION IS MANDATORY IF unlock_method IS keyfile_raw
keyfile_block_number=

## key_size is the size of the key in bytes
## e.g., 4096
## This is the size of the keyfile and should match the actual size of the keyfile.
## You can get the size of the keyfile using: wc -c <keyfile_filename>
## The openswap script will fail if the keyfile is fragmented,
## so keyfile_length should not exceed the filesystem block size.
## For ext4 filesystems, keyfile_length should not exceed 4096 bytes,
## and it SHOULD be greater than ~200 bytes to avoid inode inlining.
####### THIS OPTION IS MANDATORY IF unlock_method IS keyfile_raw
keyfile_length=4096

## additional arguments are given to mount for keyfile_device
## has to start with --options
## it is important to use the correct options for your filesystem
## to prevent any writes to the keyfile device and thus
## minimize the risk of data loss
#keyfile_device_mount_options="--options=subvol=__active/__"
keyfile_device_mount_options="--options=ro,noload"

## additional arguments are given to cryptsetup
## --allow-discards options is desired in case swap is on SSD partition
cryptsetup_options="--type luks"
3

The file that you have right now is the one that works -
it was created specifically for your system.

The new one only contains default values - and possibly some new options.
It cannot and will not work with your system.

Do not just replace the old with the new!

You definitely need to keep what is tailored to your system
and incorporate possibly new options.

And:
there is really no point in censoring UUIDs …

Your keyfile (it’s contents) can unlock the encryption of your swap or possibly even the whole encrypted volume.

That’s what the warning is about.

Someone with the key file might be able to invalidate your encryption of the whole system …

4

I rebooted since then, everything still seems to work fine. 776kB of swap is currently used (seems pointless, but at least that makes it easy to check that it still works) and the NVidia GPU also still works. I do not use an external device to unlock, I type the password manually every time. So everything is fine, I guess?

5

If the new options are about hibernation, I don’t care. So then I can just delete the pacnew file, right?
The keyfile (/crypto_keyfile.bin) only works with the password, right? Would be pointless otherwise, since it’s on the same hard drive.

6

They are not just about that, though.

I hesitate to say: yes
So: I’ll say no - although you’ll probably be o.k

Just incorporate what is new, what was not there before … - and be done with it :grimacing:
(or incorporate your current settings into the new default -
which is effectively the same thing)

like with every .pacnew
… what is it that you are changing?

No.
More precisely:
I do not know that.
You are the only one who can test that.

A key file is intended to unlock some encrypted device without a password -
instead of having to type a password …

But the key file itself should only be accessible after decryption of the volume it resides on.
… the unlocking of which should require a password of some sort

The key file is a potential key to the kingdom -
just like your password -
be very sure and aware
about that you
know
which locks it can (and will) open.

Example scenario:

Boot some distro from USB
Can you see anything but an encrypted device?
Can you see that key file?

Can you unlock the encrypted device by supplying the key file instead of your password?

…
It get’s really complex really quick when it gets to effective encryption.

… it depends on what or whom you are worried about …

.pacnew files are and can only be:
new default options

Not incorporating them might bite you in the future.

… definitely keep what you have got now …

It comes down to:
WHO needs to have WHAT information to break/invalidate your encryption

… in the ultimate end:
it’s just a rubber hose / a whip of sorts …

7

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.