severity 491867 minor thanks > > So this will run mkswap on the resume device. > AFAIK, this mkswap operation is run by "/etc/init.d/cryptsetup-early" > which in turn is run by "/sbin/init". Thus, this operation is only > during a regular boot. It is not run during resume, since resume does > not actually run init scripts.
With only reading I come to the same conclusion. > In particular, I could find no copy of the crypttab file in the > initrd.img which hands over to the unfrozen system. Still this information has to be somewhere in the initrd, because otherwise the initrd would have no way to know what to decrypt. I guess the file is parsed and stored somewhere in conf/. What gives more evidence is that neither /usr/share/initramfs-tools mentions mkswap nor the initrd contains a copy. > Has this fix actually caused a problem with any system? Actually no, I did not trash my system. I only verified that the swap signature does change and that the luks header is not properly destroyed. I then concluded under the false assumption that cryptsetup behaves consistent. So let me propose changing other things: * First of all it would be great if we could change man crypttab to reflect this behaviour like "Run mkswap on the created device, but not before /sbin/init is run." or "Run mkswap on the created device unless it is used for resuming." * Secondly in README.initramfs.gz according to my understanding step 6 should be useless, because step 4 already formated the device. A imho better approach would be to keep step 6 and never let cryptsetup invoke mkswap by removing that swap option if this change does not break the sequence in another way. I'd also be glad if README.initramfs.gz could be extended with more explanations on why and how this works, because the documentation of cryptsetup often made me read the source. Thanks for investigating this Helmut -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]