fix typo

[linuxandos2]

sync resume with main

[desultory]

Thanks for this, I think I was able to rebase it to do about the same thing. Please let me know if I missed anything. I may go through it and "upgrade" some of the functions to use larger strings, instead of lists where possible as well

[desultory]

the formatting should be a bit easier to work with now, I'm hoping this didn't break anything too much. I've just noticed some other changes which make config parsing stricter break the loading of the resume module. I'll look into a fix for that.

[desultory]

should be fixed now, please let me know if I broke something in this rebase.

edit: found some broken quotes, should work now.

[linuxandos2]

Tested:
Generation more strtict about parameters. = good
on system with root and swap encripted:
Boot OK.
hibernation OK
Resume OK

[linuxandos2]

Used this config:

# This config will decrypt the LUKS volume with uuid "fdf442da-0574-4531-98c7-55227a041f1d", mapping it to "/dev/mapper/root"
# It will attempt to mount the btrfs volume with label "rootfs" to /target_rootfs
# It will pull all current kernel modules from lspci -k results
# It will try to process the cmdline and mount the rootfs based on the root= parameter
modules = [
"ugrd.crypto.cryptsetup", # This is included by the gpg module
#"ugrd.base.debug",
"ugrd.fs.resume" ,
"ugrd.fs.mdraid" ,
"ugrd.base.keymap",
]

binaries = ['cat', 'dd', 'lsmod', 'udevadm', 'mdadm', 'cp', 'killall', 'ls', 'mkdir', 'mknod', 'mount', 'umount', 'sed', 'sleep', 'ln', 'rm', 'uname', 'readlink', 'basename', 'modprobe', 'readlink', 'basename', 'mdmon', 'udevd', 'cryptsetup', 'loadkeys']

kmod_autodetect_lspci = true
test_swap_uuid = true
kmod_init = ["usbhid", "hid_logitech_hidpp", "hid_logitech_dj", "hid_generic", "raid0", "raid1", "raid10", "raid456"]

keymap_file = "/usr/share/keymaps/i386/azerty/be-latin1.map.gz"
dependencies = [ "/etc/cryptsetup-keys.d/gentoo.key" ]
#cryptsetup_key_file = "/etc/cryptsetup-keys.d/gentoo.key"
# If the root is a LUKS volume, specify the LUKS volume information
[cryptsetup.root]
# The UUID of the encrypted volume, mounted at /dev/mapper/root
#uuid = "2152888b-67cb-4339-a2f4-680bf955c46b"
key_file = "/etc/cryptsetup-keys.d/gentoo.key"

# If the swap is a LUKS volume, specify the LUKS volume information
[cryptsetup.swap]
# The UUID of the encrypted volume, mounted at /dev/mapper/swap
uuid = "86f67200-c891-47d3-bdd4-f8e58322325d"
key_file = "/etc/cryptsetup-keys.d/gentoo.key"

What do you think about this:

Foresee an parameter: cryptsetup_key_file that woud be the default for: key_file
Where key_file takes precedence over cryptsetup_key_file if both are specified.
Also copy the file so that the dependencies is not necessary?

Autodetect the UUID of other encrypted partitions.

Also is [cryptsetup.xxx] necessary?
Autodetect all encrypted partitions.
AutoInclude "ugrd.crypto.cryptsetup"

[desultory]

Used this config:

# This config will decrypt the LUKS volume with uuid "fdf442da-0574-4531-98c7-55227a041f1d", mapping it to "/dev/mapper/root"
# It will attempt to mount the btrfs volume with label "rootfs" to /target_rootfs
# It will pull all current kernel modules from lspci -k results
# It will try to process the cmdline and mount the rootfs based on the root= parameter
modules = [
"ugrd.crypto.cryptsetup", # This is included by the gpg module
#"ugrd.base.debug",
"ugrd.fs.resume" ,
"ugrd.fs.mdraid" ,
"ugrd.base.keymap",
]

