Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Internal Error, Could not early remove libandroid-support:aarch64 (2) #4129

Closed
Dmole opened this issue Jul 31, 2019 · 25 comments
Closed

Internal Error, Could not early remove libandroid-support:aarch64 (2) #4129

Dmole opened this issue Jul 31, 2019 · 25 comments

Comments

@Dmole
Copy link
Contributor

@Dmole Dmole commented Jul 31, 2019

for pkg, and apt.

apt-get differs;

apt-get upgrade
Reading package lists... Done
Building dependency tree                        
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
  bash coreutils dpkg gpgv libandroid-support
  libunistring rsync vim wget
0 upgraded, 0 newly installed, 0 to remove and 9 not upgraded.

Maybe related;
https://github.com/termux/termux-packages#information-for-android-7-users

@Dmole

This comment has been minimized.

Copy link
Contributor Author

@Dmole Dmole commented Jul 31, 2019

re-installing the rootfs as described in the above link fixed this but that's more of a workaround. The package manager should take care if it.

@xeffyr

This comment has been minimized.

Copy link
Member

@xeffyr xeffyr commented Jul 31, 2019

apt-get upgrade

apt-get dist-upgrade as you actually not upgrading specific packages but whole distribution.

Maybe related;
https://github.com/termux/termux-packages#information-for-android-7-users

No, it isn't.

@xeffyr

This comment has been minimized.

Copy link
Member

@xeffyr xeffyr commented Jul 31, 2019

Interesting which version of libandroid-support you have.
Post output of apt show libandroid-support.

@Dmole

This comment has been minimized.

Copy link
Contributor Author

@Dmole Dmole commented Jul 31, 2019

apt-get was unable to install the packages it kept back, erroring with the same as pkg, and apt.
Install/upgrade should work regardless of dist-upgrade.

A fresh rootfs fixed the issue so clearly it was related (how could replacing everything with a fresh install not be related).

I'd love to try apt-get dist-upgrade and apt show libandroid-support for you but I did not keep a copy of the old rootfs.

@xeffyr

This comment has been minimized.

Copy link
Member

@xeffyr xeffyr commented Jul 31, 2019

should work regardless of dist-upgrade.

It shouldn't.
Regular upgrade will refuse to uninstall (even temporary) and replace packages if required.

In Termux you have to upgrade distribution (consist of upgrading, removing & replacing packages - whatever is required) and not currently installed packages.

@Dmole

This comment has been minimized.

Copy link
Contributor Author

@Dmole Dmole commented Jul 31, 2019

So maybe regular upgrade for apt/pkg was attempting to replace packages it should have left for full/dist-upgrade. Only apt-get knew to keep back some packages.

I have used dist-upgrade on other systems, and never have I seen regular upgrade break because full/dist-upgrade was not run. It's optional by definition. If that was the issue, i'd have to conclude termux is using package managers wrongly.

The whole point of apt update is it is supposed to be safe and never result in error. full/dist-upgrade is supposed to be the more risky operation.

@xeffyr

This comment has been minimized.

Copy link
Member

@xeffyr xeffyr commented Jul 31, 2019

I have used dist-upgrade on other systems, and never have I seen regular upgrade break

Typical Ubuntu & Debian installations will not cause such breakages. They do not use rolling-release update scheme and backwards-incompatible changes are introduced only with newer distribution version (e.g. in transition from Debian 8 to 9).

Termux is more like Arch Linux or Debian sid.

@Dmole

This comment has been minimized.

Copy link
Contributor Author

@Dmole Dmole commented Jul 31, 2019

I've never had such an issue with pacman but granted I use it less.

I think the bottom lines are;

  1. apt should have left the listed packages for full-upgrade instead of trying to replace them on upgrade.

  2. pkg has no full/dist-upgrade option (listed in help) so should not have errored or should not be installed if it can't be made to function.

@xeffyr

This comment has been minimized.

Copy link
Member

