From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thorsten Wilms Subject: Custom kernel module woes Date: Wed, 21 Mar 2018 11:48:42 +0100 Message-ID: <770cd26b-86dd-0e04-5079-532801f228b8@freenet.de> Reply-To: t_w_@freenet.de Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:35757) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eybKZ-0007XA-8s for help-guix@gnu.org; Wed, 21 Mar 2018 06:50:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eybKV-00015i-B2 for help-guix@gnu.org; Wed, 21 Mar 2018 06:50:55 -0400 Received: from mout0.freenet.de ([2001:748:100:40::2:2]:47596) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eybKV-000152-5J for help-guix@gnu.org; Wed, 21 Mar 2018 06:50:51 -0400 Received: from [195.4.92.140] (helo=mjail0.freenet.de) by mout0.freenet.de with esmtpa (ID t_w_@freenet.de) (port 25) (Exim 4.90_1 #2) id 1eybKR-0002xu-5H for help-guix@gnu.org; Wed, 21 Mar 2018 11:50:47 +0100 Received: from [::1] (port=57252 helo=mjail0.freenet.de) by mjail0.freenet.de with esmtpa (ID t_w_@freenet.de) (Exim 4.90_1 #2) id 1eybKQ-0005WA-Rn for help-guix@gnu.org; Wed, 21 Mar 2018 11:50:47 +0100 Received: from mx9.freenet.de ([195.4.92.19]:40854) by mjail0.freenet.de with esmtpa (ID t_w_@freenet.de) (Exim 4.90_1 #2) id 1eybIR-0002LF-DQ for help-guix@gnu.org; Wed, 21 Mar 2018 11:48:43 +0100 Received: from p200300e4f3d1330002e029fffe32e625.dip0.t-ipconnect.de ([2003:e4:f3d1:3300:2e0:29ff:fe32:e625]:40280) by mx9.freenet.de with esmtpsa (ID t_w_@freenet.de) (TLSv1.2:ECDHE-RSA-CHACHA20-POLY1305:256) (port 465) (Exim 4.90_1 #2) id 1eybIR-0006fk-2h for help-guix@gnu.org; Wed, 21 Mar 2018 11:48:43 +0100 Content-Language: en-GB List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: "Help-Guix" To: help-guix Hi! My mentionable reasons for a custom kernel are optimizations for audio work (CONFIG_HZ=1000 and "Preemptible Kernel (Low-Latency Desktop)"), the specific CPU and reducing time and energy costs of building by selecting only the necessary drivers. I added the package definition to my system configuration to then have the kernel build and put into place via `guix system reconfigure /ect/config.scm`. This failed several times after building, when guix does what I understand to be an initramfs test run, where it tries to load a bunch of modules. With the help of #guix, I found a list that appears in linux-modules-builder and init-builder: ("ahci" "usb-storage" "uas" "usbhid" "hid-generic" "hid-apple" "dm-crypt" "xts" "serpent_generic" "wp512" "nls_iso8859-1" "pata_acpi" "pata_atiixp" "isci" "virtio_pci" "virtio_balloon" "virtio_blk" "virtio_net" "virtio_console") Aside of the issue of requiring hid-apple on a desktop PC, and lots of crypto where no encrypted partition is in sight, it would be nice if an error could be triggered before the entire kernel and drivers are build. My notes from hunting down these configuration dependencies: ahci dm-crypt, depends on: Multiple device driver support: Device mapper support: Crypt target support Cryptographic API: User-space interface for hash algorithms User-space interface for symmetric key cipher algorithms RIPEMD-160 digest algorithm SHA384 and SHA512 digest algorithms wp512 / Whirlpool digest algorithms LRW support serpent_generic / Serpent cipher algorithm Twofish cipher algorithm Device Drivers: Block Devices: Loopback device support File systems: FUSE (Filesystem in Userspace) support hid-generic hid-apple isci nls_iso8859-1 pata_acpi pata_atiixp uas, CONFIG_USB_UAS in Device Drivers, USB, USB Attached SCSI. usb-storage usbhid virtio_pci virtio_balloon virtio_blk virtio_net virtio_console xts Things were going well until I got to XTS support. With either my custom configuration, or a default one, XTS is stuck on -*-, i.e. mandatory built-in. The after-build phase will fail if there's no xts.ko module! I tried to figure out the dependencies and failed. Finally, I took the guix kernel configuration, replaced the entire segment device-drivers up to file-systems with one from my custom version and did the few other changes. It works! Now if anyone knows or can figure out how *exactly* to turn XTS's -*- into a {M}, that would still be good to know. A script that turns any kernel configuration into a guix-sd-safe one, or changes to make these gymnastics unnecessary would be great! A drawback of a lean and specific kernel is of course that it won't work with drastically changed hardware. A situation once can suddenly be forced into on hardware failure. Kernel variants are tied to system generations, right? What do I have to do if I want a choice between 2 kernels independent of generations? -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/