Intel 32bit packages on Ubuntu from 19.10 onwards

Edit: The notice regarding dropping of 32 bit support has been superseded by this public statement:

Previous post (what follows is no longer accurate):

Cross posted from the Ubuntu Devel Announce mailing list.

Last year, the Ubuntu developer community considered the question of whether to continue carrying forward the i386 architecture in the Ubuntu archive for future releases. The discussion at the time was inconclusive, but in light of the strong possibility that we might not include i386 as a release architecture in 20.04 LTS, we took the proactive step to disable upgrades from 18.04 to 18.10 for i386 systems, to avoid accidentally stranding users on an interim release with 9 months of support instead of letting them continue to run Ubuntu 18.04 LTS with its 5 years of standard support.

In February of this year, I also posted to communicate the timeline in which we would take a final decision about i386 support in 20.04 LTS, namely, that we would decide in the middle of 2019.

The middle of 2019 has now arrived. The Ubuntu engineering team has reviewed the facts before us and concluded that we should not continue to carry i386 forward as an architecture. Consequently, i386 will not be included as an architecture for the 19.10 release, and we will shortly begin the process of disabling it for the eoan series across Ubuntu infrastructure.

While this means we will not provide 32-bit builds of new upstream versions of libraries, there are a number of ways that 32-bit applications can continue to be made available to users of later Ubuntu releases, as detailed here. We will be working to polish the 32-bit support story over the course of the 19.10 development cycle.


Q. What is i386?

“i386” is the architecture name used internally in Ubuntu, Debian and some other Linux distributions to refer to the 32-bit instructions used in many Intel and Intel-compatible CPUs. Typically an i386 installation of any Linux distribution is able to run a kernel, applications and libraries built for that architecture.

Conversely “amd64” is the name commonly used to refer to 64-bit architectures. Note that despite the name, the 64-bit capabilities are available in CPUs manufactured by AMD, Intel and others. Many prefer to use the more generic names “x86” for 32-bit and “x86_64” for 64-bit Intel-compatible CPUs. However in Ubuntu (via Debian) we’re internally using i386 and amd64.

Q. I am an author / publisher / developer of 32-bit only software. How can I build it and distribute for Ubuntu users?

We recommend publishing applications as snaps, which can leverage the “core18” runtime which supports 32-bit via the existing Ubuntu 18.04 archive.

Q. I have 32bit 16.04 LTS / 18.04 LTS installed, what are my upgrade options?

18.04 LTS has Standard Security support until 2023. Extended Security Maintenance runs for a further 5 years until 2028. You can stick with your current installed version until then and still be safe and secure.

This should give plenty of time to migrate away from 32-bit legacy applications before the next LTS which will be available in April 2020, or the following LTS in 2022. Alternatively place the legacy application inside an 18.04 LTS i386 container, on top of a newer 64-bit installation of Ubuntu.

Q. My hardware can’t run a 64bit version of Ubuntu, what are my options?

Hardware which will only run a 32bit operating system is getting pretty rare these days and is unlikely to have enough resources to run the latest release of Ubuntu Desktop. You can still run a supported i386 version of Ubuntu, such as the 18.04 LTS, or the same version of one of the flavours which will be more suited to your hardware.

Alternatively upgrade to a newer computer which has support for 64-bit operating systems. Most desktop / laptop CPUs manufactured in the last 10 years support 64-bit instructions. Both Intel and AMD have product support pages detailing the capabilities of each processor.

Q. What happens if I use a flavour of Ubuntu (Xubuntu / Lubuntu / Kubuntu etc)?

All the official flavours are built from the same common archive of software packages. As the Ubuntu archive drops support for i386, it would not be available to any flavours. If you absolutely need an i386 version then 18.04 LTS is still available.

Q. What happens for derivative distributions such as Linux Mint, Pop_OS and Zorin?

Many other Linux distributions have already moved to 64-bit only. Ubuntu derivatives can continue to build upon the Ubuntu 18.04 archive which provides i386 packages. We anticipate derivative distributions will also stop providing 32-bit installation media in line with other mainstream distributions, and in most cases they already have.

Q. Doesn’t Steam use 32 bit libraries? How can I play my games?

Steam itself bundles a runtime containing necessary 32-bit libraries required to run the Steam client. In addition each game installed via Steam may ship 32-bit libraries they require. We’re in discussions with Valve about the best way to provide support from 19.10 onwards.

It may be possible to run 32 bit only games inside a lxd container running a 32 bit version of 18.04 LTS. You can pass through the graphics card to the container and run your games from that 32bit environment.

Q. How can I run 32-bit Windows applications if 32-bit WINE isn’t available in the archive?

Try 64-bit WINE first. Many applications will “just work”. If not use similar strategies as for 32 bit games. That is use an 18.04 LTS based Virtual Machine or LXD container that has full access to multiarch 32-bit WINE and related libraries.

Q. I have a legacy proprietary 32-bit Linux application on my 64-bit installation. How can I continue running it.

Run an older release of Ubuntu which supports i386, such as 16.04 LTS or, preferably 18.04 LTS in a Virtual Machine or LXD container as above.

Q. Why are you doing this? Why now? This has come out of the blue!

