* Custom kernel module woes
@ 2018-03-21 10:48 Thorsten Wilms
2018-03-22 17:51 ` Marius Bakke
2018-04-08 20:47 ` Marius Bakke
0 siblings, 2 replies; 4+ messages in thread
From: Thorsten Wilms @ 2018-03-21 10:48 UTC (permalink / raw)
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/
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Custom kernel module woes
2018-03-21 10:48 Custom kernel module woes Thorsten Wilms
@ 2018-03-22 17:51 ` Marius Bakke
2018-03-22 19:22 ` Thorsten Wilms
2018-04-08 20:47 ` Marius Bakke
1 sibling, 1 reply; 4+ messages in thread
From: Marius Bakke @ 2018-03-22 17:51 UTC (permalink / raw)
To: t_w_, help-guix
[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]
Thorsten Wilms <t_w_@freenet.de> writes:
> 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!
Can you post the .config that requires CONFIG_CRYPTO_XTS=y?
I remember having to turn on "expert" configuration in order to change
some of the default builtins. If this is the case, perhaps we should
make it a built-in on GuixSD too.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Custom kernel module woes
2018-03-22 17:51 ` Marius Bakke
@ 2018-03-22 19:22 ` Thorsten Wilms
0 siblings, 0 replies; 4+ messages in thread
From: Thorsten Wilms @ 2018-03-22 19:22 UTC (permalink / raw)
To: help-guix
[-- Attachment #1: Type: text/plain, Size: 580 bytes --]
On 22.03.2018 18:51, Marius Bakke wrote:
> Can you post the .config that requires CONFIG_CRYPTO_XTS=y?
I attached the result of `make menuconfig` in linux-libre-4.15.12, as
that shows the issue and is as neutral as it gets.
> I remember having to turn on "expert" configuration in order to change
> some of the default builtins. If this is the case, perhaps we should
> make it a built-in on GuixSD too.
It already has CONFIG_EXPERT=y, as interesting as that might seem as a
default.
--
Thorsten Wilms
thorwil's design for free software:
http://thorwil.wordpress.com/
[-- Attachment #2: config.bz2 --]
[-- Type: application/x-bzip, Size: 27646 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Custom kernel module woes
2018-03-21 10:48 Custom kernel module woes Thorsten Wilms
2018-03-22 17:51 ` Marius Bakke
@ 2018-04-08 20:47 ` Marius Bakke
1 sibling, 0 replies; 4+ messages in thread
From: Marius Bakke @ 2018-04-08 20:47 UTC (permalink / raw)
To: t_w_, help-guix
[-- Attachment #1: Type: text/plain, Size: 532 bytes --]
Thorsten Wilms <t_w_@freenet.de> writes:
> 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!
I recently revamped my kernel configuration and hit this issue too. In
my case I had to disable ext4 encryption to build xts.ko as a module.
Perhaps we should build ext4 as a module in Guix? Or make XTS a builtin?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2018-04-08 20:48 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-03-21 10:48 Custom kernel module woes Thorsten Wilms
2018-03-22 17:51 ` Marius Bakke
2018-03-22 19:22 ` Thorsten Wilms
2018-04-08 20:47 ` Marius Bakke
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).