apt-get и «Чтение списков пакетов»

можно вот это попробовать [apt][тормоза][непонятки] долго читает список пакетов (комментарий)
(более безопасный вариант: http://ubuntuforums.org/showthread.php?t=1004376&page=2&p=8982829#post8982829)

test
dpkg -S /bin/ls

annelin@somewhere ~ $ time dpkg -S /bin/ls
coreutils: /bin/ls

real	0m0.127s
user	0m0.108s
sys	0m0.016s

проблема, например, с apt-get update

пытаюсь скопировать БД apt'а из /var/lib/apt в loop-устройство
скорости меня пугают

cast megabaks
кажись та же проблема что у меня была, неправильные опции монтирования и фрагментация.

ФС - reiserfs

Сажа пердоликам.

надо было снуля использовать notail || ССЗБ
/мне уже надоедает это писать

UUID=e74b83d8-f605-48a3-b08c-292fef1ea852 /               reiserfs notail          0       1

с нуля.

а что с местом?

даже половины не занято

annelin@somewhere ~ $ df -h /
Файловая система                                       Размер Использовано  Дост Использовано% Cмонтировано в
/dev/disk/by-uuid/e74b83d8-f605-48a3-b08c-292fef1ea852    15G         4,3G   11G           29% /

Да-да, файловые системы в linux не фрагментируются. (Первые полгода).

системе месяца нету

системе месяца нету

Это был сарказм, в общем-то.

https://github.com/i-rinat/fragview
http://i.imgur.com/FtZGh.png

View → Files with highest severity

Мне кажется, что дело не в ФС. Файлы списков пакетов, наверное, стали очень большими. Попробуй удалить все файлы в /var/lib/apt/lists. А также удали кэш - /var/cache/apt. А лучше, если сомневаешься в чем-то, содержимое этих каталогов не удалить, а переместить куда-нибудь (например, в /root). Потом выполни apt-get update или aptitude update.

Для начала это сделай и расскажи, что получилось.

сделла rm -rf /var/cache/apt/ и /var/lib/apt, apt-get upgrade - стало чуть быстрее шевелиться.
у меня почему-то такое ощущение, что это из-за того, что у меня в sources все ветки указаны:)

а ежели овер sh посмотреть с учётом разных способов подсчёта?
таки т.н. sparce файлы зло

таки т.н. sparce файлы зло

Sparse файлы — добро. Они очень помогают в особых случаях и не мешают в остальных.

И du показывает занимаемое на диске место, дыры в sparse там не учитываются.

да там мало их:)

