Собрал Midnight Commander под ARM

В виде эксперимента собрал последнюю стабильную версию Midnight Commander (4.8.15) в своем репозитарии под ARM. В итоге получилось так:

• Debian Wheezy (i386, amd64, armel, armhf)
• Debian Jessie (i386, amd64, armel, armhf, arm64)
• Debian Stretch (i386, amd64)
• Debian Sid (i386, amd64)
• Ubuntu Precise (i386, amd64, armel, armhf)
• Ubuntu Trusty (i386, amd64, armhf, arm64)
• Ubuntu Vivid (i386, amd64)
• Ubuntu Wily (i386, amd64)

Любопытно насколько это востребовано и под какие железки.

Обратная сборка пакета tvheadend

Вчера вечером ставил обновления на домашнем сервере и не заметил обновление tvheadend. Был tvheadend 3.4.27, а обновился до 4.0.8. В итоге отвалилась настройка всех каналов в IPTV. Новая версия здорово отличается от старой и разбираться с ней нет никакого желания. У меня уже есть набор скриптов tvheadend-iptv-damavik, который делает всю черную работу.

Чтобы решить проблему малой кровью нужно установить старую версию пакета и заново импортировать настройки каналов и EPG. Полез в /var/cache/apt/archives - есть только новая версия. Собрался поискать пакет в бэкапе bacula, но вспомнил, что /var/cache/apt/archives исключен из бэкапа. В репозитарии tvheadend нужный пакет тоже недоступен, а поиск в гугле по названию пакета дает только ссылки на apt.tvheadend.org.

Хоть сам пакет и исключен из бэкапа, но ведь содержимое пакета в бэкапе есть. Нужно только извлечь нужные файлы, метаданные пакета и собрать пакет обратно. Сначала восстанавливаем метаданные - для этого выбираю восстановление бэкапа сервера, предшествующего дате 2015-12-19 00:00:00 и восстанавливаю директорию /var/lib/dpkg. Восстановленные данные будут находиться в /bacula/restore/.

Создаю директорию /root/tvheadend_3.4.27~gfbda802~wheezy_amd64 - сюда будут складываться нужные файлы пакета. Из бэкапа мне нужен /bacula/restore/var/lib/dpkg/info/tvheadend.list - тут описано содержимое пакета, которое мне нужно дополнительно восстановить из бэкапа. В сумме нужно восстановить следующие файлы и директории:

• /usr/share/tvheadend/
• /usr/share/doc/tvheadend/
• /usr/share/man/tvheadend.1.gz
• /etc/default/tvheadend
• /etc/init.d/tvheadend
• /etc/init/tvheadend.conf
• /usr/bin/tvheadend

Восстановленные файлы перемещаем в /root/tvheadend_3.4.27~gfbda802~wheezy_amd64. Данные пакета готовы, теперь очередь метаданных.

Создаем директорию /root/tvheadend_3.4.27~gfbda802~wheezy_amd64/DEBIAN/. Восстановленные файлы метаданных /bacula/restore/var/lib/dpkg/info/tvheadend.* перемещаем в /root/tvheadend_3.4.27~gfbda802~wheezy_amd64/DEBIAN и переименовываем чтобы убрать префикс tvheadend. из имени файла (tvheadend.md5sums -> md5sums, tvheadend.postinst -> postinst, и т.д.).

Для окончательной сборки пакета не хватает только файла DEBIAN/control - его содержимое можно взять в var/lib/dpkg/status.

Теперь собираем пакет

cd /root/tvheadend_3.4.27~gfbda802~wheezy_amd64
dpkg-deb -b . ../tvheadend_3.4.27~gfbda802~wheezy_amd64.deb
dpkg -i ../tvheadend_3.4.27~gfbda802~wheezy_amd64.deb

Осталось восстановить из бэкапа /home/hts/.hts/ и перезапустить tvheadend.

