https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069182

Короче, в инитскрипт, запускающий udev на системах без системды (причём скрипт этот любезно предоставлен системдэшниками, но сами они, ЧСХ, его не используют), засунута команда, очищающая udev-базу, построенную на этапе initrd. Из-за этого диски, обслуживаемые девмаппером (а это LVM, и, возможно, всякие рейды) перестают нормально видеться удевом как валидные устройства. Что, в свою очередь, портит работу софта, пользующегося удевом для перечисления дисков (а его сейчас море). Причём в cоответствующих udev-рулесах для LVM даже явно говорится о том, что базу надо сохранять.

Отдельно доставляет то, что, как выясняется, кто и зачем вообще добавил это удаление — не знает никто.

Короче, если кто-то, как я, пердолится с безуспешными попытками что-то установить/настроить под 64-битным вайном — сообщаю, что гениальные дебилиановские мейнтейнеры спрятали исполняемый файл wine64 так, что по PATH он не находится. Типа вайновский лончер у них сам определяет, какую версию запускать. Что ломает хренову прорву установочных скриптов разного стороннего софта, которые рассчитывают на существование wine64. Ну, вот что стоило положить в /usr/bin/ долбаный симлинк, утырки?

Я кончил.

что наконец-то даёт возможность включить spec_rstack_overflow=microcode вместо дефолтного safe-ret. Ну чё, по крайней мере у меня в тесте sysbench threads (единственный тест, где результат был хуже, чем при mitigations=off) снижения производительности практически не наблюдается. (Хотя вроде как это менее безопасно, чем «Safe RET», но это другой вопрос.)

Чем бы ещё таким потестить? А то все бегали, орали про «снижение производительности вдвое».

Чо, как у кого прошло новейшее обновление с новым интерфейсом? В интернетах-то вон, вой стоит, что не запускается.

Как было у меня — обновление прошло, Стим сам перезапустился в первый раз нормально(!). Поглядел на новый интерфейс, вышел. И после этого — всё, халява кончилась, запускаться отказывался. Иконка в трее есть, окна нет. В логах куча подобного дерьма:

Jun 16 07:22:52 **** kernel: [ 1924.346637] traps: Composite Threa[4742] trap invalid opcode ip:7ff19dbdb794 sp:7ff18ae8a7f0 error:0 in libcef.so[7ff19b2ef000+7770000]

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

Что помогло лично мне: запустил стим с ключом -vgui, при этом загрузился старый интерфейс. Включил в настройках «use GPU acceleration» (много советов его выключать, но, похоже, новому интерфейсу он, наоборот, как раз таки нужен). Стим захотел перезапуститься, перезапустился сам нормально. После штатного выхода теперь вроде бы запускается без проблем с новым интерфейсом. Ну, ещё Big Picture почему-то оказался в оконном режиме вместо полноэкранного, хотя соответствующий пункт был выключен — помогло его включить/выключить.

Не факт, что переживёт перезагрузку, правда, не пробовал ещё…

Короче, как-то так получилось, что у меня уж давненько наблюдались микрофризы на нвидии 1080. В принципе, не сильно мешали даже в игрушках, так что привык, а разбираться было лень, грешил на драйвера или на недостатки общей конфигурации пекарни. А тут решил посмотреть на ФПСы, поставил mangohud и заметил, что пики на графике frametime, которые сопровождают эти фризы, следуют равномерно через 3 секунды. Опа, думаю, значит, что-то периодически дёргается в фоне. Оказалось — какое-то время назад добавил виджеты кде-шного рабочего стола, показывающие скорость вращения вентиляторов (тупо вывод cat /sys/class/hwmon/.../ fan?_input). Но вот тот, который показывает скорость вентилятора видяхи, за неимением соответствующей записи в /sys, дёргал, по совету из Арчевики, nvidia-settings -q GPUCurrentFanSpeedRPM -t, таки каждые 3 секунды. Я хз, чем это поделие там занимается ради вывода одного-единственного параметра, но таки вот. При этом та же nvidia-smi таким не страдает (но она текущую RPM выводить не умеет, только уставку скорости в процентах). Быстренько переделал утилитку из примеров libXNVCtrl, чтобы выводила нужную скорость, и щас наслаждаюсь идеальными 60 FPS в игрухах.

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

