On Tue, 2015-10-20 at 15:02 +0800, Baoquan He wrote:
On 10/20/15 at 12:32am, Dangyi Liu wrote:
> The initial reason why I want to add this configuration is that
> some boot parameter would break kdump. For example, kernel
> developers may use slub_debug, which will cost extra memory. Normal
> users may use quiet, which makes kdump debug more difficult. It's
> necessary that in some cases admins want to remove some parameters
> from cmdline.
>
> And some parameters such as "crash kernel" should never be applied
> to the second kernel. We can remove them in kdumpctl directly.
OK, if it becomes a one by one check. Let's evaluate each of them,
how
about panic_on_warn? This one will nested panic in kdump kernel
because
of a warn. This can't be opened.
I didn't mean to put all existing items into the config file. But in
some cases admins do need to remove some boot parameters for the second
kernel. That's why I think maybe we can make it configurable.
I agree with that crashkernel and panic_on_warn should not be
configurable.
Next are hugepagexx. This could be opened again by user for
curiosity
or
efficiency and similar to slub_debug if enough crashkernel memory is
reserved. quiet, should be the same way.
This is about my 1st question. How about the 2nd? About the 3rd
question, that is a annoy and need be considered.
> > 在 2015年10月20日,上午11:46,Baoquan He <bhe(a)redhat.com> 写道:
> >
> > > On 10/19/15 at 04:29pm, Dangyi Liu wrote:
> > > Use KDUMP_COMMANDLINE_REMOVE config instead of hardcode them in
> > > kdumpctl. System admins can also specify what to remove as they
> > > like.
> > >
> > > However, this patch makes a change that kdump command line from
> > > KDUMP_COMMANDLINE will not be trimmed any more.
> > >
> > > Signed-off-by: Dangyi Liu <dliu(a)redhat.com>
> > > Cc: Dave Young <dyoung(a)redhat.com>
> > > Cc: Minfei Huang <mhuang(a)redhat.com>
> >
> > OK, I didn't follow this issue earlier. But I have some
> > questions.
> > Adding KDUMP_COMMANDLINE_REMOVE to put those kernel-parameters
> > under
> > /etc/sysconfig means they can be switched by users or admins
> > surely, just
> > like we do in KDUMP_COMMANDLINE_APPEND. I want to remind that all
> > of
> > stuffs put in KDUMP_COMMANDLINE_REMOVE are proved helpless for
> > vmcore
> > dumping. Turning one or several of them could cause bugs, but
> > turning
> > them off can prevent bugs and don't incur dumping issues. Then I
> > am
> > wondering why we want them to be turned on by users. E.g for
> > "crashkernel" could you tell in what cases user want to turn it
> > on in
> > kdump kernel?
> >
> > 2nd question is if we all agree to put them in
> > KDUMP_COMMANDLINE_REMOVE
> > do users know what they are used for and why they need remove and
> > in
> > which case they can be opened? Do you have a plan to elaborate
> > each of
> > them?
Only advanced users or instructed users may need to get access to this
config file. For example, we may tell some customers to "add quiet to
KDUMP_COMMANDLINE_REMOVE and send the full log to us", but we cannot
tell them "edit /bin/kdumpctl at line 108 to add quiet".
> >
> > 3rd, I saw you were confused about which one should be handled
> > firstly
> > about KDUMP_COMMANDLINE_APPEND and KDUMP_COMMANDLINE_REMOVE. This
> > is a
> > kind of torture we make to put on ourselves. We give users of
> > kdump too
> > many options.
I think it's better to remove first then append. For example we can
remove all "dydbg" first then add other dynamic debug options.
Dangyi