as vmlinuz processes the kernel boot parameters, they should be echoed to indicate that vmlinuz recognizes the parameter and accepts it or rejects it. There are two cases -- install and boot. Both places should record processing of boot parameters into the log.
I would suggest this worked in the main-line kernel. The FC6 and rawhide kernels philosophy is to not be divergent from the main-line kernel, hence the reasoning. I am closing this BZ as CANTFIX and recommend that you work upstream this feature.
I'm not sure what you mean by "I would suggest this worked in the main-line kernel." I have never seen this anywhere. I see a message about decompressing the kernel and then initrd, but never, for example "'method=xxx' unrecognized". If this needs to be presented to a different group, then either please re- assign it or tell me who and I will re-sumbit it to them. This is an easy thing to do and is helpful for facilitating installation, which is pretty important for more general adoption.
I meant that I would suggest you work this in the main-line kernel. The other group I would suggest is the linux kernel mailing list. Go to www.kernel.org and follow instructions on how to enroll in the LKML mailing list and submit a patch.
Ah! I see. If I do this in the main line kernel, then that revision would flow through to vmlinuz... Right? I haven't contributed before, but I think I can do this and you have given me enought get started on the journey. Thank you.
That is correct. Fedora Core takes the main-line kernel, so if the feature you want shows up in the main-line kernel, then it will surely show up in FC. Good luck and Happy Halloween!
such a change would actually cause more problems than it would fix. think about cases like 'rhgb' which the kernel has no knowledge of, but gets passed through to userspace, which reads /proc/cmdline to determine whether or not to show the graphical UI. Anaconda also has a bunch of additional options that it can read from the boot cmdline, like 'noprobe'. The kernel has nothing to do with these options, and if it started complaining about them, it would make the installers life a lot more difficult.
I disagree. The request is not to filter and remove -- the request is simply identification. Don’t identify things mysterious to you, identify things that are familiar that you discover. For example "methdo=..." would be ignored because it is misspelled and "method=..." should correspondingly be "recognized” or even “recognized by vmlinuz”. “rhgb” would be ignored except by the component that recognized it. So, except for the improvement in clarity, nothing changes. The goal it to help identify and eliminate errors and transparency is the best way. If the policy were that each component that finds something notifies the user that they have discovered something, then diagnosis and debugging of startup (installation, and boot) problems becomes much easier. It is also helpful to expose the workings of the various startup components by having them announce what they are doing and why they are doing it.