UPDATE: В комментарии напомнили, что недостает шага по фиксированию версии пакета. Можно либо через dpkg selections:

echo tvheadend hold | sudo dpkg --set-selections

либо через aptitude

sudo aptitude hold tvheadend

Или можно пошаманить с apt pinning.

Найти все пакеты, зависящие от ALSA, но не зависящие от PulseAudio

Найти все пакеты в системе, которые зависят от ALSA (пакет libasound2), но не зависящих от pulseaudio (пакет libpulse0)

$ awk -F: '/^(Package|Depends):/ {if ($1 ~ /^Package/) pkg=$2; if ($1 ~ /^Depends/ && $0 ~ /libasound2/ && $0 !~ /libpulse0/) print pkg}' /var/lib/dpkg/status
 gstreamer0.10-alsa
 iceweasel
 mencoder
 apulse
 libportaudio2
 audacity
 libcanberra0
 vlc-nox
 libflite1
 libsox-fmt-alsa
 libasound2
 recordmydesktop
 libwine-development
 alsa-utils
 chromium
 rdesktop
 openjdk-7-jre
 libkcompactdisc4
 libmlt6
 teamviewer5

В части пакетов функциональность pulseaudio реализуется плагинами (например vlc или gstreamer), но с чего начать уже видно.

NCQ в Linux как возможная причина медленной работы дисков

На этой неделе собирал php 5.5.30 для Debian Jessie и часто пользовался pbuilder. В какой-то момент заметил, что pbuilder слишком долго распаковывает пакеты в chroot. Проверил работу дискового массива через iostat - один из дисков зеркального RAID был занят на 10-20%, а второй на 100%. В сервере установлены два одинаковых диска TOSHIBA DT01ACA300 на 3Tb:

$ sudo hdparm -i /dev/sd{a,b}
/dev/sda:

 Model=TOSHIBA DT01ACA300, FwRev=MX6OABB0, SerialNo=Z3GHLUVGS
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=56
 BuffType=DualPortCache, BuffSize=unknown, MaxMultSect=16, MultSect=off
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=5860533168
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4 
 DMA modes:  mdma0 mdma1 mdma2 
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
 AdvancedPM=yes: disabled (255) WriteCache=enabled
 Drive conforms to: unknown:  ATA/ATAPI-2,3,4,5,6,7

 * signifies the current active mode


/dev/sdb:

 Model=TOSHIBA DT01ACA300, FwRev=MX6OABB0, SerialNo=X2S0833WS
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=56
 BuffType=DualPortCache, BuffSize=unknown, MaxMultSect=16, MultSect=off
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=5860533168
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4 
 DMA modes:  mdma0 mdma1 mdma2 
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
 AdvancedPM=yes: disabled (255) WriteCache=enabled
 Drive conforms to: unknown:  ATA/ATAPI-2,3,4,5,6,7

 * signifies the current active mode

Из двух дисков собран RAID1 в mdadm, а уровнем выше находится LVM.

Создал тестовый том /dev/VolGroup0/test и натравил на него fio со следующим конфигом:

[randwrite]
blocksize=4k
filename=/dev/VolGroup0/test
rw=randwrite
direct=1
buffered=0
ioengine=libaio
iodepth=32

Замеры показали около 10-30 iops, хотя должно быть 100 и более. Попробовал переключить IO scheduler на noop:

$ echo noop | sudo tee /sys/block/sda/queue/scheduler
$ echo noop | sudo tee /sys/block/sdb/queue/scheduler

Никакой разницы. А потом выключил ncq:

$ sudo hdparm -Q1 /dev/sd{a,b}

/dev/sda:
 setting queue_depth to 1
 queue_depth   =  1

/dev/sdb:
 setting queue_depth to 1
 queue_depth   =  1

После этого iops в fio стал стабильно выше 100. Для наглядности включил ncq обратно и iops через несколько секунд iops "испортился". Пока выключил, а дальше видно будет.