Edit: Вижу, требуется пояснение, в чём именно заключается вредность совета. Как выяснилось, nvidia-settnings ради чтения одного-единственного параметра на какую-то долю секунды ставит колом всю видеоподсистему. И это монстроидальное поделие рекомендуется в Арчевики для индикации параметров, например, в conky, что предполагает периодический вызов. А это, на минуточку, при периоде в 3 с, как был у меня — 1200(!) вызовов в час, или 28800(!!) в сутки. (Я тут даже подозреваю, что и глюк с перемежающимися GPF’ами плазмы, заканчивающимися паникой ядра, с которым я бьюсь уже года два — тоже, не исключено, был вызван этим гениальным поделием нвидиевских индусокодеров. Но это требует тестирования хотя бы на протяжении месяца.)

А то чо-то стал ковыряться — какой-то хренов зоопарк. Всякие вики советуют смотреть в /usr/include/X11/cursorfont.h или сравнивать с древней темой типа whiteglass — интересно, они сами это пробовали? У той же whiteglаss под КДЕ половина курсоров тупо не отображается, причем такие ходовые, как «уголки» при изменении размеров окна. Другой половины, наоборот, нет в этих древних списках — таких, как курсоры для драг&дропа, например. В штатных дебиановских темах курсоров полно каких-то имён типа nw-resize, отсутствующих в cursorfont, и симлинков с именами, похожими на хэши типа 0426c94ea35c87780ff01dc239897213 -> wait. Откуда они взялись? Хоть какие-то доки на весь этот бардак существуют в природе?

Edit: ну, какой-то более новый список я нашёл. Но про хэши вопрос остаётся.

Не совсем к линуксу относится, скорей к общесетевым вопросам, но спрошу тут. Наблюдаю какой-то сабж на домашнем серваке где-то с начала месяца (443/https, что характерно, работает). Заметил по сообщениям от certbot, что он не может летсенкриптовский ключ проверить (для этого сервак ACME должен зайти на мой по http, причём строго на 80 порт, в другие не умеет). Сначала подумал, что провайдер порт заблочил, но таки нет — в логах апача успешные заходы на 80 порт проскакивают, причём даже из Штатов, например. На магистральных каналах какие-то боевые действия, что ли? Но почему только 80 порта касается?

В частности имею в виду позорище с (не)подхватом монитора, включенного уже после загрузки. Между прочим, оффтопик умел это делать уже начиная с семерки, если не раньше. И напомню, что на современных видяхах никаких там вечно запитанных DVI/VGA уже нет, как правило, то есть надо уметь обрабатывать hotplug. Ну, udev умеет генерить событие при включении, а дальше что с ним делать? Ладно, иксы можно перезапустить, хоть по Ctrl-Alt-Bksp, хотя и это требует предварительного шаманства (нужно в конфиге разрешить запуск иксов без монитора и саму эту клавиатурную комбинацию) — а с фреймбуфером что? Никакое пердоление с заданием EDID в параметрах ядра не помогает от слова вообще.

Или это я настолько отстал от жизни со своим инитом и иксами, и модные systemd/wayland таки умеют подхват из коробки?

Короче, есть такая конфигурация ALSA->JACK: дефолтный plug -> dmix -> loopback -> dsnoop -> alsa_in -> JACK (кусок .asoundrc ниже, без capture части, она сейчас не важна).

pcm.!default {
    type plug
    slave {
        pcm "aloopDuplex"
        format S32_LE
    }
}

pcm.aloopPlayback {
  type dmix
  ipc_key 1
  ipc_key_add_uid true
  slave {
    pcm "hw:Loopback,0,0"
    format S32_LE
#    rate 48000 # default
    period_size 1024
    buffer_size 4096
  }
}

# duplex device
pcm.aloopDuplex {
  type asym
  playback.pcm "aloopPlayback"
  capture.pcm "aloopCapture"
}

# ------------------------------------------------------
# alsa_in -j alsa_in -d cloop -r 48000 -q 1
pcm.cloop {
  type dsnoop
  ipc_key 3
  ipc_key_add_uid true
  slave {
    pcm "hw:Loopback,1,0"
    format S32_LE
#    rate 48000 # default
    period_size 1024
    buffer_size 4096
  }
}

