+++ This bug was initially created as a clone of Bug #738494 +++
The introduction in the first lines of /usr/share/doc/kernel-doc-*/Documentation/kernel-parameters.txt gives a very strong indication that:
Hyphens (dashes) and underscores are equivalent in parameter names, so
can also be entered as
Adding the dashed version as a kernel parameter do however give 3 times "dracut Warning: Signal caught!" and a shell. There is _no_ indication what the problem is and it is impossible for mortals to debug it.
I assume this is a variation of the problem mentioned on https://bugzilla.redhat.com/show_bug.cgi?id=733674#c9
--- Additional comment from firstname.lastname@example.org on 2011-10-09 06:14:17 EDT ---
There are two bugs:
1) a kernel bug. It does not apply the dash-to-underscore conversion to early
boot parameters. log_buf_len is an early parameter. As a consequence the
string "log-buf-len=1M" gets passed in the environment to userspace.
FWIW, I think it would be confusing if the kernel did dash-to-underscore conversion on everything before exporting to environment. IMHO dash-to-underscore should only be applied to kernel parameters as they are recognized by the kernel, not to other random boot parameters, and not when exporting to environment. Instead I would expect that it only exported values that had a valid sh variable name on left hand side. That would also avoid injecting other invalid identifiers in the environment, such as the case of "foo,bar=baz" as boot parameter.
Nothing should rely on the fragile kernel environment variable export. The
kernel might suppress or mangle any parameter at any time.
Dracut should not export this to any file or tool, it should clean the
environment and force all tools to directly read /proc/cmdline. It's the
only safe option, everything else just asks for trouble, today and in
Please let us get rid of the use of the environment. All keys with '.' in
it are suppressed since ages, betting on luck here will just not work.
Dracut should clean the environment entirely, and not store it anywhere
else, so people do not run into such issues with mangled kernel strings.
Ideally the kernel would stop exporting anything, or at least we would
teach the kernel to suppress the exporting of any string that doesn't
match very simple key names '[A-Z_-]=' like TERM= HOME=.
(In reply to comment #2)
> Nothing should rely on the fragile kernel environment variable export. The
> kernel might suppress or mangle any parameter at any time.
So bug 733674 should be reopened?
> Ideally the kernel would stop exporting anything, or at least we would
> teach the kernel to suppress the exporting of any string that doesn't
> match very simple key names '[A-Z_-]=' like TERM= HOME=.
Was it intentional that you only included upper case and that you included dash?
I proposed a patch to treat dashes and underscores as equal for the purpose of recognizing kernel parameters:
It is needed regardless of the concerns about environment.
(In reply to comment #3)
> Was it intentional that you only included upper case and that you included
Yeah, ideally the entire export would go away, but to avoid breaking the
historic use cases like TERM= we could filter for the usual UNIX env key
format which is all uppercase key names. All kernel options and module
parameters usually contain lowercase in the key name.
(In reply to comment #4)
> I proposed a patch to treat dashes and underscores as equal for the purpose of
> recognizing kernel parameters
That looks good.
Rusty asked for a number of changes and this didn't make it into the 3.1 kernel. At the moment, F16 is looking to ship with 3.1 final. Moving this bug to rawhide, where it will likely land first.
This should now be in rawhide.