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

[Philip Hands]

Cyril Brulebois  writes:

> Hi,
>
> Ben Hutchings  (2017-03-30):
>> Please go ahead.  There may be some users that set module options at
>> installation time and don't want them set in the installed system.  But
>> they are likely to be outnumbered by those who do want them set.  If
>> the installer can boot with those module options then the installed
>> system very likely can too.
>
> Thanks for weighing in. Phil, let's do that;

Jolly good.

udebs uploaded, git pushed & tagged.

> note: we have a couple of days at least before Stretch RC 3 but the
> sooner it gets uploaded, the better.

Sorry for the delay -- the local Kindergarten had a day off yesterday,
so I was feeding bantams and rabbits with my daughter for most of the
day :-)

>> > At least, are there any plans to keep the list of hardcoded things
>> > uptodate?
>> 
>> This is a good point.  Is there a list of things to check during each
>> release cycle?
>
> There isn't yet (at least that I know of), but there should be.

Absolutely, we should have a checklist (or automated test).

Although in this particular case I think that a failure to keep things
up to date is pretty fail-safe -- we would just end up with redundant
and harmless module options being set for modules that don't exist.
Also, new options that are added are quite likely to be things similar
to the fsck.* options, which are not really useful for d-i, so it
wouldn't surprise me if nobody would ever notice.

Should we have a bug to track the lack of a checklist/auto-checker for
now, or go immediately to adding stuff to the wiki?

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


signature.asc
Description: PGP signature

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

[Samuel Thibault]

Ben Hutchings, on jeu. 30 mars 2017 15:24:03 +0100, wrote:
> they are likely to be outnumbered by those who do want them set.

Not only that, but the manual does document that such options *are*
propagated to the installed system when placed properly. Not doing so is
really unexpected behavior.

Samuel

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

[Cyril Brulebois]

Hi,

Ben Hutchings  (2017-03-30):
> Please go ahead.  There may be some users that set module options at
> installation time and don't want them set in the installed system.  But
> they are likely to be outnumbered by those who do want them set.  If
> the installer can boot with those module options then the installed
> system very likely can too.

Thanks for weighing in. Phil, let's do that; note: we have a couple of
days at least before Stretch RC 3 but the sooner it gets uploaded, the
better.

> > At least, are there any plans to keep the list of hardcoded things
> > uptodate?
> 
> This is a good point.  Is there a list of things to check during each
> release cycle?

There isn't yet (at least that I know of), but there should be. There
are a list codenames in various components (if not only src:d-i), bits
for the website, probably the installation guide etc.

But it would be nice if we could just automate doing so on a regular
fashion, e.g. using some cronjob on dillon (see also detecting missing
git pushes for branches/tags). I'll probably deal with this specific
bit, but documentation could be added to the wiki I suppose. Wiki pages
should probably get a review at some point, too, but that's another
topic.


KiBi.


signature.asc
Description: Digital signature

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

[Ben Hutchings]

On Thu, 2017-03-30 at 15:46 +0200, Cyril Brulebois wrote:
[...]
> I find it hard to decided what to do with these patches, given the amount of
> options that can be passed to the kernel… The current behaviour is clearly not
> good but I'm not sure what can/could break as a result…

Please go ahead.  There may be some users that set module options at
installation time and don't want them set in the installed system.  But
they are likely to be outnumbered by those who do want them set.  If
the installer can boot with those module options then the installed
system very likely can too.

> At least, are there any plans to keep the list of hardcoded things uptodate?

This is a good point.  Is there a list of things to check during each
release cycle?

Ben.

-- 
Ben Hutchings
In a hierarchy, every employee tends to rise to his level of
incompetence.



signature.asc
Description: This is a digitally signed message part

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

[Cyril Brulebois]

Hi,

Philip Hands  (2017-03-20):
> Philip Hands  writes:
> 
> ...
> > whereas this is it succeeding:
> >
> >   http://78.137.97.249:8080/job/lvc_debian-miniiso/337/console
> 
> It seems that I should have waited for that to completely finish before
> firing of the mail ... that run had a race condition in the test.
> 
> The test now waits for grub.cfg to exist before looking at it:
> 
>   http://78.137.97.249:8080/job/lvc_debian-miniiso/340/console
> 
> The interesting bits are the line:
> 
>   And I intend to boot with options: wibble.foo=bar fsck.bar=baz
> 
> (wibble should be assumed to be a module, whereas fsck should not)
> 
> and the lines that start with:
> 
>   And running "...
> 
> where I'm grepping various files to make sure that they contain what I
> expected.
> 
> Cheers, Phil.
> 
> P.S. You'll note that the "wibble.foo=bar" option is assumed to be a module
> and so ends up setting things in /target/etc/modprobe.d/local.conf, but
> it also gets into the grub.cfg -- perhaps we should not be letting these
> assumed-to-be-module settings through to the installed grub.cfg, but
> that's more in-line with the idea of simply dropping the dot filtering,
> so seems the least intrusive change for now.

