On Tue, Aug 18, 2020 at 12:15:52PM +0200, Martin Kolman wrote:
On Thu, 2020-08-13 at 09:22 -0400, Stephen John Smoogen wrote:
On Thu, 13 Aug 2020 at 08:58, Fabio Valentini <decathorpe@xxxxxxxxx> wrote:
> On Thu, Aug 13, 2020 at 2:16 PM <jkonecny@xxxxxxxxxx> wrote:
> > Hello everyone,
> >
> > Anaconda team has decided to deprecate use of Anaconda kernel boot
> > parameters without 'inst.' prefix. As you may already know you can
> > specify Anaconda kernel boot parameters both with and without 'inst.'
> > prefix (e.g. 'inst.repo=' or 'repo='). This deprecation means that when
> > you use Anaconda option without the 'inst.' prefix you will now get a
> > warning. We are *not* disabling parameters without a prefix yet.
> >
> > The reason for this is keep running into parameter conflicts with other
> > projects. As an example there is 'debug' parameter for both kernel and
> > us, so when you want to enable kernel debugging in installation
> > environment you will also enable Anaconda debug mode.
> >
> > Because of this I have created the following pull request for Anaconda:
> >
> > https://github.com/rhinstaller/anaconda/pull/2786
> >
> >
> > In case you have any objections please start discussion either on the
> > pull request or here.
> >
> >
> > Best regards,
> > Jirka
>
> This may be a stupid question, but why are parameter namespaced with
> "inst." and not with "anaconda."? Is this a historical artifact?
> "inst" is a pretty generic term as well, and "anaconda" would
> definitely not lead to parameter overloading on the kernel cmdline.
>
I think inst was meant to be universal so that debian etc could use
it. However I will say if I have to type 20 anaconda.<item>=<flag> on
a serial terminal like I have to for the inst.<item>=<flag> I will
quickly be looking for any other installer to use. I regularly end up
with enough redraw problems because the line went over whatever SOL or
the HTML-console thinks a line should be and clearing the entire line
so I can't see what I am typing.
The decision was made to make it generic but also to distinguish anaconda
options from dracut options, which were prefixed with 'rd.'. It helped with
bug triage as well sorting things between anaconda or dracut.
Given anaconda's backwards compatibility support, the non-prefixed options
still had to be supported.
IIRC there are some platforms (PPC ? s390?) that have pretty low limit on the
length of the string representing boot options, so not just typing - your
options might not physically fit in if the prefix was too long. :)
Maybe older ppc systems, but newer ones are slightly less insane. s390 and
s390x have the line length limit. When booting from z/VM, the command line
parameters are provided by a separate file that's loaded when the script used
to ipl the guest is run. This file has to be text and formatted as if from a
PC, so the line length limit is 80 characters. There is an upper bound on the
number of lines, but I forget what it is. I've had up to 10 lines and it's
fine. With this system, the lines are read in and concatenated and given to
the kernel as one string, so just continue the previous line to the next. For
this reason and others, prefixing the command line options with "anaconda."
was deemed unnecessarily long.
--
Stephen J Smoogen.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
--
David Cantrell <dcantrell@xxxxxxxxxx>
Red Hat, Inc. | Boston, MA | EST5EDT
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