binaries = ['cat', 'dd', 'lsmod', 'udevadm', 'mdadm', 'cp', 'killall', 'ls', 'mkdir', 'mknod', 'mount', 'umount', 'sed', 'sleep', 'ln', 'rm', 'uname', 'readlink', 'basename', 'modprobe', 'readlink', 'basename', 'mdmon', 'udevd', 'cryptsetup', 'loadkeys']

kmod_autodetect_lspci = true
test_swap_uuid = true
kmod_init = ["usbhid", "hid_logitech_hidpp", "hid_logitech_dj", "hid_generic", "raid0", "raid1", "raid10", "raid456"]

keymap_file = "/usr/share/keymaps/i386/azerty/be-latin1.map.gz"
dependencies = [ "/etc/cryptsetup-keys.d/gentoo.key" ]
#cryptsetup_key_file = "/etc/cryptsetup-keys.d/gentoo.key"
# If the root is a LUKS volume, specify the LUKS volume information
[cryptsetup.root]
# The UUID of the encrypted volume, mounted at /dev/mapper/root
#uuid = "2152888b-67cb-4339-a2f4-680bf955c46b"
key_file = "/etc/cryptsetup-keys.d/gentoo.key"

# If the swap is a LUKS volume, specify the LUKS volume information
[cryptsetup.swap]
# The UUID of the encrypted volume, mounted at /dev/mapper/swap
uuid = "86f67200-c891-47d3-bdd4-f8e58322325d"
key_file = "/etc/cryptsetup-keys.d/gentoo.key"

What do you think about this:

Foresee an parameter: cryptsetup_key_file that woud be the default for: key_file Where key_file takes precedence over cryptsetup_key_file if both are specified. Also copy the file so that the dependencies is not necessary?

Autodetect the UUID of other encrypted partitions.

Also is [cryptsetup.xxx] necessary? Autodetect all encrypted partitions. AutoInclude "ugrd.crypto.cryptsetup"

Thanks for testing that stuff :D

There is already an option to include the key file into the image, if include_key = true is set under that section.

I can see some value in setting a default key to be used for any mounts, but I think in most cases it's probably a best practice to use a unique key per LUKS container.

[cryptsetup.xxx] is only necessary if you're specifying a mount which is not autodetected, or needs additional config, such as header/key files.

I updated the example a fair bit to hopefully better explain how this stuff works:
09a13f3

[linuxandos2]

Thanks for testing that stuff :D

You'r welcome.
About [cryptsetup.xxx]: for swap the UUID is needed. Could swap be autodetected? During tracing the genetration, at a certain moment the UUID is present, but I do'nt find where in the code. So auto should be possible?

Also tested on system without luks. ==> OK

[desultory]

Thanks for testing that stuff :D

You'r welcome. About [cryptsetup.xxx]: for swap the UUID is needed. Could swap be autodetected? During tracing the genetration, at a certain moment the UUID is present, but I do'nt find where in the code. So auto should be possible?

Also tested on system without luks. ==> OK

Thanks for the thorough testing :D

Yes, it would be possible to detect that info, just a little bit tricky.

I think a lot of the current code could be reused, but a lot of it operates off of mountpoints, like from /proc/mounts, as the place to start looking for info. This doesn't make it impossible to detect, it's just a bit different from current detection methods.

Ideally, it should also do something like check for hibernation support before enabling the resume module, and then once the resume module is enabled, that can check for things like swap devices. There is also the case that a user may enable the resume module because they want to add swap/hibernate later, but it's not setup yet.

[desultory]

c005a0d
I reviewed it a bit more and think this should help some, not sure how late resume was working without this? The old commit was using some init levels which were "condensed" since import ordering is not supported.

(a lot of the trouble is that this is a big pr and was done before/during a somewhat substantial project overhaul)

[desultory]

I've double checked and this patch works flawlessly on my old test VM for resumes which has not been updated in a very long time, so I'm feeling pretty confident in these changes being good. I'll have to make a new vm with swap under lvm under luks or similar to test the more advanced stuff, but I'm happy this has not broken the most basic setups.

[desultory]

I'm closing this as I think all relevant changes were integrated into the current resume branch. Current work is being done here:

#290

The important bit is that testing is added for these changes, covering a basic resume case, and an encrypted resume case.

thanks for the help and fixes added here!