@xeffyr xeffyr commented Jul 31, 2019

  1. Pacman just goes stright forward and replaces everything. Unlike apt, it doesn't require additional command line utilities to work.
    When packages conflict, something should be removed.

  2. It has because it is wrapper for apt. See https://github.com/termux/termux-packages/blob/master/packages/termux-tools/pkg#L43

@Efreak

This comment has been minimized.

Copy link
Contributor

@Efreak Efreak commented Aug 1, 2019

Output here, @xeffyr

$ apt show libandroid-support -a
Package: libandroid-support
Version: 24-3
Essential: yes
Maintainer: Fredrik Fornwall @fornwall
Installed-Size: 176 kB
Pre-Depends: dpkg (>= 1.19.4-3)
Homepage: https://github.com/termux/libandroid-support
Download-Size: 105 kB
APT-Sources: https://termux.net stable/main arm Packages
Description: Library extending the Android C library (Bionic) for additional multibyte, locale and math support

Package: libandroid-support
Version: 24
Status: install ok installed
Essential: yes
Maintainer: Fredrik Fornwall @fornwall
Installed-Size: 176 kB
Homepage: https://github.com/termux/libandroid-support
Download-Size: unknown
APT-Manual-Installed: yes
APT-Sources: /data/data/com.termux/files/usr/var/lib/dpkg/status
Description: Library extending the Android C library (Bionic) for additional multibyte, locale and math support

$

Edit: apt-get dist-upgrade gives the same error as apt upgrade. I'm on arm, not aarch64, so that differs:

Do you want to continue? [Y/n]
E: This installation run will require temporarily removing the essential package libandroid-support:arm due to a Conflicts/Pre-Depends loop. This is often bad, but if you really want to do it, activate the APT::Force-LoopBreak option.
E: Internal Error, Could not early remove libandroid-support:arm (2)
@ssb22

This comment has been minimized.

Copy link

@ssb22 ssb22 commented Aug 1, 2019

I have the same problem. Transcript:

Welcome to Termux!

Wiki: https://wiki.termux.com
Community forum: https://termux.com/community
IRC channel: #termux on freenode
Gitter chat: https://gitter.im/termux/termux
Mailing list: termux+subscribe@groups.io

Search packages: pkg search
Install a package: pkg install
Upgrade packages: pkg upgrade
Learn more: pkg help
$ pkg upgrade
Hit:1 https://termux.net stable InRelease
Ign:2 https://dl.bintray.com/grimler/game-packages-21 games InRelease
Ign:3 https://dl.bintray.com/grimler/science-packages-21 science InRelease
Get:4 https://dl.bintray.com/grimler/game-packages-21 games Release [5344 B]
Hit:4 https://dl.bintray.com/grimler/game-packages-21 games Release
Get:5 https://dl.bintray.com/grimler/science-packages-21 science Release [5348 B]
Hit:5 https://dl.bintray.com/grimler/science-packages-21 science Release
Reading package lists.Reading package lists.Reading package lists.Reading package lists.Reading package lists.Reading package lists.Reading package lists.Reading package lists.Reading package lists.Reading package lists.Reading package lists.Reading package lists... Done
Building dependency trBuilding dependency trBuilding dependency trBuilding dependency trBuilding dependency trBuilding dependency tree
Reading state informatReading state informatReading state information... Done
40 packages can be upgraded. Run 'apt list --upgradable' to see them.
Reading package lists.Reading package lists.Reading package lists... Done
Building dependency trBuilding dependency trBuilding dependency trBuilding dependency trBuilding dependency tree
Reading state informatReading state informatReading state information... Done
Calculating upgrade...Calculating upgrade...Calculating upgrade... Done
The following NEW packages will be installed:
bzip2 coreutils
diffutils
findutils gnupg
grep gzip
libassuan libiconv
libksba libnpth
pcre pinentry sed
tar
termux-licenses
xz-utils
The following packages will be upgraded:
apt bash busybox
ca-certificates
clang
command-not-found
curl dnsutils dpkg
gdbm git gpgv krb5
ldns less
libandroid-support
libbz2 libc++
libcurl libdb
libffi libllvm
liblua liblzma
libnghttp2
libsqlite
libunistring man
ncurses
ncurses-ui-libs
netcat nodejs
openssh openssl
python readline
tcl termux-exec
termux-tools wget
40 upgraded, 17 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/55.5 MB of archives.
After this operation, 19.6 MB of additional disk space will be used.
Do you want to continue? [Y/n]
E: This installation run will require temporarily removing the essential package libandroid-support:aarch64 due to a Conflicts/Pre-Depends loop. This is often bad, but if you really want to do it, activate the APT::Force-LoopBreak option.
E: Internal Error, Could not early remove libandroid-support:aarch64 (2)
$

