Language Selection

English French German Italian Portuguese Spanish

In Fedora 31, 32-bit i686 is 86ed

Filed under
Red Hat

The release of Fedora 31 drops the 32-bit i686 kernel, and as a result bootable images. While there may be users out there who still have hardware which will not work with the 64-bit x86_64 kernel, there are very few. However, this article gives you the whole story behind the change, and what 32-bit material you’ll still find in Fedora 31.

The i686 architecture essentially entered community support with the Fedora 27 release. Unfortunately, there are not enough members of the community willing to do the work to maintain the architecture. Don’t worry, though — Fedora is not dropping all 32-bit packages. Many i686 packages are still being built to ensure things like multilib, wine, and Steam will continue to work.

While the repositories are no longer being composed and mirrored out, there is a koji i686 repository which works with mock for building 32-bit packages, and in a pinch to install 32-bit versions which are not part of the x86_64 multilib repository. Of course, maintainers expect this will see limited use. Users who simply need to run a 32-bit application should be able to do so with multilib on a 64-bit system.

Read more

Fedora drops 32-bit Linux

  • Fedora drops 32-bit Linux

    Seven years ago, Linus Torvalds dropped "ancient-386-CPUs" support from the Linux kernel, dismissing it with "good riddance." While 32-bit Linux lingered on, it was no longer part of Linux's mainstream. Gradually, distributions such as Arch Linux dumped it, as well. Then, Canonical decided to boot 32-bit Linux out of Ubuntu, and people threw a fit. Canonical backed off and returned some 32-bit Linux libraries. Now, it's time to see what people think of Fedora Linux dropping support for its last 32-bit -- i686 -- Linux.

    This has been coming for some time. Fedora's developer first proposed getting rid of this 32-kernel when it was putting together Fedora 27 in 2017. The last 32-bit version was given a reprieve to see if the Fedora community would keep it afloat without any Red Hat help. It didn't.

Fedora to drop support for 32-bit Linux with Fedora 31

  • Fedora to drop support for 32-bit Linux with Fedora 31

    Linux distributions have slowly but steadily started dropping support for 32-bit (i686) machines, and Fedora looks to be the latest distro to shed the past. Fedora 31, set to release on October 29, will no longer support 32-bit Linux.

    In a post on the Fedora Wiki, Justin Forbes (the maintainer of the Fedora kernel) said that the team behind the Linux distro would “stop producing i686 bootable images.” Forbes reasons that “most x86 hardware support 64bit (sic) these days.” Forbes also referred to the lack of community development since the release of Fedora 27, when 32-bit development was moved to a “community-supported” status.

Fedora Linux wisely kills 32-bit version

  • Fedora Linux wisely kills 32-bit version

    I fondly remember building my first-ever 64-bit computer with an AMD 3200+ processor. While it seems like only yesterday, the reality is, that was more than 15 years ago! Yes, 64-bit consumer chips have been around that long, showing how asinine it is for operating systems to still support outdated 32-bit hardware in 2019. Shockingly, Microsoft has 32-bit Windows 10, while countless Linux distributions support the antiquated hardware too. Sigh.

    Thankfully, the good folks that develop the excellent Fedora Linux distribution have finally had enough. Beginning with the upcoming version 31 of the operating system, i686 32-bit processor support is being dropped by the Fedora Project. While it absolutely is the correct decision, there will undoubtedly be whining from some vocal crybabies in the Linux community. After all, for some Linux users, the act of complaining seems to be a popular pastime.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

Screencasts/Audiocasts/Shows: elementary OS, Zorin OS, Emacs, Vim and Artificial intelligence as Free Software

  • Early Look at elementary OS 6 New Desktop Features - Road to Odin
  • Zorin OS 15.3 Lite overview | Your old computer. New again.

    In this video, I am going to show an overview of Zorin OS 15.3 Lite and some of the applications pre-installed.

  • Boost Productivity With Emacs, Org Mode and Org Agenda

    Do you use "productivity apps"? If so, Emacs, Org Mode and Org Agenda lets you make todo lists, schedule tasks, manage projects and much more. I've never been a "todo list" or "appointment scheduling" kind of person but the more I play with Emacs and Org, the more I think that I should be doing these things.

  • The Untapped Magic Of The Vim Runtime Directories

    Prior to using plugin managers vim plugins were handled in a completely different way, you would make use of all these special run time directories and be required to move the files for each plugin into the specified directories, while they're not used as much anymore there's no reason why you can't make use of them in a modern vim configuration.

  • Artificial intelligence as Free Software with Vincent Lequertier

    For the seventh episode of our Software Freedom Podcast we talk with Vincent Lequertier about transparency, fairness, and accessibility as crucial criteria for artificial intelligence (AI) and why it is important for our society to release AI software under a Free Software license. Our guest for the seventh episode of the Software Freedom Podcast is Vincent Lequertier. Vincent is a member of the Free Software Foundation Europe and is researching AI in the health care sector. Together we discuss the use and development of artificial intelligence from a Free Software perspective. Vincent explains what AI actually is and why it is important for our society to release AI software under a Free Software license. We discuss why the criteria of transparency, fairness and accessibility are important when working with artificial intelligence and how they relate to Free Software. Finally, we also discover what challenges AI is facing in the future and whether we should be afraid of the increasing use of this technology in our daily lives.

NVIDIA GeForce vs. AMD Radeon Vulkan Neural Network Performance With NCNN