This has been discussed in the past on the ubuntu-devel mailing list and the decision to drop i386 has been going on for over a year. You can read more in this mailing list post which includes links to the previous discussions.

It’s no longer possible to maintain the i386 architecture to the same standard as other Ubuntu supported architectures. There is lack of support in the upstream Linux kernel, toolchains, and web browsers. Latest security features and mitigations are no longer developed in a timely fashion for the 32 bit architecture and only arrive for 64 bit.

Maintaining the i386 archive requires significant developer and QA focus for an increasingly small audience running on what is considered legacy hardware. We cannot confidently publish i386 images any more and so have taken the decision to stop doing it. This will free up some time to focus on amd64. i386 makes up around 1% of the Ubuntu install base.


Here’s a good post which describes how to set up a LXD container for Steam from @simosx:


This has been 6 years of engagement (almost to the day). Here is a rough log of the surveys and decisions taken.

I’ve used lxc/d to run software built for 16.04 on 18.04 in the past, with GL passthrough. Whilst it “works”, it is very very ugly and not straightforward. There are a lot of gotchas with regards to networking, theming, folder sharing and hardware. I’ll be very impressed if you can get that all smoothed out by the next LTS.


Most of applications that have to be ran under wine are 32 bit. IIRC 32 bit dotnet works better than 64 bit one. I’m not talking about games, just applications for work. It’s not a big problem to use a container for me, I even wrote a simple script snr to automate running systemd-nspawn containers with graphical applications inside them, but what about many other people?


First I have no problem with drop i386-architecture.
But the problem i have some win32 software to handle my disability (dyslexia) that i use to read long text using text to speech (MS sapi4 and sapi5 api’s).
And the current voice of espeak are worst than the classic microsoft SAM.
I like to see that there is a small set of librarys/32 to 64 bit wrapers for running wine32.


So no more i386, but how about ARM-32bit / ARMHF?

1 Like

Brother has full support for their printers/MFC devices but even their newest devices only have 32bit driver packages.

Dropping support for the base libraries, so that things like this will no longer work, will cause a huge mess.


Getting rid of I386 makes sense, however the only thing is, some people are still running it.

But it shouldn’t be an issue, as most computers don’t run 64-bit anymore, and like everyone has it these days. And they have until 2023 with 18.04 to use i386, so this is a step forward.

The only question is-the race for a bigger type of RAM bit-like 128-bit, but I don’t think we will see that for a while.

Four rather rude comments deleted, and two of those users suspended.

Folks, keep your comments constructive. Help point out real issues and corner cases.

“I don’t like the decision” is not constructive feedback now. The time for persuasion was back before the boat sailed. The time for tantrums was back before your adult teeth grew in.

Folks who want to start a thread and discuss realistic ways to preserve i386 support are welcome to. That’s what this site is for. If new community working groups want to coalesce around i386, all the better.

Folks who want to rant and gnash their teeth and complain that this is the greatest injustice in the history of the world will find your keystrokes wasted here, as few will see them before they are removed. This is an announcement thread, not an opinion thread.


I like to see a small subset of the of the 32 that is only need for ruing wine and i think that most of this can be done as a x86 to x86-64 translation library and only the libc* as a true multiarch library.
The best is that wine64 get support to run win32 application native than passing to wine32.


Indeed. The discussions linked in the original posts conflate the difficulty in supporting legacy 32 bit hardware with the importance of supporting 32 bit software on machines running amd64. Dropping the i386 repos directly affects amd64 users.


I’m glad that 32-bit support is being dropped, Mac has already done the same, and the amount of people running 32-bit systems who also run Linux is absolutely tiny. Hopefully this will finally force some developers to get it together and ship 64-bit versions of their software, such as Valve, who honestly should’ve just used 64-bit only from the start since their market is primarily gamers who have high-end systems.

For those people who do still need 32-bit, let me clarify something in this post: Ubuntu 18.04 LTS will have extended support until 2028, at which point the amd64 / x86_64 architecture will be nearly a quarter of a century old.

1 Like

That’s only true if you pay for ESM, otherwise its 2023.


ESM to date has only every covered the 64-bit x86 AMD/Intel architecture. (It hasn’t been decided for 18.04 LTS, but I wouldn’t bet on it)

Please note that Many laptop (Asus, Acer) requires 32 bit efi with 64 bit grub. 32 bit efi requires grub-efi-32 to compile. Please provide a solution before dropping 32 bit altogether.

Also can I dual boot 32 bit Ubuntu/Windows with 64 bit Ubuntu ?


This is only for i386

I understand dropping 32.bit installation media and ISO etc. But you should keep support for 32 bit libraries. The solutions you are proposing for this issue are completely unacceptable for a Distro that wants to provide accessibility. You are also creating hurdles for gaming and and old windows software compatibility that is a major path to dekstop adoption for many users coming from windows. You are creating major delays for companies like Valve that have been supporting the Linux desktop as a alternative for windows out of worry of MS doing the exact same thing as you are doing now. Old software games or professional software will be dead in the water unless someone takes the hit and fixes them.

This is bad for the users and bad for desktop adoption both in the consumer but also the professional space (which very often uses old outdated software unfortunately) and it is a truly short-sighted decision. Give at least some basic multiarch support.