For people using genkernel to create LUKS-enabled initramfs’es, genkernel produces images that don’t contain a sane possibility to supply additional parameters to the 'cryptsetup' call that mounts the root FS in the script /etc/initrd.scripts. More specifically, it’s about $cryptsetup_options in openLUKS(). Background: Beginning with Linux 3.1 and cryptsetup 1.4.0, the 'allow_discards' option is now supported to pass discard commands from the FS to drives that support it (i.e. TRIM on SSDs). To enable this feature, you have to supply the --allow-discards option to cryptsetup because it won’t be enabled by default anytime soon (see http://asalor.blogspot.com/2011/08/trim-dm-crypt-problems.html for more information about the implications of this). So to enable this feature during boot within a genkernel-made initramfs, you currently have to edit /usr/share/genkernel/defaults/initrd.scripts appropriately (the cryptsetup call happens there) and (re-)create the initramfs. Just checked out the most recent version of genkernel, 3.4.19: the bug applies to that version as well. Reproducible: Always Steps to Reproduce: (see above) Actual Results: (see above) Expected Results: Being able to provide additional parameters to cryptsetup could be achieved by introducing a new kernel/initramfs option, e.g. 'crypt_flags' or something like that. Maybe it’s even desireable to create an option in genkernel.conf called LUKS_ALLOW_DISCARDS (or similarly) that takes care of inserting the option. Here is the diff for initrd.scripts that enables TRIM support for the root LUKS device: 762c762 < local mntkey="/mnt/key/" cryptsetup_options='' --- > local mntkey="/mnt/key/" cryptsetup_options='--allow-discards '
Interesting. This should become a boot parameter of some kind I guess. If we add a new one for this, it would be good to pick a way that Dracut upstream likes, too. I expect them to have that problem too and a synced approach would help minimize the differences between genkernel and Dracut. Amadeusz, what do you think?
PS: Maybe parameter "allow_discards" can be re-used? Would that work or confuse the kernel?
Created attachment 297933 [details, diff] enable support for --allow-discards in genkernel init scripts I created a patch to support TRIM properly in genkernel. Basically I added a kernel option „root_trim“ (similar to root_key and root_key_dev) which has to be yes to enable trim. See attached patch.
Hello Christian, any comments on allow_discards (comment #2) ? Could you update the man page at doc/genkernel.8.txt, too?
Created attachment 297939 [details, diff] enable support for --allow-discards in genkernel init scripts, added documentation for root_trim Hi, I added some documentation. I don't like the idea of allow_discards: it is not really extensible and you can't specify a specific device. Also it doesn't match the style of the rest of the crypto options.
(In reply to comment #5) > I added some documentation. Thanks. > I don't like the idea of allow_discards: it is not really extensible and you > can't specify a specific device. It looks like this applies to the proposal of root_trim, too. Am I missing something?
Hey, (In reply to comment #6) > > I don't like the idea of allow_discards: it is not really extensible and you > > can't specify a specific device. > > It looks like this applies to the proposal of root_trim, too. Am I missing > something? There can be root_trim=yes, data_trim=yes, some_weird_trim=yes but only one allow_trim. That's how I understood the crypt submodule options.
(In reply to comment #6) > > I don't like the idea of allow_discards: it is not really extensible and you > > can't specify a specific device. > > It looks like this applies to the proposal of root_trim, too. Am I missing > something? Of course what also would be extensible is allow_discards=root,data,some_weird. That's an approach I would like :-) Greetings, CK
The patch you upload just turned out malformed on application: # patch -p 1 < ~/Desktop/genkernel.patch patching file defaults/initrd.scripts patch: **** malformed patch at line 16: @@ -793,6 +794,12 @@ I think I was able to restore it. Please verify that [1] changes what you intended to change so I can make a new release. [1] http://git.overlays.gentoo.org/gitweb/?p=proj/genkernel.git;a=commitdiff;h=c92fe6f0e654d49f00465e81f8f491ef9240fb80
(In reply to comment #9) > The patch you upload just turned out malformed on application: I'm sorry, I deleted a newline and didn't re-check it. > I think I was able to restore it. Please verify that [1] changes what you > intended to change so I can make a new release. Confirmed. Greetings, CK
(In reply to comment #10) > (In reply to comment #9) > > The patch you upload just turned out malformed on application: > > I'm sorry, I deleted a newline and didn't re-check it. No problem. I just wanted you to know. > > > I think I was able to restore it. Please verify that [1] changes what you > > intended to change so I can make a new release. > > Confirmed. Great. genkernel 3.4.21.1 has just been released. Closing.