/var/lib/apt $ find . -type f | wc -l
34
/var/lib/apt $ time cat lists/* >/dev/null
cat: lists/lock: Отказано в доступе
cat: lists/partial: Это каталог

real	0m0.066s
user	0m0.000s
sys	0m0.068s
/var/lib/apt $ time apt-cache search kde

real	0m0.075s
user	0m0.020s
sys	0m0.036s

у меня почему-то такое ощущение, что это из-за того, что у меня в sources все ветки указаны:)

5-10 минут на «Чтение списков пакетов»

Очень может быть. А если еще и deb-src все указаны, то списки весьма большие получаются, но 5-10 минут - это вообще ни в какие ворота. Слишком долго. Точно 5-10 минут? Это овердофига!

Еще можно попробовать переименовать /var/lib/dpkg/available в /var/lib/dpkg/available.save, выполнить dpkg --clear-avail, а затем выполнить aptitude/apt-get update. Перегенерировать этот файл можно было, кажется, при помощи старой системы dselect (dselect update), но в документации на dpkg написано, что этот файл использует в основном только dselect, а apt свои списки ведет. Но... можно попробовать.

после rm -rf /var/lib/apt && apt-get update — чуть меньше минуты:)

rm -rf /var/lib/apt

Вот это зря! Там же лежит файл extended_states, в котором прописана информация о том, какой пакет автоматом, а какой вручную поставлен. Надо было только /var/lib/apt/lists. Ну-ка, сколько у тебя теперь осталось пакетов, установленных автоматом?

aptitude search ~M | wc -l

0, ну и ладно

0, ну и ладно

Сочуствую. :) Убил базу. Можно руками восстановить немного. Например, все пакеты раздела libs пометить установленными автоматом. Остальное глазами посомтреть при помощи морды aptitude и руками поотмечать, что, как ты думаешь, поставлено автоматом.

Убил базу

а чем это грозит, кроме того, что придётся вычищать все зависимости руками, когда удалю что-нибудь?

в sources все ветки указаны:)

Неа. Не должно быть. У меня тоже все ветки - чтение списков пакетов - секунд 10, не больше. А железо (вероятность 90%) - слабее. Дело таки в ФС.

а чем это грозит, кроме того, что придётся вычищать все зависимости руками, когда удалю что-нибудь?

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

Например, все библиотеки можно пометить автоматом:

aptitude markauto ~s^libs$~i

А остальные разделы уже руками отсмотреть. После автоматической отметки некоторые библиотеки могут, кстати, под снос пойти. Большинство из них вообще не нужны (всяки хлам после инсталляции), скорее всего, но если ты вдруг увидел среди них библиотеку, которую действительно ставил сам, то пометь ее как установленную вручную.

ага, а еще можно удалить все пакеты и заново поставить:)
я замучаюсь же по тыщам пакетов руками ходить

ага, а еще можно удалить все пакеты и заново поставить:)
я замучаюсь же по тыщам пакетов руками ходить

Библиотеки - это самая вообще массовая часть. Ее автоматом. А остального не так много, на самом деле. Я как-то один раз делал так, когда только aptitude появился. Ничего страшного, на самом деле. Даже можно красивее сделать, чем то, что было.

после rm -rf /var/lib/apt && apt-get update — чуть меньше минуты:)

А ты переместить /var/lib/dpkg/available пробовал? Чего-нибудь дало?

нет, манипуляции с dpkg вообще ничего не давали:)

я уже скопировал extended_states с другого компьютера и написал небольшой костылик

#!/bin/bash

src=./extended_states

for i in `grep -n Package $src|cut -d: -f1` ; 
do
		current_pkg="$( cat $src | sed -n ${i}p | sed 's/Package\:\ //' )"
		dpkg -l | grep -q "$current_pkg" || continue
		head -n $(($i + 3)) $src | tail -n 4 >> ./extended_states_recovered
done

Ай, я вспомнил, что он бекапится же! Посомтри в /var/backup

да ну тебя:(
спасибо большое:D

Ну, да. Только бекап может быть очень старым. Кстати, можешь глянуть в него - там lib* подавляющее большинство. Так что если у тебя в разделе libs какая-то библиотека не стоит с флагом 'A', то можно ее пометить (либо markauto, либо в морде aptitude кнопкой 'M' (Shift-M)). Чище будет.

хм, странно. бекап достаточно свежий (день), но автоудаление по-прежнему не работает:

annelin@somewhere /var/lib/apt $ sudo apt-get purge xserver-xorg
Чтение списков пакетов… Готово
Построение дерева зависимостей       
Чтение информации о состоянии… Готово
Пакеты, которые будут УДАЛЕНЫ:
  xserver-xorg*
обновлено 0, установлено 0 новых пакетов, для удаления отмечено 1 пакетов, и 45 пакетов не обновлено.
После данной операции, объём занятого дискового пространства уменьшится на 370 kB.
Хотите продолжить [Д/н]? 

да и аптитуда показывает всё верно:

annelin@somewhere /var/lib/apt $ aptitude search ~M | wc -l
879

выводит список всех автоматически установленных пакетов
но например:
# apt-get install gnome-terminal
тянет gnome-terminal-data как зависимость
$ aptitude search ~M | grep gnome-terminal
i A gnome-terminal-data - файлы данных для эмулятора терминала в GNO

-- все ок
но:
# apt-get purge-terminal
и
# aptitude purge gnome-terminal

не предлагают снести gnome-terminal-data.
apt-get update делал

А другие пакеты? Значит, у тебя xserver-xorg не имеет зависимостей. Или имеет, но все библиотеки удерживаются еще каким-то пакетом.

чуть выше читай

Ну, теперь стало ясно, что мегабаксу не стоило верить...

не предлагают снести gnome-terminal-data.

А это, похоже, старый баг, который не раз обсуждали (неужели еще не поправили?):

Aptitude превращает вашу систему в свалку

urxvt: игнор настроек при запуске ч/з x-terminal-emulator (комментарий)

Этот баг сработал с терминалами. Очень странный баг. Мы тогда выяснили,что это баг APT и всех фронтендов, которые его используют. Попробуй с другими пакетами.

да, действительно, с другими пакетами всё ок

да, действительно, с другими пакетами всё ок

Тогда надо выяснить, что с xserver-xorg. Я полагаю, что у него просто не оказалось зависимостей по какой-то причине. Или все пакеты, от которых он зависит, помечены как установленные вручную.

Что говорит

aptitude search ~Rxserver-xorg~i

Драйвера видеокарт могут удерживаться пакетом xserver-xorg-video-all, а драйвера устройств ввода xserver-xorg-input-all. Стоят эти пакеты?

нет, емнип, руками ставил xserver-xorg-video-intel и evdev с synaptic'ом

нет, емнип, руками ставил xserver-xorg-video-intel и evdev с synaptic'ом

Ну вот он и не сносит ничего, так как руками ставил, а остальные библиотеки, видимо, еще кому-то нужны. Можно же проверить. Вот список

aptitude search ~Rxserver-xorg~i

Это все библиотеки, от которых зависит xserver-xorg

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

Ты вообще можешь снести этот xserver-xorg безболезненно.

Описание: графическая система X.org
 Этот пакет приводит к установке всех пакетов и драйверов графической системы
 X.Org. Сам пакет не устанавливает никаких файлов.

Сам сервер у тебя это пакет xserver-xorg-core

Ну как, нашли решение проблемы? Абсолютно та же фигня недавно появилась на убунте 14.04... =( Очень медленно читает/обновляет базу (и apt, и aptitude), при этом пишет что-то на диск со скоростью ~2Мб/с. Все рецепты от Zubok перепробовал - не помогает...

Единственное, что ФС - ext4

само как-то решилось.
хотя сейчас SSD с ext4fs

ну, может, и у меня само вылечится... :)