From Fedora Project Wiki
m (Add trackers)
 
(11 intermediate revisions by 4 users not shown)
Line 1: Line 1:


= No More i686 Kernels <!-- The name of your change proposal --> =
= No More i686 Kernels or bootable images<!-- The name of your change proposal --> =


== Summary ==
== Summary ==
Stop building i686 kernels, reduce the i686 package to a kernel-headers package that can be used to build 32bit versions of everything else.
Stop building i686 kernels, reduce the i686 package to a kernel-headers package that can be used to build 32bit versions of everything else. No kernel means we would stop producing i686 bootable images as well.


== Owner ==
== Owner ==
Line 18: Line 18:


== Current status ==
== Current status ==
* Targeted release: [[Releases/27 | Fedora 27 ]]  
* Targeted release: [[Releases/31 | Fedora 31 ]]  
* Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
* Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  
Line 28: Line 28:
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
-->
-->
* Tracker bug: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1728779 #1728779]
* Release notes tracker: [https://pagure.io/fedora-docs/release-notes/issue/357 #357]


== Detailed Description ==
== Detailed Description ==
Line 35: Line 36:
With this proposal, the i686 kernel will no longer be built. A kernel headers package will still exist, and all 32bit packages should continue to build as normal. The main difference is there would no longer be bootable 32bit images.
With this proposal, the i686 kernel will no longer be built. A kernel headers package will still exist, and all 32bit packages should continue to build as normal. The main difference is there would no longer be bootable 32bit images.


This was last proposed with Fedora 27, but it was deferred as an i686 SIG was to be created to handle issues going forward.  That SIG has been largely unresponsive.  The only thread so far this year has been a thread starting with "Hello, I noticed that the x86 group hasn't had any reports in a while. As the absentee sponsor of the group, I would like to remind people on the list and interested in keeping x86_32 in Fedora releases that there is general work which needs to be done by people interested. "  And the only response was one person saying they would no longer have access to legacy i686 hardware as of August.
== Benefit to Fedora ==
== Benefit to Fedora ==


More testable kernel updates, faster fixes for security bugs, and lowered exposure.  
More testable kernel updates, faster fixes for security bugs, and lowered exposure.  
    
    
== Scope ==
== Scope ==
* Proposal owners:
* Proposal owners:
Line 47: Line 48:
<!-- 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?-->


* Release engineering: [https://pagure.io/releng/issues #Releng issue number] (a check of an impact with Release Engineering is needed) <!-- REQUIRED FOR SYSTEM WIDE AS WELL AS FOR SELF CONTAINED CHANGES -->
* Release engineering: [https://pagure.io/releng/issue/8461] (a check of an impact with Release Engineering is needed) <!-- REQUIRED FOR SYSTEM WIDE AS WELL AS FOR SELF CONTAINED CHANGES -->
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuild required?  include a link to the releng issue.  
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuild required?  include a link to the releng issue.  
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: Drop i686 based images <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Please check the list of Fedora release deliverables and list all the differences the feature brings -->
<!-- Please check the list of Fedora release deliverables and list all the differences the feature brings -->


* Policies and guidelines: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Policies and guidelines: N/A (not needed for this change)<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Do the packaging guidelines or other documents need to be updated for this feature?  If so, does it need to happen before or after the implementation is done?  If a FPC ticket exists, add a link here. -->
<!-- Do the packaging guidelines or other documents need to be updated for this feature?  If so, does it need to happen before or after the implementation is done?  If a FPC ticket exists, add a link here. -->


Line 81: Line 82:


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
N/A Nothing to test, we simply stop producing a flavor of the kernel package.
N/A Nothing to test, we simply stop producing a flavor of the kernel package. As there is no direct upgrade path from i686 -> x86_64, users with capable hardware will have to reinstall.


== User Experience ==
== User Experience ==
<!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice. -->
<!-- If this change proposal is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice. -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
The few 32bit users will have the full lifecycle of Fedora 26 to choose a time to upgrade to a 64bit installation.  Some old hardware will no longer be supported by fedora.
The few 32bit users will have the full lifecycle of Fedora 30 to choose a time to upgrade to a 64bit installation.  Some old hardware will no longer be supported by fedora.


== Dependencies ==
== Dependencies ==
Line 92: Line 93:


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
N/A (not a System Wide Change)
32 bit x86 images can no longer be built.


== Contingency Plan ==
== Contingency Plan ==


<!-- 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: (What to do?  Who will do it?) N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Contingency mechanism: (What to do?  Who will do it?) Start building an i686 kernel again <!-- 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: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Contingency deadline: As QA requires for image candidates <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
* Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Blocks release? Yes <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Blocks product? product <!-- Applicable for Changes that blocks specific product release/Fedora.next -->
* Blocks product? product Fedora 31<!-- Applicable for Changes that blocks specific product release/Fedora.next -->


== Documentation ==
== Documentation ==
Line 108: Line 109:


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
N/A (not a System Wide Change)
The lack of an i686 image will need to be documented.


== Release Notes ==
== Release Notes ==
Line 117: Line 118:
-->
-->


[[Category:ChangePageIncomplete]]
[[Category:ChangeAcceptedF31]]
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
Line 124: Line 125:


<!-- Select proper category, default is Self Contained Change -->
<!-- Select proper category, default is Self Contained Change -->
[[Category:SelfContainedChange]]
<!-- [[Category:SelfContainedChange]] -->
<!-- [[Category:SystemWideChange]] -->
[[Category:SystemWideChange]]

Latest revision as of 16:56, 10 July 2019

No More i686 Kernels or bootable images

Summary

Stop building i686 kernels, reduce the i686 package to a kernel-headers package that can be used to build 32bit versions of everything else. No kernel means we would stop producing i686 bootable images as well.

Owner

  • Name: Justin Forbes
  • Email: jforbes@fedoraproject.org
  • Release notes owner:

Current status

Detailed Description

The i686 kernel is of limited use as most x86 hardware supports 64bit these days. It has been in a status of "community supported" for several Fedora releases now. As such, it gets very little testing, and issues frequently appear upstream. These tend to go unnoticed for long periods of time. When issues are found, it is often a long time before they are fixed because they are considered low priority by most developers upstream. This can leave other architectures waiting for important updates, and provides a less than desirable experience for people choosing to run a 32bit kernel. With this proposal, the i686 kernel will no longer be built. A kernel headers package will still exist, and all 32bit packages should continue to build as normal. The main difference is there would no longer be bootable 32bit images.

This was last proposed with Fedora 27, but it was deferred as an i686 SIG was to be created to handle issues going forward. That SIG has been largely unresponsive. The only thread so far this year has been a thread starting with "Hello, I noticed that the x86 group hasn't had any reports in a while. As the absentee sponsor of the group, I would like to remind people on the list and interested in keeping x86_32 in Fedora releases that there is general work which needs to be done by people interested. " And the only response was one person saying they would no longer have access to legacy i686 hardware as of August.

Benefit to Fedora

More testable kernel updates, faster fixes for security bugs, and lowered exposure.

Scope

  • Proposal owners:

Changes to the kernel spec to stop the actual i686 builds, but keep the kernel-headers package.

  • Other developers: NA
  • Release engineering: [1] (a check of an impact with Release Engineering is needed)
  • Policies and guidelines: N/A (not needed for this change)
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

32bit i686 users will need to reinstall as x86_64 with the next release.

How To Test

N/A Nothing to test, we simply stop producing a flavor of the kernel package. As there is no direct upgrade path from i686 -> x86_64, users with capable hardware will have to reinstall.

User Experience

The few 32bit users will have the full lifecycle of Fedora 30 to choose a time to upgrade to a 64bit installation. Some old hardware will no longer be supported by fedora.

Dependencies

32 bit x86 images can no longer be built.

Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) Start building an i686 kernel again
  • Contingency deadline: As QA requires for image candidates
  • Blocks release? Yes
  • Blocks product? product Fedora 31

Documentation

The lack of an i686 image will need to be documented.

Release Notes