[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#853855: di-utils: Kernel boot options containing a dot are not propagated to the installed system

Ben Hutchings <ben@decadent.org.uk> writes:

> On Sun, 2017-02-12 at 12:26 +0100, Samuel Thibault wrote:
>> Hello,
>> Emmanuel Kasper, on Fri 03 Feb 2017 13:13:32 +0100, wrote:
>> > good catch
>> > 
>> > virt-cat -a testing.build/testing.raw /etc/modprobe.d/local.conf
>> > 
>> > # Local module settings
>> > # Created by the Debian installer
>> > 
>> > options net ifnames=0
>> Ok... So to sum it up, there are options passed on the d-i kernel
>> command line that we should either:
>> - copy verbatim in the command line of the installed grub configuration
>> - set as module parameters
>> and we basically don't have an automatic way of choosing between them.
>> Just wondering: can't we just always do both?  I.e. remove the varnodot
>> check.  Sure that's ugly because then we have both the commandline and
>> the module, but to me it's the least horrifying solution.  And AIUI
>> that'd actually be needed if for instance with a new kernel release a
>> driver gets migrated from compiled-in to loadable module or vice-versa.
> I agree that the current check is incorrect and should be removed.
> It's been possible for a long time to have dotted parameters for built-
> in code, whether or not that code could ever be built as a module.
>> So, does it look too ugly?
> It is ugly that we will still end up writing module parameters for non-
> existent modules.

Well, there are only about ten of these prefixes at present AFAICT:


assuming this page is up to date:


so we could maintain a list of known non-module prefixes to filter the
options by.  As long as we catch the commonly used ones, that's fine as
it doesn't really matter if the list is not complete, since then we fall
back to being a bit ugly.

Cheers, Phil.
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/    http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY

Attachment: signature.asc
Description: PGP signature

Reply to: