Битые картинки и как их выявить

 Битые картинки в галерее с фотоаппаратов, камер, телефонов и прочих средств... Наверное это знакомо каждому. И большинство из нас не знает масштаба трагедии, пока не наткнётся на парочку таких замечательных картинок, наподобие той, что я прикрепил в шапке. К слову эту картинку я специально попортил, открыв в текстовом редакторе и добавив один символ в середину файла. Понятно, что исправить такой байт - проблема та ещё, т.к. требует глубокого семантического анализа и не всегда восстановление возможно. Однако, подобных проблем можно избежать путём резервного копирования и использования файловых систем, поддерживающих "лечение" поломанных байтов данных. Но, начнём с простого - как определить, какие файлы поломаны, чтобы восстановить их из резервной копии.

Переключатель звуковых каналов в Linux для ленивых

Будучи любителем послушать музыку с комфортом, соединил свой компьютер с ресивером аудиосистемы с помощью TosLink/ S/PDIF и столкнулся с неприятной особенностью моей новой материнки. Так, она не умеет одновременно работать с аналоговым и цифровым выходом, так что старый трюк с добавлением виртуального устройства со вторым типом выхода не прокатил - второй выход оказался немым. В итоге, чтобы переключиться на S/PDIF, мне нужно каждый раз лезть в настройки PulseAudio и переключать выход на нужный в текущий момент (колонки/наушники у компа или аудиосистема по S/PDIF). Но, лень двигатель прогресса - меня этак картина быстро перестала устраивать и я озаботился переключателем, позволяющим быстро изменять режим звуковой карты. Поделюсь тут этим фокусом, может кому пригодится.

KXStudio и S/PDIF

Столкнулся с дурацкой особенностью связки ALSA+JACK Audio Toolkit. А именно, что по умолчанию он отказывается выводить звук через S/PDIF (что оптический, что коаксиальный). Долго плясал с бубном, пока не обнаружил указание на то, что в alsa цифровые выходы по умолчанию заглушены, т.к. у части звуковых карт нет поддержки одновременного вывода по digital/analog каналам. Так вот этот момент накладывается на то, что для перечисления устройств, Cadence использует команду aplay -l вместо aplay -L и получает упрощённый список а ля hw0:analog hw0:digital nvidia hdmi0 и т.д.  В общем, не показывается в этом списке, что часть каналов заглушена и запускается двумя параллельными триггерами. 

Решается это дело довольно просто - в Cadence нужно остановить JACK Server, затем запустить alsamixer, например в варианте alsamixergui (если не установлен - $sudo apt install alsamixergui), после чего видим весь список устройств и смотрим на значки сверху, что там заглушено - находим нужный интерфейс, включаем и вуаля - всё начинает работать. 

В заключении, хочется сказать, что для записи аудио - jack шикарная штука, а программы проекта KXStudio - великолепны, но вот для повседневной жизни это геморрой тот ещё - чтобы элементарно переключить канал входа или выхода, нужно зайти в Cadence → Configure → ALSA Driver → сменить вход/выход → JACK Stop → JACK Start → JACK Bridges: PulseAudio Start, иначе те же KDE не поймут, где у вас там звук и как он должен работать. 