I find it hard to decided what to do with these patches, given the amount of
options that can be passed to the kernel… The current behaviour is clearly not
good but I'm not sure what can/could break as a result…

At least, are there any plans to keep the list of hardcoded things uptodate?


KiBi.


signature.asc
Description: Digital signature

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

[Philip Hands]

BTW the jenkins tests have now been duplicated on the proper
jenkins.debian.net setup.

The successful run using the pu/bug-853855 branches of di-utils and
rootskel is here:

  https://jenkins.debian.net/job/lvc_debian-miniiso/355/console

and the same test failing with the current daily build is here (look for
"did not give the expected outcome"):

  
https://jenkins.debian.net/view/lvc/job/lvc_debian-DI-miniiso-gui-daily-bugtest/3/console

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


signature.asc
Description: PGP signature

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

[Philip Hands]

Philip Hands  writes:

...
> whereas this is it succeeding:
>
>   http://78.137.97.249:8080/job/lvc_debian-miniiso/337/console

It seems that I should have waited for that to completely finish before
firing of the mail ... that run had a race condition in the test.

The test now waits for grub.cfg to exist before looking at it:

  http://78.137.97.249:8080/job/lvc_debian-miniiso/340/console

The interesting bits are the line:

  And I intend to boot with options: wibble.foo=bar fsck.bar=baz

(wibble should be assumed to be a module, whereas fsck should not)

and the lines that start with:

  And running "...

where I'm grepping various files to make sure that they contain what I
expected.

Cheers, Phil.

P.S. You'll note that the "wibble.foo=bar" option is assumed to be a module
and so ends up setting things in /target/etc/modprobe.d/local.conf, but
it also gets into the grub.cfg -- perhaps we should not be letting these
assumed-to-be-module settings through to the installed grub.cfg, but
that's more in-line with the idea of simply dropping the dot filtering,
so seems the least intrusive change for now.
-- 
|)|  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


signature.asc
Description: PGP signature

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

[Philip Hands]

Samuel Thibault  writes:

> Hello,
>
> Philip Hands, on ven. 24 févr. 2017 11:10:55 +0100, wrote:
>> I think these changes should do the trick:
>> 
>>   https://anonscm.debian.org/cgit/d-i/rootskel.git/log/?h=pu/bug-853855
>>   
>> https://anonscm.debian.org/cgit/d-i/debian-installer-utils.git/log/?h=pu/bug-853855
>> 
>> rootskel: I separated that into two commits (13c865dc & 4f8e64c1) to
>>   make it more obvious what I did.
>> 
>> di-utils: I've just removed the check for dots, so that they should then
>>   get included in the target's kernel command line
>> 
>> I'll try to sort out some tests for that later (jenkins just failed to
>> build an image for some reason).
>
> Do you have any news on the tests?

Thanks for the nudge -- the thing I'd not got around to was checking
that the test also fails with the unpatched daily .iso -- which can now
be seen here:

  
http://78.137.97.249:8080/job/lvc_debian-DI-miniiso-gui-daily-bugtest/7/console

whereas this is it succeeding:

  http://78.137.97.249:8080/job/lvc_debian-miniiso/337/console

I've also run a few other tests by hand, but there are of course
countless scenarios that I've not explored.

So, I think the fix ready for release.

Cyril,

  Are you OK with me including these patches, and releasing the two
  packages (rootskel, debian-installer-utils)?

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


signature.asc
Description: PGP signature

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

[Samuel Thibault]

Hello,

Philip Hands, on ven. 24 févr. 2017 11:10:55 +0100, wrote:
> I think these changes should do the trick:
> 
>   https://anonscm.debian.org/cgit/d-i/rootskel.git/log/?h=pu/bug-853855
>   
> https://anonscm.debian.org/cgit/d-i/debian-installer-utils.git/log/?h=pu/bug-853855
> 
> rootskel: I separated that into two commits (13c865dc & 4f8e64c1) to
>   make it more obvious what I did.
> 
> di-utils: I've just removed the check for dots, so that they should then
>   get included in the target's kernel command line
> 
> I'll try to sort out some tests for that later (jenkins just failed to
> build an image for some reason).

