Bug#247054: Crypto-root patch updated to initrd-tools 0.1.70
On Tue, Nov 30, 2004 at 09:52:09AM +0100, Loïc Minier wrote:
> Yes, so my conclusion is "either the generated initrd is borken because
> it asks for a password when it isn't needed or because it tries to
> activate swap where it can't".
Ahh. Well, that's true.
> "Wesley W. Terpstra" <terpstra@gkec.tu-darmstadt.de> - Tue, Nov 30, 2004:
> > Furthermore, it is impossible to use swsusp + initrd with the stock kernels
> > (without the obsolete debian patch) because the kernel does not have the
> > opportunity to load the initrd prior to restoring it's state. (not modular)
>
> So you're saying that, when resuming, the kernel never boots the
> initrd, and as such must be able to access the resume partition
> directly, without an initrd setup of swap?
Yes.
The debian patch made swsusp a module which could be loaded after swap was
setup via whatever means were necessary. To the best of my knowledge, the
swsusp restart present in the stock kernel can not be delayed like this.
If I am wrong, I would be happy to be so. I used to use swsusp with crypto,
and when the module got pulled I lost my ability to have quick power on/off.
> > Since I run crpto over LVM over RAID 1, it certainly does work.
>
> Please don't take everything I say as an attack.
I was just being terse; not attacked.
> I see no mention of the LVM volumes or of "RAID 1" in the fstab you
> quotted, the logical question is "where is that configured". Is it
> autoconfigured/autodetected like LVM physical volumes?
The devices listed were /dev/mapper/muffin-* which are LVM block devices.
The 'dmname' parameter just suggests the new encrypted devices' name.
--
Wesley W. Terpstra
Reply to: