Missing foreign architecture in eoan

popey · September 24, 2019, 8:41am

Currently the 19.10 daily amd64 image ships with no foreign architectures. This makes installing 32-bit software such as Steam (and others) difficult for new users. The 19.04 amd64 release images had i386 foreign architecture enabled by default, so this seems to be a regression since the last release.

I appreciate there have been many long discussions about the (possible) future(s) of i386 packages and support. However, as I understand it, right now 19.10 ships with i386 packages in the archive, and will do on release day. So for an amd64 install, I would expect there to be an i386 foreign architecture configured.

Steps to reproduce…

Boot 19.10
Run dpkg --print-foreign-architectures in a terminal

I’d expect i386 in the output, but get nothing.

I appreciate the workaround is to use dpkg --add-architecture i386 but that’s impenetrable tech nonsense for normals who just want to install the latest Ubuntu, get Steam and start gaming. It will also exacerbate the (still held) opinion among our users and detractors that we are “killing gaming on Linux” by making i386 software installations difficult.

Our most recent statement on the matter says It has always been our intention to maintain users’ ability to run 32-bit applications on 64-bit Ubuntu – our kernels specifically support that.

Will this be fixed before 19.10 is released?

vorlon · September 25, 2019, 8:12pm

This was the result of a change made at the time we intended to drop the i386 architecture. The apt-setup change was reverted soon after it became clear we would not drop i386 from the archive, but the change did not get propagated to ubiquity because it had not been reuploaded.

Anyone installing eoan with beta or later media will get the prior expected behavior, of i386 enabled by default.

popey · September 25, 2019, 11:09pm

Thanks!

(this is padding)

joshi81 · September 27, 2019, 2:43pm

How about those of us who have already installed Eoan, before beta? Reinstall?

bdmurray · September 27, 2019, 3:20pm

popey mentions the workaround in his original post:

If you do that you can avoid needing to reinstall.

joshi81 · September 27, 2019, 3:42pm

Thank you, missed that completely.

wxl · January 16, 2020, 8:35pm

I don’t see this fixed in Eoan or Focal for that matter.

popey · January 16, 2020, 8:39pm

What makes you say it’s not fixed @wxl? Pretty sure this was sorted in eoan some months back.

wxl · January 16, 2020, 8:51pm

I just ran dpkg --print-foreign-architectures in Eoan and Focal and got no results.

bdmurray · January 16, 2020, 8:58pm

Is this on a fresh install or an upgrade? If it is an upgrade from which media did you install? You can check via ‘cat /var/log/installer/media-info’.

wxl · January 16, 2020, 8:59pm

It’s a fresh install. For that matter, it’s present on the live CD.

bdmurray · January 16, 2020, 9:15pm

I am not seeing this on Focal.

bdmurray@clean-focal-amd64:~$ dpkg --print-foreign-architectures
i386
bdmurray@clean-focal-amd64:~$ cat /var/log/installer/media-info
Ubuntu 20.04 LTS “Focal Fossa” - Alpha amd64 (20200106)

wxl · January 16, 2020, 9:34pm

Ok, I stand corrected. On the live CD, it’s showing the incorrect behavior, but the installed system (with updates) shows the correct behavior. On Lubuntu, it’s incorrect on both, though. So what’s Lubuntu missing?

popey · January 16, 2020, 10:01pm

Confirmed both eoan and focal have the i386 architecture enabled.

Here’s the conversation where it was fixed. https://irclogs.ubuntu.com/2019/09/25/%23ubuntu-release.html#t05:22

I don’t know enough about how these components interact to know why it works fine on Ubuntu but not Lubuntu? Is it anything to do with the fact that Ubuntu uses Ubiquity and Lubuntu uses Calamares, perhaps?

wxl · January 16, 2020, 10:09pm

Since the fix is in Ubiquity, that’s most certainly where the issue lies. That also explains why the live environment doesn’t show it.

wxl · January 17, 2020, 12:49am

So, question: why not throw this change into casper so that we can all enjoy it? Added benefit is that it will be there in the live environment.

popey · January 17, 2020, 9:04am

The “fix” was just undoing an change made previously which removed i386 support from amd64 installs.

Was the feature ever in Calamares based installs to enable the i386 foreign arch on non-ubiquity based installs? Perhaps that’s just been a missing feature of that installer? Because to me it looks like it’s “always” (i.e. for a long time) been on the Ubiquity installs, just an oversight when Calamares was introduced, relatively recently.

Sounds like a bug needs to be filed against Calamares and tracked there?

wxl · January 17, 2020, 5:41pm

Calamares is a general installer meant to work over a wide variety of package managers. That’s a good thing because it’s applicable to a wide variety of distros. However, that makes it a little less specific, too. I guess it’s reasonable that they could allow some configuration option to select architectures, but you got to admit, this is a pretty weird edge case given the vast majority of install situations across many distros.

That said, instead of hiding the idea in Ubiquity, if we had it in casper instead, it would have two benefits:

Regardless of installer used, everyone would get the right architectures. I imagine this could benefit derivatives and remixes as well as official flavors.
All of the right architectures would be there in the live system, which would have the added benefit of supporting folks that are using live with persistence.

mwhudson · January 21, 2020, 12:48am

If we want the change to apply everywhere, it seems to me we should build images with the foreign architecture enabled rather than enabling in both casper and the installer separately. I don’t know if there’s a reason that would be a bad idea though.

wxl · January 21, 2020, 6:02am

I guess I wasn’t suggesting the change be both in the installer and in casper, but strictly in the latter.