From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: Re: Kernel modules in initrd Date: Thu, 22 Feb 2018 17:01:11 -0500 Message-ID: <87eflck7ko.fsf@netris.org> References: <20180222211707.GB9758@jurong> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:39663) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eoyw4-0002dm-UI for guix-devel@gnu.org; Thu, 22 Feb 2018 17:01:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eoyw0-0006Re-2m for guix-devel@gnu.org; Thu, 22 Feb 2018 17:01:53 -0500 Received: from world.peace.net ([50.252.239.5]:47786) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eoyvz-0006Qw-Tb for guix-devel@gnu.org; Thu, 22 Feb 2018 17:01:47 -0500 In-Reply-To: <20180222211707.GB9758@jurong> (Andreas Enge's message of "Thu, 22 Feb 2018 22:17:07 +0100") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Andreas Enge Cc: guix-devel@gnu.org Hi Andreas, Andreas Enge writes: > recently I had an unpleasant experience in installing GuixSD: After booting > with the USB key and following the installation instructions, then rebooting > into the installed system, the "/" file system was not found: neither using > file system labels, nor device nodes. > > The problem turned out to be that the disk of the machine needed special > kernel modules, and adding > (initrd (lambda (file-systems . rest) > (apply base-initrd file-systems > #:extra-modules '("mptbase" "mptsas" "mptscsih") > rest))) > to the operating-system declaration solved the problem. > However, it took us quite some time and several trials to diagnose the > problem in the first place. > > So I wonder: > 1) Could we add more kernel modules to the base-initrd, whenever people > report that new ones are needed? For instance, the berlin server has > modules (list "megaraid_sas" "libsas" "scsi_transport_sas"). We need a better system for dealing with this. I don't think that loading every kernel module that any GuixSD user ever needed during the early boot process is a good approach. To make matters worse, it's easy for a user to add modules to their initrd, but there's no easy way to remove modules from the default set. I don't want *every* GuixSD user to unconditionally load, into their kernels during early boot, code to support LSI MegaRAID SAS cards, just because there exists one GuixSD user out there who needs it. Every extra loaded kernel module means more RAM usage in the kernel, a larger initrd image that must be loaded by possibly slow bootloaders, and code complexity in the running kernel, leading to a greater attack surface for possible security exploits. For example, last year some memory corruption bugs were found in the LSI MegaRAID SAS module. See . To make this easier, I think the right approach is to include many modules like these to our installation image initrd, and then to automatically detect which modules are needed for booting. A future easy installer could automatically add those modules to the OS config, but in the meantime we could simply print a message recommending that the user should add the needed modules to their initrd config. What do you think? Mark