With having added Tencent's NCNN tests to the Phoronix Test Suite with Vulkan acceleration, here is a look at the real-world impact by using RealSR-NCNN for scaling up with RealSR. Various NVIDIA GeForce and AMD Radeon graphics cards were tested for this initial NCNN / RealSR-NCNN Vulkan comparison. This is our first time looking at how well Vulkan performs in this area with the current state of the Linux drivers. The GeForce hardware was tested with the latest 450 series proprietary driver while on the Radeon side it was with Linux 5.9 and Mesa 20.3-devel using the RADV Vulkan driver. One of the Tencent developers working on NCNN has commented as well that using RADV's ACO offers a big boost for the performance, which fortunately is the current default for the RADV Vulkan driver. Read more Also: Phoronix Test Suite / OpenBenchmarking.org Now Has 600 Different Tests/Benchmarks

Kernel Space: Trenchboot, RAID10, Spelling Mistakes and Initcalls

  • Trenchboot Secure Launch Support For Linux Sees New Patches

    For a while now Oracle engineers and others have been working on Trenchboot as a means of secure launch/boot support when paired with the likes of Intel TXT and AMD SKINIT for trusted execution and configuring each piece of the software boot chain for trusted/secure handling. The latest kernel patches have been sent out for review for secure launching of the kernel. Earlier this year Oracle engineers sent out Linux kernel patches for Trenchboot while on Thursday the newest work surfaced.

  • Linux 5.10 To See RAID10 DISCARD Improvement - From 259 Seconds To Less Than 1 Second

    Queued today into the block subsystem's "-next" area ahead of the Linux 5.10 cycle kicking off next month are some MD RAID enhancements. In particular, thanks to Red Hat's Xiao Ni is improved RAID10 discard request handling. The change with a set of five SSDs in a RAID10 array on a test system dropped the mkfs.xfs time for creating an XFS file-system taking 4 minutes 39 seconds to less than 1 second... Quite a noticeable difference in that scenario.

  • Colin King: Kernel janitor work: fixing spelling mistakes in kernel messages

    The Linux 5.9-rc6 kernel source contains over 300,000 literal strings used in kernel messages of various sorts (errors, warnings, etc) and it is no surprise that typos and spelling mistakes slip into these messages from time to time. To catch spelling mistakes I run a daily automated job that fetches the tip from linux-next and runs a fast spelling checker tool that finds all spelling mistakes and then diff's these against the results from the previous day. The diff is emailed to me and I put my kernel janitor hat on, fix these up and send these to the upstream developers and maintainers. The spelling checker tool is a fast-and-dirty C parser that finds literal strings and also variable names and checks these against a US English dictionary containing over 100,000 words. As fun weekend side project I hand optimized the checker to be able to parse and spell check several millions lines of kernel C code per second.

  • Initcalls, part 2: Digging into implementation

    In the first part of this blog post series on Linux kernel initcalls, we looked at their purpose, their usage, and ways to debug them (using initcall_debug or FTrace). In this second part, we'll go deeper into the implementation of initcalls, with a look at the colorful __device_initcall() macro, the rootfs initcall, and how modules can be executed.

Graphics: AMD, KWinFT and Zink

  • AMD Sends Out Linux Kernel Support For Van Gogh APUs - Confirms DDR5 Memory, VCN3

    s a nice Friday afternoon patch series there is the 275k lines of code for wiring up the next-generation AMD Van Gogh APU support under Linux. Earlier this week there were the Mesa patches for AMD Dimgrey Cavefish and Van Gogh while today the kernel-side portion for Van Gogh was sent out for the AMDGPU kernel driver.

  • AMD Van Gogh APUs Spotted In Linux Patch, Features DDR5, Navi 2 iGPU

    AMD submitted the 45 Linux kernel patches, which weigh in at 275,000 lines of code, to enable Linux support for the coming APUs. The patches also reveal that Van Gogh comes with Video Core Next 3.0, which supports AV1 decode. In the past, Phoronix has found patches indicating VCN 3.0 (video encode) is native to the Navi 2 graphics engine. Pairing the Navi 2 / RDNA 2 graphics engine with DDR5/LPDDR5 could unlock quite a bit of graphical horsepower, as integrated graphics engines tend to respond well to increased memory throughput. Van Gogh is also predicted to come with Zen 2 cores, and it will certainly be interesting to see what kind of impact the improved memory throughput has on the Zen 2 architecture.

  • Roman Gilg: Universal means to specific ends

    Today new beta versions for all KWinFT projects – that are KWinFT, Wrapland, Disman and KDisplay – were released. With that we are on target for the full release which is aligned with Plasma 5.20 on October 13. Big changes will unquestionable come to Disman, a previously stifled library for display management, which now learns to stand on its own feet providing universal means for the configuration of displays with different windowing systems and Wayland compositors. But also for the compositor KWinFT a very specific yet important feature got implemented and a multitude of stability fixes and code refactors were accomplished. In the following we will do a deep dive into reasons and results of this recent efforts.

  • Mike Blumenkrantz: Engage Thrusters

    Briefly, zink copies the framebuffer state, there’s a number of conditions under which a new pipeline object is needed, which all result in ctx->gfx_pipeline_state.hash = 0;. Other than this, there’s sample count check for sample changes so that the shader can be modified if necessary, and then there’s the setup for creating the Vulkan framebuffer object as well as the renderpass object in get_framebuffer(). Eagle-eyed readers will immediately spot the problem here, which is, aside from the fact that there’s not actually any reason to be setting up the framebuffer or renderpass here, how zink is also flushing the current batch if a renderpass is active. The change I made here was to remove everything related to Vulkan from here, and move it to zink_begin_render_pass(), which is the function that the driver uses to begin a renderpass for a given batch.