Формат S32_LE выбран для совместимости с JACK (потому что он обычно запускается первым и alsa_in создаёт свой конец loopback’а с таким форматом).

В принципе, в таком виде всё даже работает, НО. Битрейт в алсовской части, как видно, везде дефолтный 48000. Сам JACK сидит на 96000, поэтому получается двойная конвертация: сначала из источника (с каким-то своим битрейтом) plug делает 48000, а потом уже alsa_in 96000. Мне так показалось, что можно от этого избавиться, указав везде rate 96000 для Алсы, чтобы конверсия была один раз, на стороне plug. Попробовал — ИЧСХ, оно даже работает со speaker-test, например. Но вот Файрфокс, ска, отказывается цепляться к дефолтному устройству с какой-то невнятной диагностикой, чего-то там про MediaSinkAudioError.

Сначала подумал, что ему вообще битрейт выше 48000 не нравится, но он таки цепляется и звук выводит, если: а) запустить через apulse (пульсы в системе нет); или б) если дефолтным устройством задать непосредственно звуковуху, работающую на зажатом битрейте 96000.

ХЗ, чего ему может не нравиться. Ну, то есть, скорей всего, какой-то косяк в его поддержке Алсы, которую афтары постепенно deprecate’ят, но вдруг я чего-то ещё в конфиге не учёл?

Просто оставлю это здесь:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914179

Ни хрена не понимаю. Мать GIGABYTE GA-Z87X-UD5H, на ней стоят два сенсорных чипа, поддерживаемые модулем it87. Один IT8728F — он поддерживается давно и всё работает. Другой IT8790E — его поддержку не так давно запилили (не помню, когда именно, то где-то с месяц назад я его точно в xsensors наблюдал), о, думаю, зашибись. Обновил дебиановское ядро до 4.9.6 — опа, второй пропал. То есть драйвер его при загрузке видит:

dmesg.log
[   17.808119] it87: Found IT8728F chip at 0xa30, revision 1
[   17.808137] it87: Beeping is supported
[   17.808376] it87: Found IT8790E chip at 0xa40, revision 3
[   17.808401] it87: Beeping is supported

drwxr-xr-x 4 root root    0 мар  6 00:08 it87.2608
drwxr-xr-x 3 root root    0 мар  6 00:08 it87.2624

/sys/devices/platform/it87.2608$ ls -l
total 0
lrwxrwxrwx 1 root root    0 мар  6 00:08 driver -> ../../../bus/platform/drivers/it87
-rw-r--r-- 1 root root 4096 мар  6 00:09 driver_override
drwxr-xr-x 3 root root    0 мар  6 00:08 hwmon
-r--r--r-- 1 root root 4096 мар  6 00:09 modalias
drwxr-xr-x 2 root root    0 мар  6 00:09 power
lrwxrwxrwx 1 root root    0 мар  6 00:08 subsystem -> ../../../bus/platform
-rw-r--r-- 1 root root 4096 мар  6 00:08 uevent

/sys/devices/platform/it87.2624$ ls -l
total 0
-rw-r--r-- 1 root root 4096 мар  6 00:09 driver_override
-r--r--r-- 1 root root 4096 мар  6 00:09 modalias
drwxr-xr-x 2 root root    0 мар  6 00:09 power
lrwxrwxrwx 1 root root    0 мар  6 00:09 subsystem -> ../../../bus/platform
-rw-r--r-- 1 root root 4096 мар  6 00:08 uevent

Пишет насчёт user not authorized. Пользователь в plugdev есть. Хз, когда оно сломалось, давненько уже флэшки не совал - а тут опаньки. Чо эти мудаки из редхата сломали опять, куда копать хоть? udev, polkit, черта лысого?

...так теперь ещё и экспертами-наркологами заделались? Остолбенеть.

По существу-то есть что сказать? Где тут был «спор», «провокация» и прочая чешуя?

Не то чтобы этот ваш дрочерский скор представлял какую-то ценность, просто вот интересно. Ладно, когда я там кого-то называл «ватой» и проч. — это понятно. Но тут-то чо?