Missing foreign architecture in eoan

#1

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?

5 Likes
#2

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.

2 Likes
#3

Thanks!

(this is padding)

#4

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

#5

popey mentions the workaround in his original post:

If you do that you can avoid needing to reinstall.

1 Like
#6

Thank you, missed that completely.

#7

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

#8

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

#9

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

#10

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’.

#11

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

#12

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)

#13

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?

#14

Confirmed both eoan and focal have the i386 architecture enabled.

Screenshot%20from%202020-01-16%2021-54-25
Screenshot from 2020-01-16 21-54-25.jpg1920×1080 506 KB

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?

#15

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.

#16

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.

#17

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?

#18

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:

  1. Regardless of installer used, everyone would get the right architectures. I imagine this could benefit derivatives and remixes as well as official flavors.
  2. 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.
1 Like
#19

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.

#20

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

1 Like