Do you have any news on the tests?

Samuel

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

[Samuel Thibault]

Philip Hands, on ven. 24 févr. 2017 11:10:55 +0100, wrote:
> I think these changes should do the trick:

They look good to me.

Samuel

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

[Ben Hutchings]

On Fri, 2017-02-24 at 11:10 +0100, Philip Hands wrote:
> > Samuel Thibault  writes:
> 
> > Hello,
> > 
> > Philip Hands, on lun. 13 févr. 2017 11:16:19 +0100, wrote:
> > > Ben Hutchings  writes:
> > > > On Sun, 2017-02-12 at 12:26 +0100, Samuel Thibault wrote:
> > > > > 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:
> > 
> > [...]
> > > 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.
> > 
> > That looks good to me. Anything against this solution?
> 
> I think these changes should do the trick:
> 
>   https://anonscm.debian.org/cgit/d-i/rootskel.git/log/?h=pu/bug-853855
>   
> https://anonscm.debian.org/cgit/d-i/debian-installer-utils.git/log/?h=pu/bug-853855
[...]

LGTM, though I'm not really familiar with this code.

Ben.

-- 
Ben Hutchings
All the simple programs have been written, and all the good names
taken.



signature.asc
Description: This is a digitally signed message part

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

[Philip Hands]

Samuel Thibault  writes:

> Hello,
>
> Philip Hands, on lun. 13 févr. 2017 11:16:19 +0100, wrote:
>> Ben Hutchings  writes:
>> > On Sun, 2017-02-12 at 12:26 +0100, Samuel Thibault wrote:
>> >> 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:
> [...]
>> 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.
>
> That looks good to me. Anything against this solution?

I think these changes should do the trick:

  https://anonscm.debian.org/cgit/d-i/rootskel.git/log/?h=pu/bug-853855
  
https://anonscm.debian.org/cgit/d-i/debian-installer-utils.git/log/?h=pu/bug-853855

rootskel: I separated that into two commits (13c865dc & 4f8e64c1) to
  make it more obvious what I did.

di-utils: I've just removed the check for dots, so that they should then
  get included in the target's kernel command line

I'll try to sort out some tests for that later (jenkins just failed to
build an image for some reason).

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


signature.asc
Description: PGP signature

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

[Samuel Thibault]

Hello,

Philip Hands, on lun. 13 févr. 2017 11:16:19 +0100, wrote:
> Ben Hutchings  writes:
> > On Sun, 2017-02-12 at 12:26 +0100, Samuel Thibault wrote:
> >> 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:
[...]
> 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.

That looks good to me. Anything against this solution?

Samuel

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

[Philip Hands]

Ben Hutchings  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:

  fsck.*
  locale.*
  luks.*
  net.*
  plymouth.*
  quotacheck.*
  rd.*
  systemd.*
  udev.*
  vconsole.*

assuming this page is up to date:

  https://www.freedesktop.org/software/systemd/man/kernel-command-line.html

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


signature.asc
Description: PGP signature

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

[Ben Hutchings]

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.  But I'm guessing that for some other boot loaders we
don't set the kernel parameters at all, so setting (some) parameters
there is better than nothing, right?

Ben.

-- 
Ben Hutchings
If God had intended Man to program,
we'd have been born with serial I/O ports.



signature.asc
Description: This is a digitally signed message part

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

[Samuel Thibault]

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.

So, does it look too ugly?

Samuel

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

[Emmanuel Kasper]

