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.

  • Welcome to Retrocomputing. Thanks for this well researched, detailed question; keep up the good work! – wizzwizz4 Dec 1 '16 at 21:47
  • 2
    Adding as a comment because it's neither Linux nor BSD, but Minix apparently supports i586 with 32 MiB RAM. – 8bittree Dec 2 '16 at 14:54
  • @8bittree: Thanks, indeed, Minix is also unix-ish, but I must admit that I fear that the amount of (free) software, which runs properly under Minix is rather small. Additionally, I'm not aware of Minix distributions, i.e. including packaged software in addition to the base system. – Axel Beckert Dec 2 '16 at 14:59
  • 2
    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 Dec 2 '16 at 18:54

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. – Axel Beckert Dec 1 '16 at 22:44
  • I've always been a fan of Slackware... Might have to try out the latest release on my P100 :) – Matt Lacey Jan 8 at 0:58

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 Dec 2 '16 at 1:13
  • 2
    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 Dec 2 '16 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. – Axel Beckert Dec 2 '16 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 Feb 15 '17 at 18:24
  • @ZanLynx, If you've got a shared filesystem that your target can use as its root filesystem, you can use a custom setting of ROOT on the build system to handle dependency tracking and compilation. Otherwise, your only option is to invoke ebuild directly and do the dependency tracking by hand. – Mark Feb 15 '17 at 20:05

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;  }
  • Welcome to Retrocomputing Stack Exchange. This is an excellent answer - did you work out these patches yourself? – wizzwizz4 Jul 26 '17 at 12:53
  • 3
    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. – Theodore Head Jul 26 '17 at 14:30
  • 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. – Axel Beckert Jul 31 '17 at 14:29
  • 1
    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. :-) – Theodore Head Aug 1 '17 at 15:14

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

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

  • 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 Jan 7 at 14:59

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.