< Changes
m (Language, typos) |
(fixed up some of the wording) |
||
| Line 6: | Line 6: | ||
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. | <!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. | ||
Note that motivation for the change should be in the Benefit to Fedora section below, and this part should answer the question "What?" rather than "Why?". --> | Note that motivation for the change should be in the Benefit to Fedora section below, and this part should answer the question "What?" rather than "Why?". --> | ||
Right now Anaconda allows both with prefix (inst.stage2=) | Right now Anaconda allows usage of boot options both with the 'inst' prefix (inst.stage2=) and without (stage2=). We would like to ignore the use of Anaconda kernel boot parameters which do not contain the 'inst.' prefix. | ||
== Owner == | == Owner == | ||
| Line 51: | Line 51: | ||
<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --> | <!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --> | ||
Anaconda allows you to use kernel boot parameters with and without 'inst.' prefix right now (e.g. inst.repo= / repo=). | Anaconda allows you to use kernel boot parameters with and without the 'inst.' prefix right now (e.g. inst.repo= / repo=). However, specifying boot parameters without the 'inst' prefix has not been recommended for years and has been deprecated since Fedora 33. We (Anaconda team) would like to make it an official requirement now that users must specify the 'inst.' prefix all the time. | ||
The reason for this | The reason for this is frequent parameter conflicts with other projects. As an example there is the 'debug' parameter for both kernel and Anaconda. Another reason is to make it readable at first glance what belongs to Dracut (rd.), kernel (no prefix) or Anaconda (inst.). | ||
We already had a few issues with conflicts in the past, | We already had a few issues with conflicts in the past, such as if the user ran an installation with `debug`. In that case the installation boot would enable debug mode for the kernel and also for Anaconda which is probably not what the user intended. | ||
== Feedback == | == Feedback == | ||
| Line 91: | Line 91: | ||
--> | --> | ||
This change should make crystal clear what kernel boot parameters are processed by the Anaconda installer. | This change should make crystal clear what kernel boot parameters are processed by the Anaconda installer. | ||
It will also avoid conflicts with other kernel boot parameters | It will also avoid conflicts with other kernel boot parameters. | ||
== Scope == | == Scope == | ||
* Proposal owners: | * Proposal owners: | ||
<!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
Remove support to process arguments without the 'inst.' prefix and require 'inst.' prefix for kernel boot parameters consumed by Anaconda. | Remove support to process arguments without the 'inst.' prefix and require the 'inst.' prefix for kernel boot parameters consumed by Anaconda. | ||
* Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<!-- What work do other developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do other developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
All configurations using the not recommended solution without prefix have to change the invocation of the kernel boot options consumed by Anaconda. These users are already warned since Fedora 33 after boot. | All configurations using the not-recommended solution without prefix will have to change the invocation of the kernel boot options consumed by Anaconda. These users are already warned since Fedora 33 after boot. | ||
This should not be a problem for ISOs we ship because they already use the recommended 'inst.' prefix everywhere. However, it will probably touch some custom PXE | This should not be a problem for ISOs we ship because they already use the recommended 'inst.' prefix everywhere. However, it will probably touch some custom PXE configurations and other custom ISO configurations which are prone to this, because users often want to save typing and not explicitly write the 'inst.' prefix. Fortunately, most of these configuration changes shouldn't be that hard to change. | ||
* Release engineering: [https://pagure.io/releng/issues #Releng issue number] (a check of an impact with Release Engineering is needed) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * Release engineering: [https://pagure.io/releng/issues #Releng issue number] (a check of an impact with Release Engineering is needed) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
| Line 119: | Line 119: | ||
== Upgrade/compatibility impact == | == Upgrade/compatibility impact == | ||
<!-- What happens to systems that have had previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? --> | <!-- What happens to systems that have had previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? --> | ||
If your custom infra configuration is not updated then | If your custom infra configuration is not updated then new Fedora installations could not install correctly. Most probably the ISO will not boot (use of 'stage2=') or your repositories won't be used (use of 'repo='). | ||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
| Line 166: | Line 166: | ||
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --> | <!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --> | ||
* Contingency mechanism: The Anaconda team will revert code changes and get back support without the 'inst.' prefix. <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * Contingency mechanism: The Anaconda team will revert code changes and get back support for boot parameters without the 'inst.' prefix. <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --> | <!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --> | ||
* Contingency deadline: Final Freeze <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * Contingency deadline: Final Freeze <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
| Line 177: | Line 177: | ||
<!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
I don't think we need to document this change other than Release Notes. As | I don't think we need to document this change other than in Release Notes. As mentioned before, the solution without 'inst.' prefix has not been recommended for years and it should not be used anywhere in the official documentation. | ||
== Release Notes == | == Release Notes == | ||
Revision as of 00:35, 7 December 2020
Ignore Anaconda kernel boot parameters without 'inst.' prefix
Summary
Right now Anaconda allows usage of boot options both with the 'inst' prefix (inst.stage2=) and without (stage2=). We would like to ignore the use of Anaconda kernel boot parameters which do not contain the 'inst.' prefix.
Owner
- Name: Jiří Konečný
- Email: <jkonecny@redhat.com>
Current status
- Targeted release: Fedora 34
- Last updated: 2020-12-07
- FESCo issue: <will be assigned by the Wrangler>
- Tracker bug: <will be assigned by the Wrangler>
- Release notes tracker: <will be assigned by the Wrangler>
Detailed Description
Anaconda allows you to use kernel boot parameters with and without the 'inst.' prefix right now (e.g. inst.repo= / repo=). However, specifying boot parameters without the 'inst' prefix has not been recommended for years and has been deprecated since Fedora 33. We (Anaconda team) would like to make it an official requirement now that users must specify the 'inst.' prefix all the time.
The reason for this is frequent parameter conflicts with other projects. As an example there is the 'debug' parameter for both kernel and Anaconda. Another reason is to make it readable at first glance what belongs to Dracut (rd.), kernel (no prefix) or Anaconda (inst.).
We already had a few issues with conflicts in the past, such as if the user ran an installation with debug. In that case the installation boot would enable debug mode for the kernel and also for Anaconda which is probably not what the user intended.
Feedback
We have sent mail about doing the deprecation on Fedora 33. The only issue there was why the prefix is 'inst.' and not 'anaconda.'. https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/43LKTJOUO5TB7LGFWPRNXOYLEQF3KLGG/#ENTHA45Y6VO45FAD4ULPSHCTOXPML3PA
Benefit to Fedora
This change should make crystal clear what kernel boot parameters are processed by the Anaconda installer. It will also avoid conflicts with other kernel boot parameters.
Scope
- Proposal owners:
Remove support to process arguments without the 'inst.' prefix and require the 'inst.' prefix for kernel boot parameters consumed by Anaconda.
- Other developers:
All configurations using the not-recommended solution without prefix will have to change the invocation of the kernel boot options consumed by Anaconda. These users are already warned since Fedora 33 after boot. This should not be a problem for ISOs we ship because they already use the recommended 'inst.' prefix everywhere. However, it will probably touch some custom PXE configurations and other custom ISO configurations which are prone to this, because users often want to save typing and not explicitly write the 'inst.' prefix. Fortunately, most of these configuration changes shouldn't be that hard to change.
- Release engineering: #Releng issue number (a check of an impact with Release Engineering is needed)
- Policies and guidelines:
This should not be required. All the documentation should use the recommended 'inst.' prefix already.
- Trademark approval: N/A (not needed for this Change)
- Alignment with Objectives: No
Upgrade/compatibility impact
If your custom infra configuration is not updated then new Fedora installations could not install correctly. Most probably the ISO will not boot (use of 'stage2=') or your repositories won't be used (use of 'repo=').
How To Test
- You need a Virtual Machine and ISO for testing.
- Boot the installation using the ISO and try Anaconda specific kernel boot parameters. See here to find out the list https://anaconda-installer.readthedocs.io/en/latest/boot-options.html.
- Parameters without the prefix should be ignored and with the prefix should be used.
User Experience
Users of Fedora official ISOs should not be impacted because all the Fedora official ISOs should already use the recommended prefix.
Dependencies
Don't know about any packages impacted by this change.
Contingency Plan
- Contingency mechanism: The Anaconda team will revert code changes and get back support for boot parameters without the 'inst.' prefix.
- Contingency deadline: Final Freeze
- Blocks release? No
- Blocks product? This won't require changes for any specific product.
Documentation
I don't think we need to document this change other than in Release Notes. As mentioned before, the solution without 'inst.' prefix has not been recommended for years and it should not be used anywhere in the official documentation.