Unfortunately Debian kicked out Pentium 1 (i586) CPU support from its 32-bit PC port (named i386 for historic circumstances) for its next stable release Debian 9 Stretch. (Then again they complain that there are no more devices validating the existence of this port in more or less the same breath…)

So I wonder which other current and active Linux or BSD distributions (not ELKS and not FUZIX) do still support 20 years old 32-bit PC hardware (I have e.g. two 760-series Thinkpads with Pentium 1: 760ED and 760XD) or current embedded devices like Vortex86-based devices.

So far I found:

I've also tried to figure out what's the minimum CPU requirement of Alpine Linux for x86 or for Gentoo Linux, but failed so far.

The Linux kernel no more supports i386 CPUs anymore since version 3.8. I'm though not sure if Linux still supports i486SX CPUs like the Vortex86SX which have less instructions (IIRC no FPU) and range below a normal i486. Not sure if any current BSD still supports i386 or i486SX CPUs.

A related question is "What is the oldest computer capable of running a modern version of Linux?", but I'm not trying to focus on the oldest hardware but on the OS with the lowest CPU requirements to find an OS for given, old hardware. Hence the separate question.

  • 5
    Adding as a comment because it's neither Linux nor BSD, but Minix apparently supports i586 with 32 MiB RAM.
    – 8bittree
    Commented Dec 2, 2016 at 14:54
  • 6
    the Linux From Scratch project (linuxfromscratch.org) probably has some useful info. You can always build your own distro (cross compiled or not). It's not as tough as it sounds, and is a lot of fun!
    – SnakeDoc
    Commented Dec 2, 2016 at 18:54
  • 6
    I honestly think there needs to be a distinction between "supporting" and "actually usable". The simple problem is that while something may technically run, it doesn't mean its actually usable. As computing resources expanded, both the kernel and user land expanded to "take up" those new found resources. In this example, yeokhengmeng.com/2018/01/make-the-486-great-again , installing Linux on a 486, he described how the machine took 11 minutes to JUST BOOT. So, "supported" -- yes. But only in the "check box" sense. Commented Jan 8, 2018 at 23:29
  • 1
    FreeBSD supports 386 with a FPU and above - freebsd.org/releases/12.1R/hardware Commented May 22, 2021 at 23:07
  • 2
    I have recently spent quite some time with x86 Alpine Linux on a Vortex86 device. Almost all of the packages work out of the box - we've run into that qt5 was compiled with SSE instructions which has been fixed, and that libEGL appears to be too. Commented Sep 14, 2021 at 20:01

8 Answers 8


Slackware still claims to support 486s:

Below is a list of minimum system requirements needed to install and run Slackware.

  • 486 processor
  • 64MB RAM (1GB+ suggested)
  • About 5GB+ of hard disk space for a full install
  • CD or DVD drive (if not bootable, then a bootable USB flash stick or PXE server/network card)

Knoppix also still claims to support 486s, although given that it's based on a mixture of Debian releases I have reason to doubt that:

  • Intel/AMD-compatible CPU (i486 and up),
  • RAM: at least 120 MB for the graphical desktop. Recommended for working with various office applications: 500MB RAM,
  • a bootable CD-ROM/DVD drive (IDE/ATAPI/SATA, Firewire, USB), or USB flash disk,
  • a standard SVGA-compatible graphics chipset,
  • PS/2 or USB Mouse.

The current Linux kernel still supports 486 CPUs, including FPU-less CPUs (it still has a FPU emulator). Vortex86SX CPUs are actually FPU-less i586-class CPUs.

  • Thanks for the comment about Vortex86SX being actually i586-class CPUs, just without FPU. I always wondered, why DM&P released a 486SX-compatible CPU after already having released an MMX-compatible one. They're less far away from each other than I thought. Commented Dec 1, 2016 at 22:44
  • I've always been a fan of Slackware... Might have to try out the latest release on my P100 :)
    – Matt Lacey
    Commented Jan 8, 2018 at 0:58

I have had great success with Gentoo Linux on the earliest generation of Intel 80486 processors, though I had to patch it (below).

It works on the later ones too (486DX2 and 486DX4, both clock multiplied and having the back-ported Pentium CPUID instruction).

I have it working on a Compaq LTE Elite 4/75CX laptop with a whopping 24MiB of memory.

Bugs have been filed with Gentoo for the following patches.

After you sync up the latest package configs with 'emerge --sync' or 'emerge-webrsync', you need to update the /usr/portage/profiles/arch/x86/make.defaults global configuration file because it assumes i686 as distributed.

