Missing foreign architecture in eoan

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.



(this is padding)

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

popey mentions the workaround in his original post:

If you do that you can avoid needing to reinstall.

1 Like

Thank you, missed that completely.

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

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

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

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

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

I am not seeing this on Focal.

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

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?

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?

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.

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.

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?

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

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.

1 Like

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

1 Like

Just FYI, Lubuntu added a process to the installer to add the foreign architecture. In the event a decision is made to make this more universal through casper or in the images themselves (the more I think about @mwhudson’s suggestion, the more this makes the best sense), we can revert this, but at least this way the user has a good experience no matter what.

1 Like