[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)



On Fri, 19 May 2023 at 09:19:35 -0500, G. Branden Robinson wrote:
> I have to ask how someone would conduct an install to a 32-bit x86 machine
> running under emulation, assuming no OS on the simulated machine.

I see four levels of support that we could reasonably have for i386:

1. same as in recent Ubuntu: just enough packages (mostly libraries) to
   configure it as a multiarch foreign architecture on an amd64 system,
   and run legacy Linux i386 binaries directly or legacy Windows i386
   binaries via Wine

2. same as (1), plus basic utilities (coreutils, etc.) and optionally an
   init system, to be able to make a pure i386 container or chroot
   that can run on an externally-provided amd64 kernel

3. same as (2), plus kernel, bootloader and init system to be able to:
   (a) construct a complete bootable installation using debootstrap or
       similar;
   (b) upgrade existing i386 installations

4. user-facing media like debian-installer and Debian Live

Debian 12 is (4). Steve is talking about dropping down to (3), or possibly
lower, for Debian 13 (and I think that's a good idea).

For compatibility testing for what will happen to legacy 32-bit binaries,
I'd personally install multiarch foreign architecture packages on a
64-bit system (possibly emulated), which matches how we would expect
our users to run those legacy binaries "in production": after all,
there isn't a great deal of point in testing situations that we don't
expect to support. That matches how typical users of things like Steam
and 32-bit Wine are expected to run them today, and requires at least (1)
(I assume Ubuntu continues to keep (1) *because* those use-cases exist).

If we have at least (2), then it's also possible to make a 32-bit-only
container or chroot, using mmdebstrap or debootstrap or similar. For a
chroot, or a "chroot done properly"-style container with no init system
(conventional for Docker), an init system isn't needed. For a container
that boots like a lightweight alternative to a VM (conventional for lxc),
an init system like systemd will also be necessary. Some container
frameworks like Podman and systemd-nspawn can work either way.

If we have at least (3), then it's also possible to make a bootable
system, but without (4) you would have to either install Debian 12 and
upgrade, or use something like vmdb2 or debos, instead of installing
interactively with debian-installer. For a reproducible test system,
you might well want to do that anyway.

    smcv


Reply to: