Dpkg error while cleaning up

I get an error while doing the latest update

dpkg: error while cleaning up:
 rm command for cleanup subprocess was killed by signal (Segmentation fault)

and after the update, I also can not run the command termux-info its does not display output, only vibrations every time.

• runing on

$ uname -a
Linux localhost 3.18.19-12327063 #1 SMP PREEMPT Thu Jun 7 09:58:59 KST 2018 armv7l Android

• more details:

$ pkg up
Get:1 https://termux.net stable InRelease [1720 B]
Get:2 https://its-pointless.github.io/files termux InRelease [2061 B]
Get:3 https://termux.net stable/main arm Packages [63.1 kB]
Get:4 https://termux.xeffyr.ml extra InRelease [10.5 kB]
Hit:4 https://termux.xeffyr.ml extra InRelease
Get:5 https://its-pointless.github.io/files termux/extras all Packages [1504 B]
Get:6 https://its-pointless.github.io/files termux/extras arm Packages [16.8 kB]
Fetched 85.2 kB in 3s (24.4 kB/s)
Reading package lists... Done
Building dependency tree
Reading state information... Done
17 packages can be upgraded. Run 'apt list --upgradable' to see them.
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  coreutils debianutils dpkg dpkg-dev gettext gettext-dev libcaca libcaca-dev libcln
  libcln-dev libzopfli libzopfli-dev lldb lldb-dev lzip patchelf zopfli
17 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 13.4 MB of archives.
After this operation, 745 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 https://termux.net stable/main arm dpkg arm 1.19.0.5 [173 kB]
Get:2 https://termux.net stable/main arm coreutils arm 8.30 [448 kB]
Get:3 https://termux.net stable/main arm debianutils arm 4.8.6 [16.2 kB]
Get:4 https://termux.net stable/main arm dpkg-dev arm 1.19.0.5 [18.1 kB]
Get:5 https://termux.net stable/main arm gettext arm 0.19.8-3 [1108 kB]
Get:6 https://termux.net stable/main arm gettext-dev arm 0.19.8-3 [41.1 kB]
Get:7 https://termux.net stable/main arm libcaca arm 0.99.beta19-2 [226 kB]
Get:8 https://termux.net stable/main arm libcaca-dev arm 0.99.beta19-2 [11.7 kB]
Get:9 https://termux.net stable/main arm libcln arm 1.3.4-3 [363 kB]
Get:10 https://termux.net stable/main arm libcln-dev arm 1.3.4-3 [48.9 kB]
Get:11 https://termux.net stable/main arm libzopfli arm 1.0.2-1 [20.9 kB]
Get:12 https://termux.net stable/main arm libzopfli-dev arm 1.0.2-1 [9352 B]
Get:13 https://termux.net stable/main arm lldb arm 6.0.1 [10.3 MB]
Get:14 https://termux.net stable/main arm lldb-dev arm 6.0.1 [443 kB]
Get:15 https://termux.net stable/main arm lzip arm 1.20-1 [38.1 kB]
Get:16 https://termux.net stable/main arm patchelf arm 0.9.0.1-1 [49.7 kB]
Get:17 https://termux.net stable/main arm zopfli arm 1.0.2-1 [73.3 kB]
Fetched 13.4 MB in 59s (227 kB/s)
(Reading database ... 50362 files and directories currently installed.)
Preparing to unpack .../archives/dpkg_1.19.0.5_arm.deb ...
Unpacking dpkg (1.19.0.5) over (1.19.0.4) ...
Setting up dpkg (1.19.0.5) ...
(Reading database ... 50362 files and directories currently installed.)
Preparing to unpack .../00-coreutils_8.30_arm.deb ...
Unpacking coreutils (8.30) over (8.29) ...
dpkg: error while cleaning up:
 rm command for cleanup subprocess was killed by signal (Segmentation fault)
Preparing to unpack .../01-debianutils_4.8.6_arm.deb ...
Unpacking debianutils (4.8.6) over (4.8.4) ...
dpkg: error while cleaning up:
 rm command for cleanup subprocess was killed by signal (Segmentation fault)
Preparing to unpack .../02-dpkg-dev_1.19.0.5_arm.deb ...
Unpacking dpkg-dev (1.19.0.5) over (1.19.0.4) ...
dpkg: error while cleaning up:
 rm command for cleanup subprocess was killed by signal (Segmentation fault)
Preparing to unpack .../03-gettext_0.19.8-3_arm.deb ...
Unpacking gettext (0.19.8-3) over (0.19.8-2) ...
dpkg: error while cleaning up:
 rm command for cleanup subprocess was killed by signal (Segmentation fault)
Preparing to unpack .../04-gettext-dev_0.19.8-3_arm.deb ...
Unpacking gettext-dev (0.19.8-3) over (0.19.8-2) ...
dpkg: error while cleaning up:
 rm command for cleanup subprocess was killed by signal (Segmentation fault)
Preparing to unpack .../05-libcaca_0.99.beta19-2_arm.deb ...
Unpacking libcaca (0.99.beta19-2) over (0.99.beta19-1) ...
dpkg: error while cleaning up:
 rm command for cleanup subprocess was killed by signal (Segmentation fault)
Preparing to unpack .../06-libcaca-dev_0.99.beta19-2_arm.deb ...
Unpacking libcaca-dev (0.99.beta19-2) over (0.99.beta19-1) ...
dpkg: error while cleaning up:
 rm command for cleanup subprocess was killed by signal (Segmentation fault)
Preparing to unpack .../07-libcln_1.3.4-3_arm.deb ...
Unpacking libcln (1.3.4-3) over (1.3.4-2) ...
dpkg: error while cleaning up:
 rm command for cleanup subprocess was killed by signal (Segmentation fault)
Preparing to unpack .../08-libcln-dev_1.3.4-3_arm.deb ...
Unpacking libcln-dev (1.3.4-3) over (1.3.4-2) ...
dpkg: error while cleaning up:
 rm command for cleanup subprocess was killed by signal (Segmentation fault)
Preparing to unpack .../09-libzopfli_1.0.2-1_arm.deb ...
Unpacking libzopfli (1.0.2-1) over (1.0.2) ...
dpkg: error while cleaning up:
 rm command for cleanup subprocess was killed by signal (Segmentation fault)
Preparing to unpack .../10-libzopfli-dev_1.0.2-1_arm.deb ...
Unpacking libzopfli-dev (1.0.2-1) over (1.0.2) ...
dpkg: error while cleaning up:
 rm command for cleanup subprocess was killed by signal (Segmentation fault)
Preparing to unpack .../11-lldb_6.0.1_arm.deb ...
Unpacking lldb (6.0.1) over (6.0.0-2) ...
dpkg: error while cleaning up:
 rm command for cleanup subprocess was killed by signal (Segmentation fault)
Preparing to unpack .../12-lldb-dev_6.0.1_arm.deb ...
Unpacking lldb-dev (6.0.1) over (6.0.0-2) ...
dpkg: error while cleaning up:
 rm command for cleanup subprocess was killed by signal (Segmentation fault)
Preparing to unpack .../13-lzip_1.20-1_arm.deb ...
Unpacking lzip (1.20-1) over (1.20) ...
dpkg: error while cleaning up:
 rm command for cleanup subprocess was killed by signal (Segmentation fault)
Preparing to unpack .../14-patchelf_0.9.0.1-1_arm.deb ...
Unpacking patchelf (0.9.0.1-1) over (0.9.0.1) ...
dpkg: error while cleaning up:
 rm command for cleanup subprocess was killed by signal (Segmentation fault)
Preparing to unpack .../15-zopfli_1.0.2-1_arm.deb ...
Unpacking zopfli (1.0.2-1) over (1.0.2) ...
dpkg: error while cleaning up:
 rm command for cleanup subprocess was killed by signal (Segmentation fault)
Setting up patchelf (0.9.0.1-1) ...
Setting up debianutils (4.8.6) ...
Setting up gettext (0.19.8-3) ...
Setting up lzip (1.20-1) ...
Setting up lldb (6.0.1) ...
Processing triggers for man (1.14.3-1) ...
Setting up coreutils (8.30) ...
Setting up libzopfli (1.0.2-1) ...
Setting up dpkg-dev (1.19.0.5) ...
Setting up libcln (1.3.4-3) ...
Setting up libcln-dev (1.3.4-3) ...
Setting up lldb-dev (6.0.1) ...
Setting up libcaca (0.99.beta19-2) ...
Setting up zopfli (1.0.2-1) ...
Setting up gettext-dev (0.19.8-3) ...
Setting up libzopfli-dev (1.0.2-1) ...
Setting up libcaca-dev (0.99.beta19-2) ...
$ 

Ahhhh, yes. The venerable «Catch-22» situation of Debian package management. It boils down to Debian depending on py3compile as part of the libpython3.x package when that package provides the py3compile as well; it’s a no-go, there.

I too was bitten by this unable to get py3compile working again for I had too deleted the entire /usr/[/local]/lib/python3* directories.

Once done, nothing in Debian package management tool can help you get back to a working Python3 environment. You must do meat-ball surgery.

Reconstruction of Python3 in Debian entails three critical things:

• Restoring py3compile script (for most of you, you already have this)
• Restoring libpython3.7
• Restoring python binary

One could do the RE-copying of /usr[/local]/lib directory from another working Debian host/system. But this time, I shall detail the steps from within the broken host in question (as if you do NOT have another working host).

Step 1 — Download Packages

Download the impacted Debian packages:

cd /tmp
apt-get download libpython3.7-minimal
apt-get download python3.7-minimal
apt-get download python3-minimal # (this is important)
apt-get download libpython3.7-stdlib
apt-get download python3.7

Step 2 — Cleanup

Clean up old stuff

rm -rf /usr[/local]/lib/python3.7*
rm -rf /usr[/local]/bin/python3.7*
update-alternatives --remove python3 /usr[/local]/bin/python3.7
hash -r  # removes cached python3 binary path

Step 3 — Extract files from packages

Let us extract the missing py3compile

cd /tmp
dpkg-deb -x python3-minimal_3.7.3-1_amd64.deb missing
dpkg-deb -x python3.7-minimal_3.7.3-2_amd64.deb missing
dpkg-deb -x libpython3.7-minimal_3.7.3-2_amd64.deb missing
dpkg-deb -x libpython3.7-stdlib_3.7.3-2_amd64.deb missing
dpkg-deb -x python3.7_3.7.3-2_amd64.deb missing

Step 3

Manually install over your root filesystem

cd /tmp/missing
ls -lR /tmp/missing  # if you are curious about overwriting your HD
sudo cp -rpfv /tmp/missing/*  /

Step 4 — Verification

Start up Python3

python3
Python 3.7.3 (default, Apr  3 2019, 05:39:12) 
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>

Test import and show version

>>> import sys
>>> print(sys.version_info)
sys.version_info(major=3, minor=7, micro=3, releaselevel='final', serial=0)
>>>
>>> quit()

Step 5 — Clean up ourselves

rm -rf /tmp/missing

Step 6 — Officially reinstall Python via Debian APT

dpkg -s -a  | grep  reinstreq
# Any listing also needs to be reinstalled along with python3
apt-get install --reinstall python3

Most likely, you got MANY packages that are in that stuck state of «reinstreq» state.

apt-get autoclean
apt-get autoremove
# (MANY PACKAGES FAILED TO BE INSTALLED)

At this point, you will have to manually reinstall each and every one of those listed by apt-get autoremove…

apt-get install --fix-broken --reinstall <list-of-many-failed-packages>

Last Step — Reinstalling impacted half-state Debian packages

Let me guess, you got the following error:

E: Internal Error, No file name for XXXXXX

I will tell you that you probably had a newer Debian release in your /etc/apt/sources.list for awhile, it went all down south (bad), and took that newer release out of the sources.list file (in effort to revert back to a ‘stable’ release): that’s not an unrecoverable thing to me here, just that you jerked the Debian package database around a bit there … rather brusquely.

The resolution of the last step entails a restoration and stabilization of the Debian package management database by reinstalling nearly everything. I will detail it later but the link to follow is given here.

I have been trying to remove MySQL from my node, but it fails removal. I have tried remove, purge, dpkg —force-all, to no effect. Suggestions?

dpkg --purge --force-all mysql-server-8.0

dpkg: warning: overriding problem because --force enabled:
dpkg: warning: package is in a very bad inconsistent state; you should
 reinstall it before attempting a removal
(Reading database ... 281877 files and directories currently installed.)
Removing mysql-server-8.0 (8.0.22-0ubuntu0.20.04.3) ...
Failed to stop mysql.service: Unit mysql.service not loaded.
invoke-rc.d: initscript mysql, action "stop" failed.
dpkg: error processing package mysql-server-8.0 (--purge):
 installed mysql-server-8.0 package pre-removal script subprocess returned error exit status 1
Failed to stop mysql.service: Unit mysql.service not loaded.
invoke-rc.d: initscript mysql, action "stop" failed.
Failed to start mysql.service: Unit mysql.service not found.
invoke-rc.d: initscript mysql, action "start" failed.
Unit mysql.service could not be found.
dpkg: error while cleaning up:
 installed mysql-server-8.0 package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 mysql-server-8.0

dpkg --install /var/cache/apt/archives/mysql-server-8.0_8.0.23-0ubuntu0.20.04.1_amd64.deb

Selecting previously unselected package mysql-server-8.0.
(Reading database ... 281878 files and directories currently installed.)
Preparing to unpack .../mysql-server-8.0_8.0.23-0ubuntu0.20.04.1_amd64.deb ...
Failed to stop mysql.service: Unit mysql.service not loaded.
invoke-rc.d: initscript mysql, action "stop" failed.
dpkg: warning: old mysql-server-8.0 package pre-removal script subprocess returned error exit status 1
dpkg: trying script from the new package instead ...
Failed to stop mysql.service: Unit mysql.service not loaded.
invoke-rc.d: initscript mysql, action "stop" failed.
dpkg: error processing archive /var/cache/apt/archives/mysql-server-8.0_8.0.23-0ubuntu0.20.04.1_amd64.deb (--install):
 new mysql-server-8.0 package pre-removal script subprocess returned error exit status 1
Failed to stop mysql.service: Unit mysql.service not loaded.
invoke-rc.d: initscript mysql, action "stop" failed.
Failed to start mysql.service: Unit mysql.service not found.
invoke-rc.d: initscript mysql, action "start" failed.
Unit mysql.service could not be found.
dpkg: error while cleaning up:
 installed mysql-server-8.0 package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 /var/cache/apt/archives/mysql-server-8.0_8.0.23-0ubuntu0.20.04.1_amd64.deb

apt install --reinstall mysql-server-8.0
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Suggested packages:
  mailx tinyca
The following packages will be upgraded:
  mysql-server-8.0
1 upgraded, 0 newly installed, 0 to remove and 53 not upgraded.
1 not fully installed or removed.
Need to get 0 B/1,275 kB of archives.
After this operation, 14.3 kB of additional disk space will be used.
Preconfiguring packages ...
(Reading database ... 281878 files and directories currently installed.)
Preparing to unpack .../mysql-server-8.0_8.0.23-0ubuntu0.20.04.1_amd64.deb ...
Failed to stop mysql.service: Unit mysql.service not loaded.
invoke-rc.d: initscript mysql, action "stop" failed.
dpkg: warning: old mysql-server-8.0 package pre-removal script subprocess returned error exit status 1
dpkg: trying script from the new package instead ...
Failed to stop mysql.service: Unit mysql.service not loaded.
invoke-rc.d: initscript mysql, action "stop" failed.
dpkg: error processing archive /var/cache/apt/archives/mysql-server-8.0_8.0.23-0ubuntu0.20.04.1_amd64.deb (--un
pack):
 new mysql-server-8.0 package pre-removal script subprocess returned error exit status 1
Failed to stop mysql.service: Unit mysql.service not loaded.
invoke-rc.d: initscript mysql, action "stop" failed.
Failed to start mysql.service: Unit mysql.service not found.
invoke-rc.d: initscript mysql, action "start" failed.
Unit mysql.service could not be found.
dpkg: error while cleaning up:
 installed mysql-server-8.0 package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 /var/cache/apt/archives/mysql-server-8.0_8.0.23-0ubuntu0.20.04.1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Failed command list:

All of the following failed, same error as above:

dpkg --purge --force-all mysql-server-8.0

dpkg --install mysql-server-8.0

dpkg --install /var/cache/apt/archives/mysql-server-8.0_8.0.23-0ubuntu0.20.04.1_amd64.deb

dpkg --remove --force-all mysql-server-8.0

dpkg --configure -a

dpkg --purge --force-all mysql-server-8.0

apt install --reinstall mysql-server-8.0

Че, dpkg до сих пор болеет?

В очередной раз после ребута заглючила Малина. На этот раз что-то с Питоном, который нужен для моих задач.

Что ни пробовал, получаю одну и ту же хрень:

Да насрать мне что у меня с Питоном. Я просто хочу его удалить используя стандартный пакетный менеджер операционной системы. Вызывать питон чтобы удалить питон могут додуматься только дебилыановцы

Пост — не о том, что мне делать. Разбираться влом, завтра просто накачу образ с нуля. Пост — удивление тому, что Дебиан до сих пор болеет детскими болезнями класса «не могу удалить глючную программу потому что она глючит».

Да насрать мне что у меня с Питоном

Использовать в этом случае что-то сложнее apt-get, который тольо попу не подтирает пользователю, который поломал зависимости, тогда странно

# rm /var/lib/dpkg/info/python3.*
# dpkg —configure -a

для малины арч есть

Я разве писал за apt? Он тут ни при чем. И да,

Это обычный дроч там, где его не должно быть.

В этом и есть твоя проблема. Не ограничиваясь питоном

Я просто хочу его удалить используя стандартный пакетный менеджер операционной системы

Вызывать питон чтобы удалить питон могут додуматься только дебилыановцы

Стандартный пакетный менеджер операционной системы, кстати, написан на … python. Я вот не уверен, какая именно версия питона в raspberry pi является системной — 2 или 3. Но удалять не разобравшись — отличная идея, да 😉

Разбираться влом, завтра просто накачу образ с нуля

windows way, он никогда не меняется

Завтра вообще окажется, что у тебя флешка в малине дохнет

Ну и как уже сказали, в dpkg можно тупо удалить prerm script проблемного пакета

rm /var/lib/dpkg/info/python3.*

Вот это опасно, ИМХО. Я бы в конкретный скрипт (например, prerm) добавил в начало exit 0

Стандартный пакетный менеджер операционной системы, кстати, написан на … python.

Нет. Си и немного перла.

Из дебиана питон вполне себе удачно выпиливается обычно. Интереса ради я держал вполне рабочий сервер с почтой, биндом и файлопомойкой совершенно без питона. Единственный пакет, который пришлось ставить в /usr/local/bin/ в обход dpkg — iotop, написанный на сях, найденный на гитхабе(тот.ю что в репах — на питоне).

Васшета ты не можеш удалить пайтон из системы, его малый кусок в любом случае останется. Обусловленно оно тем фактом что часть критических системных компонентов написаны на пайтон3. Точнее технически можешь, но тогда пол-системы по депсам снесет.

Завтра вообще окажется, что у тебя флешка в малине дохнет

Тоже про это подумал

Всё правильно. И перезагрузись два раза. Как завещал Билли.

Васшета ты не можеш удалить пайтон из системы

Ты лог-то прочитал ? Проблема не в том, что я не могу удалить пайтон из системы, а в том что при удалении пайтон запускает пайтон.

Завтра вообще окажется, что у тебя флешка в малине дохнет

Допустим. Только каким боком это к удалению программы, которая не удаляется, потому что пытается запуститься ?

Вопрос не к программе, и не к причине почему она перестала запускаться, а к ТУПОМУ МЕНЕДЖЕРУ, который в нормальных ОС (и дистрах) удаляет программу своими средствами, а не средствами этой программы.

Если ты не понял в чем суть, то вот краткий пересказ дебиановского бреда:

Вот так это примерно выглядит в моем случае, и отсюда логичный вопрос: какое дело пакетный_менеджер че там в конфиге programname ?

Стандартный пакетный менеджер операционной системы, кстати, написан на … python

Во-первых, пофигу на чем он написан. Во-вторых, удаляю я третьепитон. В-третьих, если я удаляю зависимость — пакетный менеджер предлагает мне удалить пол-системы. Или dpkg и это ниасилил ?

windows way, он никогда не меняется

Ну и как уже сказали, в dpkg можно тупо удалить prerm script проблемного пакета

Возможно. Но мне надо думать над идеей, а не задрачиваться на ключи каждой программы. От пакетного менеджера требуется две задачи: устанавливать и удалять. Если же мне понадобится дроч с флагами, я поставлю генту.

ИМХО у тебя в /usr/local/lib/python* косой мудуль затесался который крешится. Ну и надо смотреть, т.к. если запускается pre-remove скрипт, то оно вполне нормально и ничего ненормального в таком нет.

Ну это понятно, что модуль который крашится.

Не понятно, почему это влияет на пакетный менеджер. Только что сэмитировал подобное на Арче на десктопе. Нормально удалилось, несмотря на то что ручками написал белиберду в код.

Мне всегда казалось что задача пакетного менеджера условно говоря пробежаться rm -rf /path/to/program, ну и че нибудь типа sed ‘/programname/d’ programdatabase.db. Бредовато звучит, что я не могу удалить неработающую программу, а вместо этого приходится разбираться почему она не работает, и заставлять ее работать чтобы удалить 🙂

Есть такое понятие как pre и post скрипты, если ты удалишь пакет у которого эти шаги удаления сломаны то очевидно оставишь систему в не консистентном состоянии, о чём тебе пакетный менеджер и пишет.

В котором, a) нет пакета python-smbus; b) сегфолтится gcc:

1. Образ установленный по рачвики;

2. Сегфолтится на сборке ЛЮБОГО пакета;

3. Этот же самый пакет собирается норм на соседнем x86_64.

Ты сам-то пробовал то, что советуешь ?

Проблема в том что dpkg НИЧЕГО не ставит в /usr/local
По дебостандартам префикс всегда /usr (но не /usr/local)
А вот когда «специалисты» вместо того что бы поставить пакет (какой нить python3-feature) ставят его от рута через pip(ну скопипастил же команду бездумно из гайда в нете), то такой пакет как раз попадает в /usr/local, и в большинстве случаев он и используется, но не всегда 🙂 Вот тут-то вот и начинаются веселухи.

Через pip ничего не ставилось, префикс стандартный, python3 не удаляется.

Веселуха в том, что пакетному менеджеру должно быть плевать, как себя ведет программа которую он удаляет.

у меня работало и yay собрался

Веселуха в том, что пакетному менеджеру должно быть плевать, как себя ведет программа которую он удаляет.

Ну ет твоя хотелка. А жисть она другая, и в ней существуют хуки. И хуки имеют свойство выполнятся в соответствующих моментах, в даном случае pre-removal. А то что он сфелился судя из лога результат того что консистентность системы была искуственно нарушена (соответствующий пакет грохнули напрямую через dpkg с игнорированием rdepends или наоборот, установлен без необходимых)

у меня работало и yay собрался

Сисадмин, вы же не попали ни разу в мишень!

Не знаю товарищ подполковник, с моего автомата все пули вылетели, проблема на стороне мишени.

просто у тебя админская мана не прокачена до 80 левла, так бы посмотрел сурово — и малина сама всё сделала

Проблема не в том, что я не могу удалить пайтон из системы, а в том что при удалении пайтон запускает пайтон.

Не совсем понял вашу мысль. Ну запускает, что такого? Или он в процессе работы какие-то либы пытается подгрузить которые уже удалены?

Не совсем понял вашу мысль. Ну запускает, что такого? Или он в процессе работы какие-то либы пытается подгрузить которые уже удалены?

Мне просто интересно, почему дебианщики считают нормальным, что средствами операционной системы невозможно удалить глючную программу. Ну потому что для других дистров, да и для оффтопика это кагбе не совсем нормально.

Всё равно не понял какое отношение это имеет к пистону.

Всё равно не понял какое отношение это имеет к пистону.

А, тут все просто.

Debian. Поставил пистон3 для кое-какого проекта с использованием ADC на i2c. Потом в этом пистоне3 шото заглючило, при попытке вызвать ЛЮБОЙ пистоновский файл — оно сегфолтилось. Пофиг по какой причине, важно что все другое, включая скрипты на ненавистном пыхе — работает. Ну думаю ладно, быстрее всего будет его переустановить.

Но нет, не удаляется.

А не удаляется, потому что сраный dpkg, удаляя питон, зачем-то его вызывает, но поскольку он сегфолтится с вскукареком «Fatal Python error: initfsencoding: Unable to get the locale encoding» — то dpkg его не удаляет. Вот меня это и удивило, потому что ситуация что какая-то установленная программа не работает — вполне штатная. Странно вообще запускать удаляемую программу для ее удаления, но даже хрен с ним, если запустил — то нафига ж останавливать удаление программы, если программа вылетела с ошибкой.

С этой фигней (ну почти с этой) я сталкивался еще 10 лет назад, думал с тех пор починили. Но нет, дебиан же стабильный, гы. Сымитировал эту ситуацию на Арче — pacman все нормально удалил.

Я этих легенд про выпиливание Python’а и Perl’а ещё в середине 2000-х наслушался, но уже тогда, по факту, было нельзя. Много софта так или иначе юзает Python и Perl и выпиливание их из системы ни к чему хорошему не приводит. Про это надо забыть.

Да и чем может помешать Python? Места на диске жалко? Может быть, тогда пришло время его проапгрейдить?

А, понял. Спасибо за пояснение. Вот бы не подумал что они в dpkg его завезли. Очень-очень странное решение. Там и кода-то не мульон и маленькая тележка, зачем пистон тянуть было? Или индусоэффект?
Я подозревал за apt, aptitude.

Много софта так или иначе юзает Python и Perl и выпиливание их из системы

Нет. Речь о третьем питоне. Его я установил сам. Больше в системе ничего его не использовало, десктопы я не ставил.

Да и чем может помешать Python?

Поставил пистон3 для кое-какого проекта с использованием ADC на i2c

Может быть, тогда пришло время его проапгрейдить?

О чем и пост. Если ты поставил питон3, и поломал один из его модулей — ты не можешь ни снести его ни переустановить. Стандартными средствами.

Пост не о том, «как починить питон3», или «как исправить ситуацию», а о том что dpkg не умеет удалять питон3, если сам питон3 сегфолтится.

А, понял. Спасибо за пояснение. Вот бы не подумал что они в dpkg его завезли. Очень-очень странное решение. Там и кода-то не мульон и маленькая тележка, зачем пистон тянуть было? Или индусоэффект? Я подозревал за apt, aptitude.

Не. Питон3 — это отдельная программа, которую я поставил обычным apt install python3 python3-pip python3-smbus etc. Но apt вроде только скачивает и зависимости разруливает, а ставит dpkg. Соответственно когда делаешь apt remove python3 — тоже вызывается dpkg. Этот сраный dpkg вызывает какой-то хук или пре-remove скрипт, и если скрипт вылетает — то вылетает ВЕСЬ ПРОЦЕСС УДАЛЕНИЯ, что разумеется есть идиотизм, ведь мало ли по какой причине у меня перестала запускаться софтина. Может ОЗУ ей мало, или я прибил конфиг и не сделал бэкап. Туповато. Но я думал что за десятилетие эту багу пофиксили.

Источник

«E: Sub-process /usr/bin/dpkg returned an error code (1) » What does this mean?

I’ve seen this message several times whenever someone has a problem installing, upgrading or removing some piece of software, but I wonder, what does it mean, and more importantly, is possible to solve it?

(the above is just an example, not my actual problem)

1 Answer 1

That message is generic. It just means that the dpkg instance called by apt / apt-get failed for some reason. It doesn’t explain why, how, or give hints how to solve it. As a diagnostic message, it is not useful.

You need to read the lines before the message (sometimes quite a number of them) to find the real error that prevents you from completing the installation.

Yeah, but how do I solve it?

There is no single way to solve it. There are so many reasons why this can happen that it’s futile to attempt to list them all in a single post. Each and every circumstance is almost unique to that package/environment.

But, there’s redemption. The fact that you see this message means that probably there is more relevant information in the lines before the message. For illustrative purposes I will use a example:

Now, to find the problem, you need to read backwards:

E: Sub-process /usr/bin/dpkg returned an error code (1) doesn’t tell me anything useful. So moving on.

Errors were encountered while processing: mongodb-10gen just tells me what package have problems. Is useful but not enough.

subprocess installed post-installation script returned error exit status 100 : this tells me that the script that failed was the postinst , the one executed in post-installation. This will come handy in some situations, but not in this one.

dpkg: error while cleaning up: nothing useful here.

invoke-rc.d: unknown initscript, /etc/init.d/mongodb not found. BINGO! This tells us that invoke-rc.d , a binary that controls the init script in most Debian-like system, failed. It failed because it couldn’t find the /etc/init.d/mongodb script. This is bad. We need to create it or copy from somewhere else so it starts working again. Reinstalling the package is also normally an option for file not found errors.

In this case, reporting a bug is not necessary because is probable that we were the ones that removed the script, but if you are completely sure you didn’t touch the file (a debsums -sla should confirm it) then report a bug.

So, what exactly do you need to get help? Ideally, the complete output of the problem. It’s also helpful to include the output of sudo dpkg -C and sudo apt-get check , and the output of apt-cache policy package1 package2. where «package1 package2 . » includes all the packages with problems.

Источник

That message is generic. It just means that the dpkg instance called by apt/apt-get failed for some reason. It doesn’t explain why, how, or give hints how to solve it. As a diagnostic message, it is not useful.

You need to read the lines before the message (sometimes quite a number of them) to find the real error that prevents you from completing the installation.

Yeah, but how do I solve it?

There is no single way to solve it. There are so many reasons why this can happen that it’s futile to attempt to list them all in a single post. Each and every circumstance is almost unique to that package/environment.

But, there’s redemption. The fact that you see this message means that probably there is more relevant information in the lines before the message. For illustrative purposes I will use a example:

(Reading database ... 81657 files and directories currently installed.)
 Removing mongodb-10gen ...
 arg: remove
 invoke-rc.d: unknown initscript, /etc/init.d/mongodb not found.
 dpkg: error processing mongodb-10gen (--remove):
  subprocess installed pre-removal script returned error exit status 100
 invoke-rc.d: unknown initscript, /etc/init.d/mongodb not found.
 dpkg: error while cleaning up:
  subprocess installed post-installation script returned error exit status 100
 Errors were encountered while processing:
  mongodb-10gen
 E: Sub-process /usr/bin/dpkg returned an error code (1)

Now, to find the problem, you need to read backwards:

• E: Sub-process /usr/bin/dpkg returned an error code (1) doesn’t tell me anything useful. So moving on.

• Errors were encountered while processing: mongodb-10gen just tells me what package have problems. Is useful but not enough.

• subprocess installed post-installation script returned error exit status 100: this tells me that the script that failed was the postinst, the one executed in post-installation. This will come handy in some situations, but not in this one.

• dpkg: error while cleaning up: nothing useful here.

• invoke-rc.d: unknown initscript, /etc/init.d/mongodb not found. BINGO! This tells us that invoke-rc.d, a binary that controls the init script in most Debian-like system, failed. It failed because it couldn’t find the /etc/init.d/mongodb script. This is bad. We need to create it or copy from somewhere else so it starts working again. Reinstalling the package is also normally an option for file not found errors.

  In this case, reporting a bug is not necessary because is probable that we were the ones that removed the script, but if you are completely sure you didn’t touch the file (a debsums -sla should confirm it) then report a bug.

So, what exactly do you need to get help? Ideally, the complete output of the problem. It’s also helpful to include the output of sudo dpkg -C and sudo apt-get check, and the output of apt-cache policy package1 package2... where «package1 package2 …» includes all the packages with problems.

0

1

root@pi:/# apt purge python3
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages were automatically installed and are no longer required:
  libmpdec2 libpython3-stdlib libpython3.7-minimal libpython3.7-stdlib python-pip-whl python3-minimal python3.7 python3.7-minimal
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
  dh-python* python3* python3-distutils* python3-lib2to3* python3-pip* python3-pkg-resources* python3-setuptools*
0 upgraded, 0 newly installed, 7 to remove and 37 not upgraded.
9 not fully installed or removed.
After this operation, 4,346 kB disk space will be freed.
Do you want to continue? [Y/n] y
Segmentation fault
(Reading database ... 30574 files and directories currently installed.)
Removing dh-python (3.20190308) ...
Fatal Python error: initfsencoding: Unable to get the locale encoding
ModuleNotFoundError: No module named 'encodings'

Current thread 0x76f64ad0 (most recent call first):
Aborted
dpkg: error processing package dh-python (--remove):
 installed dh-python package pre-removal script subprocess returned error exit status 134
Fatal Python error: initfsencoding: Unable to get the locale encoding
ModuleNotFoundError: No module named 'encodings'

Current thread 0x76f6aad0 (most recent call first):
Aborted
dpkg: error while cleaning up:
 installed dh-python package post-installation script subprocess returned error exit status 134
Removing python3-pip (18.1-5+rpt1) ...
Fatal Python error: initfsencoding: Unable to get the locale encoding
ModuleNotFoundError: No module named 'encodings'

Current thread 0x76fcaad0 (most recent call first):
Aborted
dpkg: error processing package python3-pip (--remove):
 installed python3-pip package pre-removal script subprocess returned error exit status 134
Removing python3-setuptools (40.8.0-1) ...
Fatal Python error: initfsencoding: Unable to get the locale encoding
ModuleNotFoundError: No module named 'encodings'

Current thread 0x76fdfad0 (most recent call first):
Aborted
dpkg: error processing package python3-setuptools (--remove):
 installed python3-setuptools package pre-removal script subprocess returned error exit status 134
dpkg: python3-distutils: dependency problems, but removing anyway as you requested:
 python3-setuptools depends on python3-distutils; however:
  Package python3-distutils is to be removed.
 python3-pip depends on python3-distutils.
 dh-python depends on python3-distutils | python3 (<< 3.6.5~rc1-1); however:
  Package python3-distutils is to be removed.
  Version of python3 on system is 3.7.3-1.

Removing python3-distutils (3.7.3-1) ...
Removing python3-lib2to3 (3.7.3-1) ...
dpkg: python3-pkg-resources: dependency problems, but removing anyway as you requested:
 python3-setuptools depends on python3-pkg-resources (= 40.8.0-1).

Removing python3-pkg-resources (40.8.0-1) ...
Fatal Python error: initfsencoding: Unable to get the locale encoding
ModuleNotFoundError: No module named 'encodings'

Current thread 0x76f03ad0 (most recent call first):
Aborted
dpkg: error processing package python3-pkg-resources (--remove):
 installed python3-pkg-resources package pre-removal script subprocess returned error exit status 134
dpkg: python3: dependency problems, but removing anyway as you requested:
 python3-setuptools depends on python3:any; however:
  Package python3 is to be removed.
 python3-pkg-resources depends on python3:any.
 python3-pip depends on python3:any; however:
  Package python3 is to be removed.
 dh-python depends on python3:any.
 dh-python depends on python3-distutils | python3 (<< 3.6.5~rc1-1); however:
  Package python3-distutils is not installed.
  Package python3 is to be removed.
 dh-python depends on python3:any.
 dh-python depends on python3-distutils | python3 (<< 3.6.5~rc1-1); however:
  Package python3-distutils is not installed.
  Package python3 is to be removed.

Removing python3 (3.7.3-1) ...
Fatal Python error: initfsencoding: Unable to get the locale encoding
ModuleNotFoundError: No module named 'encodings'

Current thread 0x76f92ad0 (most recent call first):
Aborted
dpkg: error processing package python3 (--remove):
 installed python3 package pre-removal script subprocess returned error exit status 134
Errors were encountered while processing:
 dh-python
 python3-pip
 python3-setuptools
 python3-pkg-resources
 python3
E: Sub-process /usr/bin/dpkg returned an error code (1)
root@pi:/# 

For the past week or two, every time I installed new software into Ubuntu, I was greeted with the “Errors were encountered while processing:” blah, blah, blah speech.

Up until yesterday, that error was just a battle scar my computer had earned attempting to install a few software packages. I didn’t need them, my computer wasn’t bothered by them not being fully installed so after trying to fix them many times I thought f#ck it! No real problem. But yesterday, when a few more packages failed to install, and this time they stopped my computer from updating itself and prevented me from using Synaptic, I decided enough is enough, I’m going to fix it once and for all. So, I tooled up, got out my best keyboard, readied my fastest mouse, donned my Linux badges and set out on my quest to kill the Big Bad Bug, save the princess and live happily ever after…. sorry, got a little carried away there.

Today, I completed my quest – I squished that bug and watched his juices spit all over my computer’s insides as it made that squelchy noise only squished bugs know how to make so well.

The next time you find you cannot add software into your Ubuntu distro because you’re getting errors that look like or totally unlike this one:

Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 38 not upgraded.
4 not fully installed or removed.
Need to get 0B/590kB of archives.
After this operation, 0B of additional disk space will be used.
WARNING: The following packages cannot be authenticated!
python-distutils-extra scons
Authentication warning overridden.
Selecting previously deselected package python-distutils-extra.
(Reading database ... 458474 files and directories currently installed.)
Preparing to replace python-distutils-extra 2.12 (using .../python-distutils-extra_2.12_all.deb) ...
dpkg (subprocess): unable to execute old pre-removal script: Exec format error
dpkg: warning: old pre-removal script returned error exit status 2
dpkg - trying script from the new package instead ...
Traceback (most recent call last):
File "/usr/bin/pycentral", line 2196, in <module>
main()
File "/usr/bin/pycentral", line 2190, in main
rv = action.run(global_options)
File "/usr/bin/pycentral", line 1645, in run
pkg = DebPackage('package', self.args[0], oldstyle=False)
File "/usr/bin/pycentral", line 381, in __init__
self.read_pyfiles()
File "/usr/bin/pycentral", line 414, in read_pyfiles
self.pkgconfig.set('pycentral', 'include-links', '0')
File "/usr/lib/python2.6/ConfigParser.py", line 669, in set
ConfigParser.set(self, section, option, value)
File "/usr/lib/python2.6/ConfigParser.py", line 377, in set
raise NoSectionError(section)
ConfigParser.NoSectionError: No section: 'pycentral'
dpkg: error processing /var/cache/apt/archives/python-distutils-extra_2.12_all.deb (--unpack):
subprocess new pre-removal script returned error exit status 1
dpkg (subprocess): unable to execute installed post-installation script: Exec format error
dpkg: error while cleaning up:
subprocess installed post-installation script returned error exit status 2
Preparing to replace scons 1.2.0-2ubuntu1 (using .../scons_1.2.0-2ubuntu1_all.deb) ...
dpkg (subprocess): unable to execute old pre-removal script: Exec format error
dpkg: warning: old pre-removal script returned error exit status 2
dpkg - trying script from the new package instead ...
Traceback (most recent call last):
File "/usr/bin/pycentral", line 2196, in <module>
main()
File "/usr/bin/pycentral", line 2190, in main
rv = action.run(global_options)
File "/usr/bin/pycentral", line 1645, in run
pkg = DebPackage('package', self.args[0], oldstyle=False)
File "/usr/bin/pycentral", line 381, in __init__
self.read_pyfiles()
File "/usr/bin/pycentral", line 414, in read_pyfiles
self.pkgconfig.set('pycentral', 'include-links', '0')
File "/usr/lib/python2.6/ConfigParser.py", line 669, in set
ConfigParser.set(self, section, option, value)
File "/usr/lib/python2.6/ConfigParser.py", line 377, in set
raise NoSectionError(section)
ConfigParser.NoSectionError: No section: 'pycentral'
dpkg: error processing /var/cache/apt/archives/scons_1.2.0-2ubuntu1_all.deb (--unpack):
subprocess new pre-removal script returned error exit status 1
dpkg (subprocess): unable to execute installed post-installation script: Exec format error
dpkg: error while cleaning up:
subprocess installed post-installation script returned error exit status 2
Errors were encountered while processing:
/var/cache/apt/archives/python-distutils-extra_2.12_all.deb
/var/cache/apt/archives/scons_1.2.0-2ubuntu1_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Use these steps to fix them:

Firstly, make a note of the applications that refuse to install then try one or more of the usual hit-n-stab gambits before pulling out your longsword and making more extensive blood letting cuts into your system:

1. ensure that the shared libraries are properly registered (also fixes some GCC/G++ errors)

sudo ldconfig

1. try to remove the package (replace ‘your-app’ with the name of the dodgy application)

sudo dpkg -r YOUR-APP

1. check your package cache

sudo apt-get check

1. update your package list

sudo apt-get update

1. ensure package downloads were properly completed when the system last updated

sudo apt-get upgrade --fix-missing

1. try to upgrade the system (sometimes an updated package version fixes the issue)

sudo apt-get upgrade
sudo apt-get dist-upgrade

1. try to reconfigure all applications that failed to install

sudo dpkg --configure -a

1. try to reconfigure specific applications that failed to install

sudo dpkg --configure YOUR-APP

1. try to fix broken packages

sudo apt-get install -f

1. try to fix a specific broken package

sudo apt-get install YOUR-APP -f

1. try to install the dependencies that an application requires for it to install successfully

sudo apt-get build-dep YOUR-APP

1. re-try to install the failed apps

sudo apt-get install

If none of the above fix it, try this:

1. Go to the website that maintains the failed package. In most cases, this will be Launchpad.net (for Ubuntu flavors, go here); users of Debian distros (inc. Ubuntu) can download source code packages from Debian.org and a lot of packages for all distros are maintained through Gna. If you’re really stuck, Google it;
2. Search for the failed package then re-download it and re-install it. First try the deb package that is pre-built for your OS version then, if that doesn’t work, download the source code and build it from scratch;
   1. Most packages ship with installation instructions written in a Readme or Installation file (it’s important to read them). Most build with either

   ./configure
   make
   make install

   1. else

   python setup.py install

   1. Ensure any shared libraries are properly registered

   sudo ldconfig

If you struggle to install the downloaded source code you can read this Linux Software Installation EasyGuide. The downside to installing from source code (i.e not through Apt, Aptitude, Yum or dpkg) is that your regular package manager will not know that the software has been installed. Just re-install it through your regular package manager once it is functioning properly.

If you are still battling away after trying the above then you have no choice but to bring out your longsword and start swinging at dpkg’s bowels:

1. backup your dpkg status file with

sudo cp /var/lib/dpkg/status status.bckup

1. just for reference, if you need to restore the backup version of the status file, type

sudo mv status.bckup > /var/lib/dpkg/status

1. edit your dpkg status file
   1. KDE Users

   kdesudo kate /var/lib/dpkg/status

   1. Gnome users

   gksu gedit /var/lib/dpkg/status

2. search for the problem package(s) by name (press Ctrl+F),
3. edit the line that reads

Status: install reinstreq half-configured

to replace it with

Status: install ok installed

and save it,

1. then either uninstall the package(s) then/or re-install it(them) with either

sudo apt-get remove YOUR-APP

1. else

sudo apt-get install YOUR-APP

1. If the problem persists, re-edit /var/lib/dpkg/status but this time search for the failed package by name and delete its details from

   Package....

   to

   Description....

   Delete from the open line above package to the open line below its description that leads on to the next package’s details. Here is an example of the complete package listing for ‘lsb-core’:

   Package: lsb-core
   Status: install ok installed
   Priority: extra
   Section: misc
   Installed-Size: 196
   Maintainer: Ubuntu Core Developers <[email protected]>
   Architecture: amd64
   Source: lsb
   Version: 4.0-0ubuntu5
   Replaces: lsb (<< 2.0-2)
   Provides: lsb-core-amd64, lsb-core-noarch
   Depends: lsb-release, libc6 (>> 2.3.5), libz1, libncurses5, libpam0g, postfix | mail-transport-agent, at, bc, binutils, bsdmainutils, bsdutils, cpio, cron, ed, file, libc6-dev | libc-dev, locales, cups-bsd | lpr, lprng | cups-client, m4, mailx | mailutils, make, man-db, mawk | gawk, ncurses-term, passwd, patch, pax, procps, psmisc, rsync, alien (>= 8.36), python, python-central (>= 0.6.11), debconf (>= 0.5) | debconf-2.0, libc6-i386, lib32z1, lsb-base, time
   Conflicts: lsb (<< 2.0-2)
   Description: Linux Standard Base 4.0 core support package
   The Linux Standard Base (http://www.linuxbase.org/) is a standard
   core system that third-party applications written for Linux can
   depend upon.
   .
   This package provides an implementation of the core of version 4.0 of
   the Linux Standard Base for Debian on the Intel x86, Intel ia64
   (Itanium), IBM S390, and PowerPC 32-bit architectures with the Linux
   kernel. Future revisions of the specification and this package may
   support the LSB on additional architectures and kernels.
   .
   The intent of this package is to provide a best current practice way
   of installing and running LSB packages on Debian GNU/Linux. Its
   presence does not imply that Debian fully complies
   with the Linux Standard Base, and should not be construed as a
   statement that Debian is LSB-compliant.
   Homepage: http://www.linux-foundation.org/en/LSB
   Original-Maintainer: Chris Lawrence <[email protected]>
   Python-Version: all

   That whole section would be deleted were lsb-core an issue on your system.

2. When you update your package list you will notice that those packages with their details removed from dpkg’s status file will not now show as installed by dpkg. Rest assured, those packages are still installed/semi-installed but dpkg is no longer aware of them. At this point you can choose to either ‘re-install’ the badly installed package or just leave it hanging on your system as an undetected badly installed package which you should try to re-install at a later time. I recommend you try to re-install immediately. If you leave it as an undetected package, dpkg will not automatically update it and will try to re-install it should it be a dependency of other packages that you later try to install.

If none of those steps fix it then the likelihood is that nothing will but search the net before you decide to re-install your operating system.

As a word of caution, never, ever delete your dpkg (apt) status file. If someone tells you to type

sudo rm /var/lib/dpkg/status

Ignore them or your computer will explode! You can open it up, look at it and edit it but you must never, ever delete it. It contains all the data dpkg requires to update and uninstall packages. If you delete it you will not be able to properly remove or upgrade the packages installed prior to it being removed and you might have problems when you try to install new packages into your system.

Bootnote: You can use Aptitude to “Hold” partially installed packages and packages that prevent others from being installed. Open a terminal, type “sudo aptitude”, press “Ctrl+T” then “Return”, use the arrow keys to navigate to the suspect package, press the “equals” key i.e “=” (the package to be held should now change color), press Ctrl+T then press return and any packages that are ready to install but were stuck due to the (now) held package will now install.

Visit the Software Installation EasyGuide for more installation error busters and the Ubuntu Repository List to get extra useful repositories for your system.

Здравствуйте! Почему-то при попытке установить любую программу на сервер с Debian Jessie 8.5 вываливается следующее:

root@server:~# apt-get install postfix
Reading package lists... Done
Building dependency tree       
Reading state information... Done
postfix is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 58 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] Y
Setting up mongodb-org-server (3.0.14) ...
dpkg: error processing package mongodb-org-server (--configure):
 subprocess installed post-installation script returned error exit status 102
Errors were encountered while processing:
 mongodb-org-server
E: Sub-process /usr/bin/dpkg returned an error code (1)

Удалить пакет mongodb-org-server я не могу:

root@server:~# apt-get remove mongodb-org-server
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be REMOVED:
  mongodb-org-server
0 upgraded, 0 newly installed, 1 to remove and 58 not upgraded.
1 not fully installed or removed.
After this operation, 26,6 MB disk space will be freed.
Do you want to continue? [Y/n] Y
(Reading database ... 52910 files and directories currently installed.)
Removing mongodb-org-server (3.0.14) ...
dpkg: error processing package mongodb-org-server (--remove):
 subprocess installed pre-removal script returned error exit status 102
dpkg: error while cleaning up:
 subprocess installed post-installation script returned error exit status 102
Errors were encountered while processing:
 mongodb-org-server
E: Sub-process /usr/bin/dpkg returned an error code (1)