@Rmano

This comment has been minimized.

Copy link

@Rmano Rmano commented Aug 6, 2019

Same problem here..., I fixed it by reinstall the core too. A bit of cleanup is ok after months without using it...

@fadjriaf

This comment has been minimized.

Copy link

@fadjriaf fadjriaf commented Aug 6, 2019

Same Problem Here Too..
I Fixed it by Clear Data and Update the App..
My Termux Not Updated yet..
And It Works..

@xeffyr

This comment has been minimized.

Copy link
Member

@xeffyr xeffyr commented Aug 8, 2019

The following NEW packages will be installed:
bzip2 coreutils
diffutils
findutils gnupg
grep gzip
libassuan libiconv
libksba libnpth
pcre pinentry sed
tar
termux-licenses
xz-utils

Hmm, there happens following:

  • Few months ago iconv() implementation was moved from libandroid-support to libiconv. But since old libandroid-support provides libiconv.so symlink used by essential utilities (like coreutils), package libiconv can't be installed.

  • Now busybox was replaced by separate packages which makes coreutils to be required for installation. So here a conflict loop starts to happen.

Since now we have static libraries, I can link coreutils and few other essential packages with libandroid-support statically and remove this dependency (apt should be able to temporary uninstall/deconfigure it). But if this won't solve the issue, I'm not sure if something else can be done...

@emecas

This comment has been minimized.

Copy link

@emecas emecas commented Aug 11, 2019

Same Issue:

E: This installation run will require temporarily removing the essential package libandroid-support:arm due to a Conflicts/Pre-Depends loop. This is often bad, but if you really want to do it, activate the APT::Force-LoopBreak option.
E: Internal Error, Could not early remove libandroid-support:arm (2)

Fixed by removing and re-installing app, then:

pkg upgrade

Anyways, I'm still wondering about suggestion, how to activate the APT::Force-LoopBreak option ?

@xeffyr

This comment has been minimized.

Copy link
Member

@xeffyr xeffyr commented Aug 11, 2019

how to activate the APT::Force-LoopBreak option

Should be like apt -o APT::Force-LoopBreak=yes dist-upgrade.

@ssb22

This comment has been minimized.

Copy link

@ssb22 ssb22 commented Aug 13, 2019

@Dmole

This comment has been minimized.

Copy link
Contributor Author

@Dmole Dmole commented Aug 13, 2019

Unfortunately, the suggested command left me without a busybox package...

ssb22 as xeffyr has already seen in #4128 termux is asking the package managers to do the wrong thing, so just refresh the app and move on so no one need actually fix this issue.

@ssb22

This comment has been minimized.

Copy link

@ssb22 ssb22 commented Aug 13, 2019

@ulu

This comment has been minimized.

Copy link

@ulu ulu commented Aug 15, 2019

so just refresh the app and move on so no one need actually fix this issue.

Maybe I miss your point but using "clear all data" is not a solution but a complete desaster because all data is getting lost. Try to suggest this solution to upgrade installed Linux-Distributions from one version to another!

termux is asking the package managers to do the wrong thing

IMHO the package manager does what it should do. Upgrades using apt-get are working for years on Debian. If the system cannot correctly upgraded with a specific version then someone released a broken version.

@xeffyr

This comment has been minimized.

Copy link
Member

@xeffyr xeffyr commented Aug 15, 2019

If the system cannot correctly upgraded with a specific version then someone released a broken version.

