Project

General

Profile

Bug #11820

Synaptic displays and installs 64-bit packages by default

Added by jzakiya about 2 years ago. Updated almost 2 years ago.

Status:
Resolved
Priority:
Elevated
Assignee:
-
Category:
-
Target version:
Start date:
09/21/2016
Due date:
% Done:

100%

QA Check:
Pass
Feature Branch:
bugfix/11820-synaptic-vs-multiarch
Type of work:
Code
Blueprint:
Starter:
Affected tool:

Description

I am able to install Tail 2.6 on my laptop (new System76 Gazelle, I7, 16GB)
from USB, and then install apps from synaptic, and run them, such as htop.

I also have installed Tail 2.6 on the same laptop in VirtualBox 5.1.6 (latest)
but installed apps will not run. (I have never encountered this problem before.)

Example:

I installed htop from synaptic and get the following error in the terminal.

amnesia@amnesia:~$ htop
bash: /usr/bin/htop: cannot execute binary file: Exec format error

In get a similar problem when I installed and ran Ruby.

Associated revisions

Revision b2faa4ff (diff)
Added by intrigeri about 2 years ago

Disable the amd64 foreign architecture once we're doing doing stuff with amd64 packages.

Rationale: Synaptic does not handle well the multiarch use case, at least in Jessie.

Note that we previously had APT::Architectures configured in two different
places. Now we only enable the amd64 architecture only when needed, for most of
the config/chroot_local-hooks duration, and in one single place, to make it
possible to disable it afterwards (one can't use a chroot_local-hook to delete
/etc/apt/apt.conf, since live-build would copy it back in place from
config/chroot_apt/apt.conf during a later stage of the build).

Also, we have to explicitly set APT::Architectures to include only i386:
otherwise, apparently APT relies on dpkg's list of architectures, that includes
amd64 sinc we cannot do "dpkg --remove-architecture amd64" as we have amd64
packages installed, that we don't want to remove.

refs: #11820

History

#1 Updated by emmapeel about 2 years ago

  • Assignee set to jzakiya
  • QA Check set to Info Needed

So, you say this didn't happened with Tails 2.5?

Can you try:

Install the packages with `sudo apt install <package>` and see if hte problem persists.

Run synaptic from the command line and tell us if there are any errors in the console.

#2 Updated by jzakiya about 2 years ago

Like I said, this is the first time I've not been able to install apps via synaptic.
I rechecked installing apps in 2.5, and it continues to work there.

In 2.6, I tried `sudo apt install htop` and it failed to take my passord.
I then did a `sudo -s` and got a root prompt with my password, and tried again, and it failed again.

#3 Updated by spriver about 2 years ago

I reproduced the bug.
Synaptic is installing an amd64 version of e.g. htop, even if a 32-bit VM is being used. Installation of htop via apt install htop an i386 version, which is working then.

When an amd64 VM is being used in VirtualBox, the correct architecture version of the package is installed and is working then.

#4 Updated by intrigeri about 2 years ago

  • Status changed from New to Confirmed
  • Assignee changed from jzakiya to intrigeri
  • Priority changed from Normal to Elevated
  • Target version set to Tails_2.7
  • QA Check changed from Info Needed to Dev Needed
  • Type of work changed from Discuss to Code

Synaptic is installing an amd64 version of e.g. htop, even if a 32-bit VM is being used. Installation of htop via apt install htop an i386 version, which is working then.

When an amd64 VM is being used in VirtualBox, the correct architecture version of the package is installed and is working then.

Thanks!

So this is a problem with multiarch support in Synaptic. I doubt it affects only VirtualBox, so raising priority. I'll have a look.

#5 Updated by intrigeri about 2 years ago

  • Subject changed from installing apps from synaptic fails in VirtualBox to Synaptic installs 64-bit packages

#6 Updated by intrigeri about 2 years ago

  • Subject changed from Synaptic installs 64-bit packages to Synaptic displays and installs 64-bit packages by default
  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 10

In a libvirt/qemu VM, be it with a 64-bit CPU + 64-bit kernel, or with a 32-bit CPU + 32-bit kernel: Synaptic reloads package lists just fine (including both i386 and amd64 ones), but displays and installs only amd64 packages. I think it's a bug in Synaptic, that I've reported upstream. But it would be nice to fix this in Tails 2.7, so we need some solution that does not rely on waiting for a fix being available in Debian stable.

To display i386 packages, one can to click the "Architecture" button, and then both i386 and amd64 packages are shown. One can pre-select this view using the ViewMode "5" option in /root/.synaptic/synaptic.conf. But still, even if we did that, chances are that users are confused and install the wrong (amd64) package too often.

The best short-term fix might be to disable the amd64 architecture via config/chroot_local-hooks/. I'll try that.

#7 Updated by intrigeri about 2 years ago

intrigeri wrote:

The best short-term fix might be to disable the amd64 architecture via config/chroot_local-hooks/. I'll try that.

Sadly, this does not work out-of-the-box: if APT::Architectures is not explicitly configured, apparently APT relies on dpkg's list of architectures, and we cannot do "dpkg --remove-architecture amd64" as we have amd64 packages installed, that we want to keep. So I'll try setting APT::Architectures explicitly to include i386 only.

#8 Updated by intrigeri about 2 years ago

  • Assignee changed from intrigeri to bertagaz
  • % Done changed from 10 to 50
  • QA Check changed from Dev Needed to Ready for QA
  • Feature Branch set to bugfix/11820-synaptic-vs-multiarch

#9 Updated by bertagaz about 2 years ago

  • Status changed from In Progress to Fix committed
  • Assignee deleted (bertagaz)
  • % Done changed from 50 to 100
  • QA Check changed from Ready for QA to Pass

Indeed fixes the issue, so it's merged, congrats!

#10 Updated by bertagaz almost 2 years ago

  • Status changed from Fix committed to Resolved

Also available in: Atom PDF