So change this:

CFLAGS="-O2 -march=i686 -pipe"

to this:

CFLAGS="-O2 -march=i486 -pipe"

This glibc patch is needed for all i80486 and Pentium cpus because they all return (maxidx < 2) as true and the assert() causes the process to fail with a general protection fault. Unfortunately, that includes causing the init process to die, which makes your system panic.

--- glibc-2.23/sysdeps/x86_64/cacheinfo.c   2016-02-18 17:54:00.000000000 +0000
+++ tmp/cacheinfo.c 2017-07-07 14:58:25.840654116 +0000 @@ -259,7 +259,8 @@  static long int __attribute__ ((noinline))  handle_intel (int name, unsigned int maxidx)  {
-  assert (maxidx >= 2);
+  if (maxidx < 2)
+    return -1;
     /* OK, we can use the CPUID instruction to get all info about the
      caches.  */

This gcc patch is only needed for the first generation i80486, which lacks the CPUID instruction.

--- gcc-5.4.0/gcc/config/i386/cpuid.h   2015-06-18 10:56:43.000000000 +0000
+++ tmp/cpuid.h.newest  2017-07-07 21:54:34.598488154 +0000 @@ -1,5 +1,5 @@  /*
- * Copyright (C) 2007-2015 Free Software Foundation, Inc.
+ * Copyright (C) 2007-2017 Free Software Foundation, Inc.   *   * This file is free software; you can redistribute it and/or modify it  
* under the terms of the GNU General Public License as published by the @@ -47,7 +47,7 @@  #define bit_SSE      (1 << 25)  #define bit_SSE2 (1 << 26)  
-/* Extended Features */
+/* Extended Features (%eax == 0x80000001) */  /* %ecx */  #define bit_LAHF_LM  (1 << 0)  #define bit_ABM       (1 << 5) @@ -63,11 +63,15 @@ 
#define bit_MMXEXT  (1 << 22)  #define bit_LM       (1 << 29)  #define bit_3DNOWP   (1 << 30)
-#define bit_3DNOW  (1 << 31)
+#define bit_3DNOW  (1u << 31)
+/* %ebx  */
+#define bit_CLZERO (1 << 0)    /* Extended Features (%eax == 7) */  /* %ebx */  #define bit_FSGSBASE   (1 << 0)
+#define bit_SGX (1 << 2)  #define bit_BMI  (1 << 3)  #define bit_HLE   (1 << 4)  #define bit_AVX2  (1 << 5) @@ -87,11 +91,19 @@ 
#define bit_AVX512CD    (1 << 28)  #define bit_SHA      (1 << 29)  #define bit_AVX512BW (1 << 30)
-#define bit_AVX512VL   (1 << 31)
+#define bit_AVX512VL   (1u << 31)    /* %ecx */  #define bit_PREFETCHWT1     (1 << 0)  #define bit_AVX512VBMI  (1 << 1)
+#define bit_PKU    (1 << 3)
+#define bit_OSPKE  (1 << 4)
+#define bit_AVX512VPOPCNTDQ    (1 << 14)
+#define bit_RDPID  (1 << 22)
+/* %edx */
+#define bit_AVX5124VNNIW (1 << 2)
+#define bit_AVX5124FMAPS (1 << 3)    /* XFEATURE_ENABLED_MASK register bits (%eax == 13, %ecx == 0) */  #define bit_BNDREGS     (1 << 3) @@ -168,7 +180,7 @@
     /* Return highest supported input value for cpuid instruction.  ext can
-   be either 0x0 or 0x8000000 to return highest supported value for
+   be either 0x0 or 0x80000000 to return highest supported value for
    basic or extended cpuid information.  Function returns 0 if cpuid
    is not supported or whatever cpuid returns in eax register.  If sig
    pointer is non-null, then first four bytes of the signature @@ -224,21 +236,39 @@    return __eax;  }  
-/* Return cpuid data for requested cpuid level, as found in returned
+/* Return cpuid data for requested cpuid leaf, as found in returned
    eax, ebx, ecx and edx registers.  The function checks if cpuid is
    supported and returns 1 for valid cpuid information or 0 for
-   unsupported cpuid level.  All pointers are required to be non-null.  */
+   unsupported cpuid leaf.  All pointers are required to be non-null.  */    static __inline int
-__get_cpuid (unsigned int __level,
+__get_cpuid (unsigned int __leaf,
         unsigned int *__eax, unsigned int *__ebx,
         unsigned int *__ecx, unsigned int *__edx)  {
-  unsigned int __ext = __level & 0x80000000;
+  unsigned int __ext = __leaf & 0x80000000;
+  unsigned int __maxlevel = __get_cpuid_max (__ext, 0);
+  if (__maxlevel == 0 || __maxlevel < __leaf)
+    return 0;
+  __cpuid (__leaf, *__eax, *__ebx, *__ecx, *__edx);
+  return 1;
+/* Same as above, but sub-leaf can be specified.  */
+static __inline int
+__get_cpuid_count (unsigned int __leaf, unsigned int __subleaf,
+          unsigned int *__eax, unsigned int *__ebx,
+          unsigned int *__ecx, unsigned int *__edx)
+  unsigned int __ext = __leaf & 0x80000000;
+  unsigned int __maxlevel = __get_cpuid_max (__ext, 0);

-  if (__get_cpuid_max (__ext, 0) < __level)
+  if (__maxlevel == 0 || __maxlevel < __leaf)
     return 0;

-  __cpuid (__level, *__eax, *__ebx, *__ecx, *__edx);
+  __cpuid_count (__leaf, __subleaf, *__eax, *__ebx, *__ecx, *__edx);    return 1;  }
  • 1
    Welcome to Retrocomputing Stack Exchange. This is an excellent answer - did you work out these patches yourself?
    – wizzwizz4
    Commented Jul 26, 2017 at 12:53
  • 5
    Yes, I debugged the problem and wrote patches for all of this. Of course I found out that the upstream gcc and glibc software had versions of them too! So their upstream patches are the ones that I posted here. Commented Jul 26, 2017 at 14:30
  • 1
    Thanks for that impressive answer. I though assume you don't run the according compile jobs on the i486 with 24 MB of RAM locally but do the compilation elsewhere, either in advance or via distcc or so. Commented Jul 31, 2017 at 14:29
  • 6
    Yes, the solution I used was a $20 USB-to-IDE adapter to attach the drive to my modern laptop. I recompiled there, and then moved the drive back to the vintage machine. I have tried to recompile on an 80486 and it was ... disappointing. :-) Commented Aug 1, 2017 at 15:14

Linux still supports the 80486 SX: the SX was simply a DX without the FPU, and the FPU emulation code is still present (Processor type and features->Math emulation).

Finding a distro is a bit trickier. Gentoo still supports the 486 in theory (when the installation instructions call for downloading a "stage 3" archive, simply download the "i486" version), but practice is a bit harder. Gentoo is a source-based distribution, so all packages are compiled on your computer. As you can imagine, this is a bit slow on a 486, and in my experience, requires at least 250 MB of combined RAM+swap, with at least 48 MB of that as RAM (something a bit rare on 486 systems).

  • Is it possible to cross-compile Gentoo?
    – Random832
    Commented Dec 2, 2016 at 1:13
  • 4
    For the most part, yes. You still need that 48 MB of RAM and generous amounts of swap, though: the package manager is rather memory-hungry.
    – Mark
    Commented Dec 2, 2016 at 1:16
  • Yes, RAM is another issue. The 760ED from 1996 has less than 50 MB (currently not sure if 32 MB or 48 MB) RAM, but the 760XD (from 1997) has impressive 80 MB RAM. The latter currently runs Debian 8 Jessie. It runs, but rather slow. Disk space is another issue and the 1 GB of the 760 ED is rather small even for a slim Debian desktop, but the 760XD's 3 GB are sufficient. Commented Dec 2, 2016 at 11:40
  • @Mark: I'm a former Gentoo user and as I recall if you are cross-compiling you never need to run the package manager on the target. I believe you need some special configuration to separate your builder and your target's emerge/ports directories but you can handle all the dependencies and such on the builder. Good for cross-building to small RAM targets.
    – Zan Lynx
    Commented Feb 15, 2017 at 18:24
  • 2
    After further testing, I can't recommend running Gentoo on a system with less than 96 MB of RAM. Compiling GCC 5.4 on a system with 48 MB took 41 days, and used 360 MB of swap at peak, with some individual files taking more than a day to compile.
    – Mark
    Commented Sep 22, 2018 at 18:51

Modern Gentoo still works on the 486 in 2018!

You can see the details including the video of my attempt here: http://yeokhengmeng.com/2018/01/make-the-486-great-again/

Detailed instructions: https://github.com/yeokm1/gentoo-on-486

Summary of implementation:
1. Use a modern PC to do the compilation and installation
2. Adjust Portage settings to target 486
3. Modify Linux kernel options with the 486 option
4. Compile everything
5. Move the disk to the 486 PC
6. Profit!

Thanks to the answers in this thread for pointing me in the right direction. https://retrocomputing.stackexchange.com/a/4364/7573 https://retrocomputing.stackexchange.com/a/1814/7573

  • 2
    Welcome to Retrocomputing. Thanks for providing a disclaimer for the tutorial and a summary here; most people don't take the time to do this! :-)
    – wizzwizz4
    Commented Jan 7, 2018 at 14:59

OpenBSD supports 80486DX and higher. 80486SX is not supported because it lacks floating point.


Just stumbled upon Tiny Core Linux which currently uses kernel 5.10 and claims that a 486DX with 46 MB of RAM suffices.

  • 1
    That’s interesting! I wonder how well it works in practice on a 486-based system since it runs entirely from RAM. Commented Dec 22, 2021 at 12:32
  • I plan to try it out instead of Debian 8 Jessie on one of my 760-series Thinkpads as you can completely forget Debian on even a Pentium 1 nowadays. Still need to figure out how to boot it as the hardware can only boot from floppy disks or hard disks. Maybe running it from the Jessie installation. Commented Dec 22, 2021 at 22:59
  • @StephenKitt: Regarding your edit of my answer: I usually prefer to show how I came to my conclusions or results. Commented Dec 22, 2021 at 23:57

In 2021 Arch Linux 32 and FreeBSD 12.2 still works on a Pentium-class machine in text mode, specifically on a Pentium 166 MMX with 64MB of RAM.

Arch Linux 32 provides i486, i686 (Pentium Pro or better), and pentium4 builds.

FreeBSD requires i686-class machine starting with version 13.0.

On the user experience side, expect:

  • boot time to the text login prompt in 5-10min range
  • 64MB of RAM is barely sufficient to do anything meaningful, like installing additional software with the package manager
  • swap is a must and will be used
  • use Syslinux bootloader
  • many Pentium motherboards, depending on the chipset and configuration, won't cache RAM past 64MB in L2 cache; running without L2 cache is so slow the systemd cannot complete boot process.

Realistically, a minimal 32-bit system requirement for modern software is Pentium III with 512MB of RAM and a Radeon-based AGP card. Graphical web browsing is possible in Firefox or Midori, yet very sluggish. As a general desktop UX, Raspberry Pi 4 destroys anything made prior to 64-bit CPUs were introduced, such as Athlon 64 and later Pentium 4 Prescott-s.

  • Thanks for that fresh input! For web browsing, I wouldn't use that bloat of Firefox on such a system. Netsurf, Dillo or Links 2.x are IMHO the proper choices for a GUI browser there. I also wouldn't use bloaty systemd as init system. Using sysvinit (still alive, version 3.00 about to be released) or OpenRC (from Gentoo) saves a lot of disk space and RAM. A boot up time of a few minutes is well known and expected, yes. That was already the case with Debian 8 Jessie on my Thinkpad 760ED with 48 MB RAM. I though don't see why a specific GPU should be necessary. Commented Sep 15, 2021 at 21:41
  • Radeon card can run composite desktop in a meaningful way. Also fast graphics-mode console, perhaps due to KMS. Commented Sep 16, 2021 at 9:24
  • 2
    Firefox and Chrome will be near unusable on a 660MHz system these days. Let alone 66. Commented Sep 16, 2021 at 20:15
  • 1
    FreeBSD 12 can not boot on my i586 machines, though it claims to support i486; this is also reported by other users, see bugs.freebsd.org/bugzilla/show_bug.cgi?id=250755.
    – Arnie97
    Commented Dec 5, 2021 at 1:13
  • Composite desktops don't make sense as they AFAIK need much more RAM as the compositor always needs to render the whole screen and not just a window. That's also the reason why Raspberry Pi OS falls back to non-composite rendering on models with less RAM. Commented Dec 22, 2021 at 23:53

And I can even top my previous answer: Via this Hackaday article about Linux running on an IBM Palmtop with a i486, I stumbled upon AOSC OS/Retro, a Linux distribution specific for retro computing. It explicitly targets Intel i486 and above for the x86 architecture.

And independently of that I recently noticed that Debian GNU/Hurd's GNU Mach kernel actually seems to get build for i486 CPUs and above, so I assume that Debian's GNU/Hurd userland is still build for i486 and above as well. (Granted, I only asked for Linux and BSD, but actually I should have asked for "free Unix-like distributions". :-)

  • 1
    FYI it requires at least 12MB of RAM
    – KERR
    Commented Mar 28, 2022 at 5:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .