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
On Thu, Aug 13, 2020 at 2:16 PM jkonecny@redhat.com 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
On Thu, 13 Aug 2020 at 08:58, Fabio Valentini decathorpe@gmail.com wrote:
On Thu, Aug 13, 2020 at 2:16 PM jkonecny@redhat.com 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 decathorpe@gmail.com wrote:
On Thu, Aug 13, 2020 at 2:16 PM jkonecny@redhat.com 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 -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
On Thu, Aug 13, 2020 at 9:43 AM jkonecny@redhat.com 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@gmail.com wrote:
On Thu, Aug 13, 2020 at 2:16 PM jkonecny@redhat.com 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
On Thu, 2020-08-13 at 09:22 -0400, Stephen John Smoogen wrote:
On Thu, 13 Aug 2020 at 08:58, Fabio Valentini decathorpe@gmail.com wrote:
On Thu, Aug 13, 2020 at 2:16 PM jkonecny@redhat.com 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 -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
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@gmail.com wrote:
On Thu, Aug 13, 2020 at 2:16 PM jkonecny@redhat.com 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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org