Le 03/02/2017 à 12:38, Ian Campbell a écrit :
> On Fri, 2017-02-03 at 12:22 +0100, Emmanuel Kasper wrote:
 A kernel boot param like net.ifnames=0 will be skipped when the
 installer parses the boot option for setting the bootloader.

 Found in di-utils: 

 # Skip module-specific variables
 varnodot="${var##*.*}"
 if [ "$varnodot" = "" ]; then
 continue
 fi

 So basically any option containing a dot is not propagated to the
 installed system.  This was introduced by
 7cf15980d714da8b958a73c93459ee09fdbb9415 ("Skip new module-
 specific
 parameters in user-params.")

 I found no documented or obvious reason for this behaviour.
>>>
>>> Sounds like the assumption was that any "foo.bar=baz" arguments
>>> were
>>> always to be used as the "bar=baz" option when loading the "foo"
>>> module
>>> (i.e. "modprobe foo bar=baz"), which I think the installer supports
>>> (for convenience) but perhaps not the installed system (where they
>>> should instead be in /etc/modules or /etc/modprobe.conf or similar)
>>> does not?
>>>
>>> which I think the installer supports
>>> (for convenience) but perhaps not the installed system (where they
>>> should instead be in /etc/modules or /etc/modprobe.conf or similar)
>>
>> Thanks for the analysys, it looks like a very much plausible rationale
>> behind this commit.
>>
>> If I understand you correctly, net.ifnames is understood as
>> a kernel module option, and modules options are not propagated to the
>> bootloader, because they "should" be configured in
>> /etc/modprobe.d/my_module.
> 
> That's along the lines of what I think might be happening, yess
> 
>> Actually I might be missing something, but if for instance I need a
>> kernel module option to make the installer boot on my hardware, like a
>> radeon.modeset=0, I probably need this on the installed system as well ?
> 
> Correct, my (unchecked) assumption was that something in d-i would be
> doing so.
> 
> You might find evidence of that in the fact that your net.ifnames=bar
> ended up under /etc/ somewhere, either in /etc/modprobe.d/* or
> /etc/modprobe.conf or /etc/modules.
> 

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

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

[Ian Campbell]

On Fri, 2017-02-03 at 12:22 +0100, Emmanuel Kasper wrote:
> > > A kernel boot param like net.ifnames=0 will be skipped when the
> > > installer parses the boot option for setting the bootloader.
> > > 
> > > Found in di-utils: 
> > > 
> > > # Skip module-specific variables
> > > varnodot="${var##*.*}"
> > > if [ "$varnodot" = "" ]; then
> > > continue
> > > fi
> > > 
> > > So basically any option containing a dot is not propagated to the
> > > installed system.  This was introduced by
> > > 7cf15980d714da8b958a73c93459ee09fdbb9415 ("Skip new module-
> > > specific
> > > parameters in user-params.")
> > > 
> > > I found no documented or obvious reason for this behaviour.
> > 
> > Sounds like the assumption was that any "foo.bar=baz" arguments
> > were
> > always to be used as the "bar=baz" option when loading the "foo"
> > module
> > (i.e. "modprobe foo bar=baz"), which I think the installer supports
> > (for convenience) but perhaps not the installed system (where they
> > should instead be in /etc/modules or /etc/modprobe.conf or similar)
> > does not?
> > 
> > which I think the installer supports
> > (for convenience) but perhaps not the installed system (where they
> > should instead be in /etc/modules or /etc/modprobe.conf or similar)
> 
> Thanks for the analysys, it looks like a very much plausible rationale
> behind this commit.
> 
> If I understand you correctly, net.ifnames is understood as
> a kernel module option, and modules options are not propagated to the
> bootloader, because they "should" be configured in
> /etc/modprobe.d/my_module.

That's along the lines of what I think might be happening, yess

> Actually I might be missing something, but if for instance I need a
> kernel module option to make the installer boot on my hardware, like a
> radeon.modeset=0, I probably need this on the installed system as well ?

Correct, my (unchecked) assumption was that something in d-i would be
doing so.

You might find evidence of that in the fact that your net.ifnames=bar
ended up under /etc/ somewhere, either in /etc/modprobe.d/* or
/etc/modprobe.conf or /etc/modules.

It's only fair to warn you I might be talking BS here and reality is
nothing like that...

Ian.

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

[Emmanuel Kasper]

>> A kernel boot param like net.ifnames=0 will be skipped when the
>> installer parses the boot option for setting the bootloader.
>>
>> Found in di-utils: 
>>
>> # Skip module-specific variables
>> varnodot="${var##*.*}"
>> if [ "$varnodot" = "" ]; then
>> continue
>> fi
>>
>> So basically any option containing a dot is not propagated to the
>> installed system.  This was introduced by
>> 7cf15980d714da8b958a73c93459ee09fdbb9415 ("Skip new module-specific
>> parameters in user-params.")
>>
>> I found no documented or obvious reason for this behaviour.
> 
> Sounds like the assumption was that any "foo.bar=baz" arguments were
> always to be used as the "bar=baz" option when loading the "foo" module
> (i.e. "modprobe foo bar=baz"), which I think the installer supports
> (for convenience) but perhaps not the installed system (where they
> should instead be in /etc/modules or /etc/modprobe.conf or similar)
> does not?
> 

> which I think the installer supports
> (for convenience) but perhaps not the installed system (where they
> should instead be in /etc/modules or /etc/modprobe.conf or similar)

Thanks for the analysys, it looks like a very much plausible rationale
behind this commit.

If I understand you correctly, net.ifnames is understood as
a kernel module option, and modules options are not propagated to the
bootloader, because they "should" be configured in
/etc/modprobe.d/my_module.

Actually I might be missing something, but if for instance I need a
kernel module option to make the installer boot on my hardware, like a
radeon.modeset=0, I probably need this on the installed system as well ?

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

[Ian Campbell]

On Wed, 2017-02-01 at 15:30 +0100, Emmanuel Kasper wrote:
> Package: di-utils
> Version: 1.117
> Severity: minor
> Tags: d-i
> 
> A kernel boot param like net.ifnames=0 will be skipped when the
> installer parses the boot option for setting the bootloader.
> 
> Found in di-utils: 
> 
> # Skip module-specific variables
> varnodot="${var##*.*}"
> if [ "$varnodot" = "" ]; then
> continue
> fi
> 
> So basically any option containing a dot is not propagated to the
> installed system.  This was introduced by
> 7cf15980d714da8b958a73c93459ee09fdbb9415 ("Skip new module-specific
> parameters in user-params.")
> 
> I found no documented or obvious reason for this behaviour.

Sounds like the assumption was that any "foo.bar=baz" arguments were
always to be used as the "bar=baz" option when loading the "foo" module
(i.e. "modprobe foo bar=baz"), which I think the installer supports
(for convenience) but perhaps not the installed system (where they
should instead be in /etc/modules or /etc/modprobe.conf or similar)
does not?

Of course this logic falls apart in the presence of "foo" (such as
"net") which are not modules but instead are subsystems.

Ian.

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

[Samuel Thibault]

Hello,

Cyril Brulebois, on Thu 02 Feb 2017 17:09:01 +0100, wrote:
> Emmanuel Kasper  (2017-02-01):
> > A kernel boot param like net.ifnames=0 will be skipped when the
> > installer parses the boot option for setting the bootloader.
> > 
> > Found in di-utils: 
> > 
> > # Skip module-specific variables
> > varnodot="${var##*.*}"
> > if [ "$varnodot" = "" ]; then
> > continue
> > fi
> > 
> > So basically any option containing a dot is not propagated to the
> > installed system.  This was introduced by
> > 7cf15980d714da8b958a73c93459ee09fdbb9415 ("Skip new module-specific
> > parameters in user-params.")
> > 
> > I found no documented or obvious reason for this behaviour.
> 
> Just to be sure, what's your complete kernel command line?

FI, the discussion that triggered this report is
https://lists.debian.org/debian-boot/2017/01/msg00322.html

where we can read

“
/proc/cmdline as seen from inside the running installer looks like this:

BOOT_IMAGE=/install.amd/vmlinuz vga=788 initrd=/install.amd/initrd.gz
--- quiet  net.ifnames=0
preseed/url=http://10.0.2.2:8148/testing-preseed.cfg auto locale=en_US
kbd-chooser/method=us netcfg/get_hostname=testing.raw
netcfg/get_domain=vagrantup.com fb=false debconf/frontend=noninteractive
console-setup/ask_detect=false console-keymaps-at/keymap=us
keyboard-configuration/xkb-keymap=us
”

Samuel

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

[Cyril Brulebois]

Control: severity -1 normal
Control: tag -1 - d-i

Hi,

Emmanuel Kasper  (2017-02-01):
> A kernel boot param like net.ifnames=0 will be skipped when the
> installer parses the boot option for setting the bootloader.
> 
> Found in di-utils: 
> 
> # Skip module-specific variables
> varnodot="${var##*.*}"
> if [ "$varnodot" = "" ]; then
> continue
> fi
> 
> So basically any option containing a dot is not propagated to the
> installed system.  This was introduced by
> 7cf15980d714da8b958a73c93459ee09fdbb9415 ("Skip new module-specific
> parameters in user-params.")
> 
> I found no documented or obvious reason for this behaviour.

Just to be sure, what's your complete kernel command line?


KiBi.


signature.asc
Description: Digital signature

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

[Emmanuel Kasper]

Package: di-utils
Version: 1.117
Severity: minor
Tags: d-i

A kernel boot param like net.ifnames=0 will be skipped when the installer 
parses the boot option for setting the bootloader.

Found in di-utils: 

# Skip module-specific variables
varnodot="${var##*.*}"
if [ "$varnodot" = "" ]; then
continue
fi

So basically any option containing a dot is not propagated to the
installed system.  This was introduced by
7cf15980d714da8b958a73c93459ee09fdbb9415 ("Skip new module-specific
parameters in user-params.")

I found no documented or obvious reason for this behaviour.


-- System Information:
Debian Release: 8.7
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)