Debian was "well designed" from scratch and critical dependency switches were not required, unlike Termux. Debian also not rolling release but Termux it is, once incompatible changes rolled out, they are expected for installation by everyone. Those who "holding" packages for long time are on their own.

It is possible to do upgrade without issues. Just little more work required than just pkg upgrade and will include manual installation of few packages through dpkg.

Switching implementation of different critical things used by package manager can broke system, especially if old and new package provide same file and old one has to be uninstalled to install a new one. This doesn't mean that new version is broken. It just broke previous.

@ulu

This comment has been minimized.

Copy link

@ulu ulu commented Aug 15, 2019

My answer is in two parts: Basic questions and problem solving. Let's start with the latter.

It is possible to do upgrade without issues. Just little more work required than just pkg upgrade and will include manual installation of few packages through dpkg.

Your suggestion above did not work. Which workaround will fix the issue?


Now to the basic questions. Firstly, I do not want to blame anyone. I just want to give some feedback to encourage reflection.

Debian also not rolling release but Termux it is, once incompatible changes rolled out, they are expected for installation by everyone. Those who "holding" packages for long time are on their own.

Every update process is a kind of rolling-release. It makes no sense to distinguish between a release "when its done" or "every 1st of July" - unless you want to say "rolling release" equals "untetest".

Updating/upgrading packages is handled by an update manager like apt. It's fault of the repository manager and package manager if the packages are not correctly rolled out. If any update is breaking the system and the latter is not recoverable then whole project is getting broken.

I didn't pin any packages, but I encountered the same problem as the error reporter. IMHO "holding" packages is something that is not part of the actual problem.

Switching implementation of different critical things used by package manager can broke system, especially if old and new package provide same file and old one has to be uninstalled to install a new one.

Please explain: Why can every serious Linux distro upgrade "apt" without any problem?

This doesn't mean that new version is broken. It just broke previous.

So you say: The system will probably be corrupted again and again by a subsequent update/upgrade? This is indeed a really serious problem for the whole project.

IMHO: If we cannot trust the update/upgrade process then the entire project is broken.

@xeffyr

This comment has been minimized.

Copy link
Member

@xeffyr xeffyr commented Aug 15, 2019

Your suggestion above did not work. Which workaround will fix the issue?

It works. But there additional arguments required for dpkg.

unless you want to say "rolling release" equals "untetest".

What I want to say is:

  1. There no schedule of releasing global/major changes. They can be released at any time.

  2. Changes may be backwards incompatible and tested only for ONE previous package version.

  3. If backwards-incompatible change scheduled, it is done independently of previous one. In rare cases
    backwards-incompatible changes are mutually-exclusive and replace each other.

  4. From point 2 & 3, it should became obviously that upgrade process should work fine when your packages are at "current" version and are not outdated (say installed half-year ago).

I didn't pin any packages

Never pin packages in Termux !

It's fault of the repository manager and package manager if the packages are not correctly rolled out.

I manually rolled out updates for:

  • Switching iconv(), iconv_open() implementation from libandroid-support to GNU libiconv.

  • Replacing busybox by standalone packages.

Check git for clear information about what was done.

Please explain: Why can every serious Linux distro upgrade "apt" without any problem?

Because it doesn't use libandroid-support and busybox as absolute base replacing which can broke system.

Termux isn't serious Linux distro and basically built on hacks - the main cause of introducing updates leading to potential breakage.

So you say: The system will probably be corrupted again and again by a subsequent update/upgrade?

In case of long-time "package holding", I can say only: Termux installations which didn't upgraded for long time are not guaranteed for successful upgrade in future. If you didn't used Termux for several month, it may be easier to wipe $PREFIX and re-install packages you need.

@xeffyr xeffyr closed this Aug 15, 2019
@pbuzdin

This comment has been minimized.

Copy link

@pbuzdin pbuzdin commented Aug 18, 2019

I have same problem

@yaoqs

This comment has been minimized.

Copy link

@yaoqs yaoqs commented Aug 28, 2019

I also have the same question.
Has the problem been solved?

@termux termux locked and limited conversation to collaborators Aug 28, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
10 participants
You can’t perform that action at this time.