Bug#774647: [pkg-cryptsetup-devel] Bug#774647: cryptsetup on initramfs does not support key files (resume swap on LVM)

2016-09-15 Thread Guilhem Moulin
Control: unmerge -1 Control: tag -1 - patch Control: retitle -1 can't a use key file stored on an encrypted rootfs to unlock the resume device at initramfs stage Control: severity -1 wishlist Control: tag 776409 pending I just added support for unlocking devices at initramfs stage using a key fil

Bug#774647: [pkg-cryptsetup-devel] Bug#774647: cryptsetup on initramfs does not support key files (resume swap on LVM)

2015-12-19 Thread Guilhem Moulin
Grmbl, in fact I didn't test it properly: the resume device was mounted by systemd not by the initramfs image. This seems to be due to the current init which requires all node devices to be present before the rootfs is being mounted, as found in initramfs-tools(8): local-top OR nfs-top Af

Bug#774647: [pkg-cryptsetup-devel] Bug#774647: cryptsetup on initramfs does not support key files (resume swap on LVM)

2015-12-19 Thread Guilhem Moulin
Sorry, typo :-P -- Guilhem. From 2d877465f22b608945e2544510f5ac4240508325 Mon Sep 17 00:00:00 2001 From: Guilhem Moulin Date: Sat, 12 Dec 2015 20:04:56 +0100 Subject: [PATCH] Add keyfile support for non-root devices. --- debian/changelog | 3 +++ debian/initramfs/cryptroot-ho

Bug#774647: [pkg-cryptsetup-devel] Bug#774647: cryptsetup on initramfs does not support key files (resume swap on LVM)

2015-12-19 Thread Guilhem Moulin
Hi, On Thu, 17 Dec 2015 at 10:55:06 +0100, Jonas Meurer wrote: > I've some comments and questions regarding your patch though. Have you > tested the patch already? Yes, but only on a resume device (and without LVM). (But I don't see how the same wouldn't work for other devices and/or LVM.) > W

Bug#774647: [pkg-cryptsetup-devel] Bug#774647: cryptsetup on initramfs does not support key files (resume swap on LVM)

2015-12-17 Thread Jonas Meurer
Hi Guilhem, Am 12.12.2015 um 20:38 schrieb Guilhem Moulin: > Here is a simple patch that adds keyfile support for non-root devices. > Ideally we would also warn the user if the key file is stored on an > unencrypted device, but that requires some code refactoring in the hook > file so it'll come i