>> 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 ?