Deprecation of Anaconda boot parameters without inst. prefix

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

[Fabio Valentini]

On Thu, Aug 13, 2020 at 2:16 PM  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.

Fabio

[Stephen John Smoogen]

On Thu, 13 Aug 2020 at 08:58, Fabio Valentini  wrote:
> On Thu, Aug 13, 2020 at 2:16 PM  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.

On Thu, 2020-08-13 at 09:22 -0400, Stephen John Smoogen wrote:
> On Thu, 13 Aug 2020 at 08:58, Fabio Valentini 
> wrote:
> > On Thu, Aug 13, 2020 at 2:16 PM  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.

I wasn't in the team when the decision to use `inst.` was made.
However, I agree with Stephen that it's just shorter and some people
have to write this a lot and lot of times. Also, it could be used for
multiple installers if they want to.

Jirka
> -- 
> Stephen J Smoogen.
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]

[Neal Gompa]

On Thu, Aug 13, 2020 at 9:43 AM  wrote:
> On Thu, 2020-08-13 at 09:22 -0400, Stephen John Smoogen wrote:
> > On Thu, 13 Aug 2020 at 08:58, Fabio Valentini 
> > wrote:
> > > On Thu, Aug 13, 2020 at 2:16 PM  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.
>
> I wasn't in the team when the decision to use `inst.` was made.
> However, I agree with Stephen that it's just shorter and some people
> have to write this a lot and lot of times. Also, it could be used for
> multiple installers if they want to.

It was intended to be a standard interface. And I'm pretty sure these
flags were created at around the same time that Anaconda was being
ported to Debian and having a generic prefix meant that
debian-installer could implement it. I don't know if d-i today
actually *does* have these, but I'm pretty sure that was the reason.

Though the cross-installer compatibility idea inspired the creation of
kickseed[1] for Debian and Ubuntu years later, too..

[1]: https://launchpad.net/kickseed

[Martin Kolman]

On Thu, 2020-08-13 at 09:22 -0400, Stephen John Smoogen wrote:
> On Thu, 13 Aug 2020 at 08:58, Fabio Valentini  wrote:
> > On Thu, Aug 13, 2020 at 2:16 PM  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.

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. :)
> -- 
> Stephen J Smoogen.
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]

[David Cantrell]

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  wrote:
> > > On Thu, Aug 13, 2020 at 2:16 PM  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 -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > 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/[e-mail]
>
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]