В случае прямой работы ALSA → PulseAudio, KDE позволяет управлять звуковыми потоками очень гибко, вплоть до перебрасывания приложений между различными средствами вывода (бывает удобно, когда нужно, чтобы что-то шло через наушники, а что-то на громкую. 

Проблемы с тёмными темами и GTK2/MONO программами

Как любитель тёмных тем, время от времени сталкиваюсь с проблемами в некоторых криво написанных приложениях. Это относится, например, ко всему, что написано на .NET/Mono. К счастью, не много нормальных приложений написано на этой поделке от M$, но встречается. Так, например, произошло с замечательной лёгкой программой для математических вычислений SMath Studio (см. на картинке).

Проблемы с разрешениями для Transmission daemon и не только

Продолжаю настраивать свой домашний NAS и сгребать грабли.
Настроив SAMBA и получив весьма приличный результат по скорости копирования (>90МиБ/с), решил поставить и настроить Transmission daemon - чтоб NAS спокойно качал торренты, а пользователи могли ставить на закачку файлы через Transmission remote GUI, работающий, как с компов, так и с мобилок.

В общем, настройка Transmission daemon - не бог весть какая сложность - редактируешь себе /etc/ transmission daemon/settings.json , добавляешь нужных пользователей в группу transmission (в случае с Debian - это debian transmission), даёшь разрешения на нужные папки этому самому пользователю от которого работает transmission daemon (его можно проверить в конфиге /etc/init.d/transmission-daemon в разделе USER и, казалось бы, дело в шляпе.

Не тут то было. Всё сделал - при попытке скачать torrent получаю ошибку Permission denied.
Лезу, смотрю, что там с папкой:

$ls -l /share/HDB/Download 

Вижу ответ: drwxrwxrwx+ и по невнимательности своей думаю - ну всё ок вроде. Даю права владельца пользователю transmission - начало качать.
Вот только нафига нужны все файлы в одной свалке в "Download"? Не нужны - нужно перемешать в папки Video, Music и т.д. А там - такая же засада.

В общем, долго я мучился, пока не обнаружил тот самый идиотский "+" на конце. Оказывается, жолбаный QNAP, в чьём ведении до этого был жёсткий диск, умудрился проставить всем папкам и файлам ACL разрешения. А они ведь такая зараза, что перекрывают обычные nix'овые. Там и пользователи конкретные могут быть вписаны, и маски заданы.

В общем, снёс нахрен все ACL'ы с этих папок командой:

#setfacl -Rb /share/

Проблема разрешилась - transmission пишет во все нужные папки - жизнь удалась.

BTRFS is not so better

 Уже старая, вовремя не запощенная запись по BTRFS, родившаяся, как комент на хабрахабре про то, какая хорошая и перспективная файловая система этот бэтэрэфэс.
Оставлю тут в качестве предостережения. Уж поверьте, я с этой системой достаточно намаялся, чтобы предпочитать ей кривоватую связку ext4+LVM, для реализации некоторого функционала, не доступного в старых файловых системах.

Касательно btrfs, может у Facebook'а с его армией программистов низкого уровня и живёт это как-то, но мне кажутся полными камикадзами те, кто пытаются тащить в продакшн файловую систему к которой физически не существует полноценного инструментария для восстановления, с единственным аргументом «да она практически не ломается»… Ломается и ещё как ломается.

И даже не обязательно до потери данных, есть, например такие ошибки, когда найдены чексумы на не существующие данные и инструменты не позволяют изменять файловую систему (отрубаются все возможности по shrink, работе с субтомами и т.д.) и сделать можно ровным счётом ни-че-го. Только бэкап данных --> снос раздела --> восстановление данных на вновь созданный раздел.

И коллектив разработчиков из «гениев», которые лепят ошибки, делают неполноценные фичи, ломающие работающий функционал и потом отмазывающиеся ответами типа «а ну это у нас в версии такой-то баг был, что у вас всё слетело кхерям, но уже исправили» или «ах, а мы и не знали, что новая фича ломает старую». И ладно бы эти косяки попадали только в unstable — в обычном ubuntu со стабильными ядрами такое возникает регулярно — просто потому, что, оказывается, вот таким вот специфическим функционалом файловой системы не многие пользуются и не отловили.

Отсутствие документации на функции и вообще невнятность работы некоторых функций тоже доставляют. До ядра 3.17 при исполнении btrfs check --init-csum-tree с описанием мол «перестраивает дерево чексумм», на деле просто сносило к чёрту дерево чексум и делало файловую систему не читаемой. Потом кто-то в мэйллисте на это тыкнул с вопросом «а нахрена это надо?» И получил ответ типа «а ну не нужно ей пользоваться она ещё не дописана, чтоб реально работала». А добавили так, просто, как кнопку «харакири», только под надписью «реанимация».

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

Ubuntu Server 16.04 LTS Застряла в перезагрузке

Давича решил соорудить из дешёвого ПК, маленький домашний сервер и столкнулся с проблемой - сразу после установки Ubuntu Server 16.04 впал в цикл бесконечной перезагрузки.

Причём вход в Recovery происходил нормально и если врубить пункт продолжения загрузки - всё вроде как грузилось. Изучение journalctl дало единственную наводку - ошибка с radeon drm.
Я так слегка прифигел, от того, что на серверной оси пытается грузиться графика, решил посмотреть, что там в целях загрузки у GRUB стоит и обнаружил:

$sudo systemctl get-default

graphical.target 

Исправил это дело на multiuser.target:

$sudo systemctl set-default multiuser.target

Перезагрузился и... нифига - всё так же.
Снова попал в систему через рекавери, и начал гуглить.
Наткнулся на другую проблему на Ask Ubuntu.
Решил проверить настройки GRUB и обнаружил строку:

GRUB_CMDLINE_LINUX_DEFAULT=""

Заполнив пространство между "" параметром "nomodeset" и обновив груб ($sudo update-grub) получил реальную загрузку в текстовом режиме и проблема решилась!

В общем, чтоб не забыть решение - оставлю тут.