From: Simon Horman <horms@verge.net.au>
To: Dave Young <dyoung@redhat.com>
Cc: jstodola@redhat.com, kexec@lists.infradead.org
Subject: Re: [PATCH] kexec-tools: do not copy 1st kernel root= param in fs2dt.c
Date: Mon, 26 Oct 2015 13:31:19 +0900 [thread overview]
Message-ID: <20151026043119.GB2411@verge.net.au> (raw)
In-Reply-To: <20151019082246.GC31886@dhcp-129-115.nay.redhat.com>
On Mon, Oct 19, 2015 at 04:22:46PM +0800, Dave Young wrote:
> Hi, Simon
>
> On 10/16/15 at 10:33am, Simon Horman wrote:
> > Hi Dave,
> >
> > On Fri, Oct 09, 2015 at 01:57:22PM +0800, Dave Young wrote:
> > > Jan Stodola <jstodola@redhat.com> reported ppc64 root= is always added in kexec
> > > kernel cmdline. But sometimes we need boot without root= for example we use
> > > kexec to boot into installation initramfs image like below:
> > > kexec --load vmlinuz --initrd=initrd.img --command-line=\
> > > "inst.repo=http://<server>/<path>/Server/ppc64le/os/"
> > >
> > > While creating dtb, in case there's no root= in user provided cmdline params
> > > kexec-tools will find the original root= param used in 1st kernel and pass it
> > > to 2nd kernel. This caused that user have no way to remove root= cmdline.
> > >
> > > Dropping that part of code so that one can get chance to kexec into 2nd kernel
> > > without root= param. One can still provide root= in --command-line=""
> >
> > I'm a little concerned about the backwards-compatibility implications of
> > this change. Though I agree the new behaviour is entirely sane perhaps
> > it should be activated via a new command line option.
>
> I did not notice this problem until Jan reported it so I thouhgt that it
> is just a hidden assumption, people might not notice it and use it that
> way.
>
> For Fedora/RHEL kdump we will copy 1st kernel cmdline by default so one
> do not need to use it. For kexec and other distributions I'm not sure..
>
> Since it is more of a fix to original logic, personally I tend to not
> introducing a new option. But if you think we need to add a new option I
> can do it.
> > Also, won't this affect other architectures that use DT.
> > I'm thinking about ARM. If so it might be good to tweak the changelog.
>
> arm also uses the function, but I need verify the behavior. Will tune the
> changelog after I confirming it.
Thanks
I'm still concerned that people may be relying on this behaviour.
But I agree it seems painful to add an option to get what
should have been the default.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
prev parent reply other threads:[~2015-10-26 4:31 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-09 5:57 [PATCH] kexec-tools: do not copy 1st kernel root= param in fs2dt.c Dave Young
2015-10-16 1:33 ` Simon Horman
2015-10-19 8:22 ` Dave Young
2015-10-23 3:19 ` Dave Young
2015-10-23 9:23 ` Dave Young
2015-10-26 4:32 ` Simon Horman
2015-10-26 7:32 ` Dave Young
2015-10-26 4:31 ` Simon Horman [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151026043119.GB2411@verge.net.au \
--to=horms@verge.net.au \
--cc=dyoung@redhat.com \
--cc=jstodola@redhat.com \
--cc=kexec@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.