Дано: ASUS X50N, ноут которому уже почти 19 лет и нужно поставить на него систему, которая будет хорошо работать на нем в условиях современного веба. Выбор пал на Debian Linux с графической оболочкой LXQt. Данная среда рабочего стола является наиболее легковесной, по сравнению с другими наиболее распространенными. В итоге все прошло гладко, все основные устройства были определены в процессе установки Debian.
Изначально на нем стояла Windows XP. Стоял 160 Гб HDD, по тем временам (а это на секундочку 2007 год) это был достаточно большой объем. Вообще этот ноут использовался больше для мультимедиа задач - отредактировать фото, посмотреть фильм, записать на DVD слайд-шоу. Стоит отметить, что тут только SATA 2 на материнке, поэтому мы будем ограничены в плане пропускной способности накопителя.
О скоростях разных версий SATA:
SATA I: до 150 МБ/с
SATA II: до 300 МБ/с
SATA III: до 600 МБ/с
Как видим, достаточно мало по современным меркам. Если говорить о сети. Встроенная проводная сетевая карта поддерживает максимум 100 Мбит/сек. Беспроводное подключение - 54 Мбит/с.
В общем то, ноутбук в процессе эксплуатации за все годы ни разу не апгрейдили, за исключением установки SSD S55 от Silicon Power.
Тем не менее для базового интернет-серфинга его еще можно юзать, плюс ряд старых игр можно запускать без особых проблем.
Мой путь в мир линукса, как это все начиналось, как было и чем закончилось.
Это вторая статья из серии «моего пути», первая — про BSD и остальные сложные юниксы находится тут. В реальности погружение в индустрию происходило параллельно и я не выделял отдельные этапы работы только с линуксом или только с BSD.
Более того — в одной из следующих статей расскажу и про Windows, которую тоже знаю давно и глубоко.
Начало
Шел тяжелый 1998й год, тот самый кризисный, когда вместо рублей на ценниках красовался ныне забытый У.Е. а по улицам катались братки на черных мерседесах.
На самом деле, я уже не особо помню, какой точно дистрибьютив был первым — RedHat это был или Mandrake или даже Slackware, поскольку доставалось оно тогда охапками, ставилось «на посмотреть», быстро убивалось и откатывалось обратно на венды.
Но был один, с которым я зашел сильно дальше чем просто установка, с которого по-сути началось полноценное использование Linux.
Mandrake, Mandriva, Mageia
Мое более-менее осознанное использование линукса началось с Mandrake Linux. На что были веские причины:
несмотря на проблемы с оборудованием — мышка и та работала не всегда, Мандрейк был самым «пользовательским» дистрибутивом и только на нем одном можно было сразу получить хоть какое-то рабочее окружение, без сложной правки конфигов.
У него же был первый графический инсталлятор, который сам умел определять разрешение экрана и частоту развертки.
Плюс пакеты, много пакетов.
Судя по награде за 2000й год, у меня было что-то еще более древнее.
Сейчас это трудно объяснить, но выкачать даже 600Мб (размер одного CD-диска), необходимых для установки — по модему было ох как непросто.
Сутками скачивалось.
Поэтому имея 4 CD-диска, забитых софтом, можно было вполне комфортно жить. Вот так примерно выглядело окружение тех лет:
Тот самый KDE3, золотая классика и веха в развитии всего OpenSource.
Обратите внимание на XMMS — знаменитый линуксовый клон Winamp, на котором следущие 10 лет автор слушал музыку:
Да, это именно Netscape Navigator - предок Мозиллы и Firefox. До создания Хрома еще десять лет.
Доступ в интернет тогда был через телефонную линию и модем, время пентиумов, целеронов и хренового китайского железа (Acorp кто-то еще помнит?) Звук, видео и модем, раскладка клавиатуры и локализация — все это настраивалось, но с таким боем и по кривым мануалам, что словами эти ощущения не передать:
Видео — с ручной настройкой разрешения и частоты кадров, «плоских» мониторов еще не было;
Локализация — с кракозяблями и KOI8-R кодировкой, UTF-8 повсеместно появится через примерно пять лет.
Короче было весело.
CD-диски с Mandrake образца 2003го года, третий курс ВУЗа.
Wine тогда еще не придумали а развитие OpenOffice не позволяло нормально работать с документами MS Word — поэтому с самого начала (и поныне) у меня был dual boot:
венды, линуксы и BSD на разных разделах и разных дисках.
Количество компьютеров также постоянно росло, появлялись первые сервера и сетевое оборудование — благо работа «сисодмином-разработчиком» позволяла постоянно таскать домой самые разные железки.
Думаю мало кто из смертных может похвастаться опытом настройки домашней локалки на маршрутизаторе уровня ядра, пусть и недолгим — мне его дали на время, для обновления прошивки и настройки.
Настройка OSPRF, RIP и VLANов — в 2004м году, ручками, в дикой сибирской провинции.
Так что я работал с IOS задолго до появления этих ваших айфонов ;)
Но про сети и сисадминство расскажу как-нибудь в другой раз, благо там тоже было немало приключений.
Чудесные студенческие годы.
Едем дальше.
2007й год, который «блейзер-челки-эмо-готы» — вот это все. Еще это последний «жирный» год, потому что в следующем 2008 опять грянет мировой кризис. В тот год Мандрейк обанкротился, развалился и стал Мандривой, полная история для ценителей вот тут.
Но тем не менее, открытое продолжение Мандрейка - «Mandriva One» вновь стал очень большим шагом вперед, показав всему миру как надо делать нормальные дистрибьютивы.
Графический пошаговый инсталлятор, LiveCD, адекватная локализация - все что нужно для счастья линуксоида в ламповом 2007м .
Заодно настало время дурацких спецэффектов — появился Сompiz (Beryl и Emerald в те далекие времена):
Cейчас уже выглядит совсем аляповато, но в те годы это выглядело очень круто.
Образ Мандривы я уже выкачивал сам, но устанавливал пока еще с DVD диска. До первых «bootable usb stick» пройдет еще пару лет, а пока это все такой же «bootable iso» в лотке привода.
Вот так выглядело мое рабочее окружение в те годы:
Самый старый скриншот из сохранившихся. 2007й год.
Скриншот этот на самом деле очень интересный:
идет сборка из Portage от генты, но.. в Мандриве! Окружение — сильно переделанный jwm, а редактор — сильно переделанный Metpad. Котик (слева) — анимированный, мой, исходник потерялся в годах.
Обратите внимание, что в качестве браузера тут Firefox, поскольку Google выпустит первую версию Chrome только через год.
Много чего произошло с тех пор:
бесконечные работы во всех возможных жопах ИТ-отрасли, переезд в Германию, затем в Москву, в Сингапур, обратно в Москву и затем в Питер.
Но основным линуксом все также оставалась Мандрива.
2016й год, пью пиво посреди Сингапура.
Хотя временами я конечно перебирал со стилем:
Весна 2016го. Вроде и было не так давно, но насколько же мир успел измениться.
С тех пор и поныне, Mageia - продолжение Мандривы активно используется и является одной из ключевых рабочих систем.
Ныне это выглядит вот так:
ROSA , OpenMandriva и русский линукс
Как-то так получилось что чисто отечественные дистрибьютивы я толком не использовал — ни Альт ни ASP. И вся жесть вроде Black Cat Linux тоже обошла меня стороной :)
Росу я также полностью пропустил, вместе со всем их движем на тему совместной разработки с OpenMandriva. Видимо сказался хороший уровень владения английским, благодаря чему русская локализация мне никогда не была нужна.
Все остальное
Я перепробовал по большому счету все известные и популярные дистибьютивы. Какие-то использовал разово, какие-то использую по работе до сих пор а некоторых уже нет на свете (более не развиваются).
Хоть как-то описать весь мой опыт нереально, поэтому пройдусь по верхам.
Debian & Ubuntu
Получилось так, что с Дебианом я познакомился позже чем с Убунтой, причем путем «поиска первоисточника» в интернете. Шел 2005й год, Убунту к тому времени уже стала легендарной в мире опенсорса — из-за легкости в освоении для простых пользователей.
И действительно, ее удалось без особых проблем поставить на HP Compaq NX9020 — мой первый ноутбук:
Через него потом прошло все доступное и возможное, включая Sun Solaris x86, Slackware и все найденные BSD.
А вот уже «тюнингованный» Дебиан, внезапно на Panasonic CF-28:
2011й год, Москва.
C оформлением я опять сильно перебрал, поскольку тут еще больше кастомизированный JWM, уже без отсылок к оригиналу.
Много чего на C и Tcl писалось на этой машине:
2012й, Москва, парк Горького.
RedHat, CentOS и Scientific Linux
Серьезное использование началось с 2006 года, после переезда в Москву. Использовал именно для работы, когда было нужно иметь дело с закрытым корпоративным софтом от IBM и Oracle:
Все оно сильно зависело от устаревших системных библиотек, поэтому нормально работало только под такими специфическими дистрибьютивами.
Собственно ситуация с тех пор не сильно поменялась — завести «большую» вебсферу (не Liberty) под какой-нибудь убунтой такая же проблема как и 20 лет назад.
Scientific Linux — в своем роде уникальная штука, дистрибьютив созданный ИТ-департаментом CERN, у которого апстримом является и так стабильный CentOS. Получился эдакий дистиллят стабильности, в мире бесконечных обновлений и патчей обычных линуксов.
К сожалению не так давно разработка этого дистрибутива была прекращена.
Arch, Manjaro
Это уже новодел, с которым я впервые познакомился читая знаменитую Arch Linux Wiki.
В какой-то момент там собрали вообще всю актуальную информацию о тонкой настройке графики в линуксе: Xorg, Xinerama, Compiz, Wayland, о виртуализации: KVM, docker, ansible — короче обо всем, что делалось долго, сложно и требовало включать голову .
Логичным шагом стало изучение и самого арча. Впрочем он бысто надоел своей нестабильностью и я переключился на куда более стабильный Manjaro, который и cейчас используется на одном из ноутбуков для веб-разработки.
Всю жизнь таким занимаюсь.
Работа
Думаю у вас после прочтения встал очевидный вопрос:
чем же таким автор занимался по работе и кто платил за все эти компьютерные радости?
За все эти дистрибьютивы, изучение всяких BSD, сетей и установки линуксов на десктоп и ноутбуки — ведь это все несколько далеко от должностных обязанностей, кого бы то ни было.
На самом деле, чаще всего получалось, что ввиду широких компетенций, я совмещал обычно сразу несколько должностей: от планирования до разработки и внедрения.
Если делать разбивку на современные должности:
СTO, архитектор, тимлид, ведущий разработчик, аналитик, QA, DBA, DevOps, администратор и сетевой инженер.
Это было очень характерно для ИТ-индустрии в те годы, так что врядли удивлю кого-то из ветеранов.
Здравствуйте мои маленькие и взрослые любители линкуска.
Думаю, что каждый кто пользовался консолью, рано или поздно хотел ее кастомизировать, сделать функциональнее или красивее, и многих это приводило к проектам типа oh-my-zsh.
Вот и меня это приводило к нему и всегда вызывало попаболь.
На картинке все красиво, а когда начинаешь разбираться то понимаешь, что поймал какой то гемор.
Талмуды документации, не оень понятно с чего начинать, и самое что меня бесило это ручная правка конфига.
Все это приводило к тому что или ползовался какой то сборкой либо удалял его к чертям.
В общем мне все это надоело и я решил сделать свой фреймворк с блэкджеком понятным управлением и приятным интерфейсом которым хочется пользоваться.
И так, что мы имеем:
Все управление осуществляется через CLI, автозавершение команд через ТАБ.
Система плагинов - все так же включается и выключается командами через консоль, можно посмотреть список плагинов и описание к каждому из них. Возможность установки из других репозиториев.
Нескучные обои темы
Ииии о боже мой! Да разве можно было вообще о таком мечтать!
Переносимые профили!
Создал свой профиль, с темой набором плагинов, так же командой создается контейнер которым можно делиться или переносить между девайсами.
Все работает быстро и без тормозов.
Есть встроенный доктор который проверит конфигурацию на ошибки
DreamZSH Stats который показывает время загрузки и прочую инфу о текущей конфигурации.
Бэкапы
И прочие радости жизни. Я постарался учесть как можно больше деталей для удобство пользования. Порог вхождения стримится к нулю, можно даже мануал не читать.
В общем если вам интересно, ставьте, пользуйтесь, буду рад обратной связи.
Перевести проект в продакшен – это не поднять dev-стенд. Подходящий сервер должен выдерживать пиковую нагрузку, восстанавливаться после сбоев и не создавать сюрпризов ночью. Не каждый VPS подходит для этого: провайдеры по-разному гарантируют ресурсы, стабильность и время реакции поддержки.
Критерии production-ready VPS
VPS для продакшена должен давать предсказуемые ресурсы, а не мягкие лимиты с оверселлингом. Ключевые параметры: полноценная аппаратная виртуализация, изоляция ресурсов, стабильное хранилище, стабильная сетевая пропускная способность и поддержка IPv6. SLA не ниже 99,9% с описанными компенсациями – это важный ориентир для продакшена.
Безопасность и резервирование
Настройка сервера для продакшена начинается до деплоя: firewall настроен, SSH переведён на ключи. Типичные ошибки: открытые порты на всех интерфейсах, отсутствие изоляции между сервисами и ненастроенные snapshot’ы. Для любого продакшен-сервера регулярные бэкапы – обязательное условие. Без проверенного восстановления они не надёжны.
Мониторинг и автоматизация
Без метрик и алертинга продакшен-среда остаётся неконтролируемой. Подключите Prometheus или Zabbix, настройте пороговые алерты по CPU, RAM, дискам и времени ответа. Для крупных проектов и командной разработки полезно хранить конфигурацию инфраструктуры в Ansible или Terraform. Это упрощает деплой, поддержку среды и восстановление после сбоев, но не является обязательным условием для каждого продакшен-проекта.
Чек-лист: production-готовность VPS
• SLA ≥99,9% с описанными компенсациями
• Стабильное хранилище с понятными ограничениями по производительности
• Аппаратная виртуализация и изоляция ресурсов
• SSH-аутентификация по ключам, firewall настроен
• Автоматические бэкапы с тестом восстановления
• Мониторинг и алертинг (Prometheus или Zabbix)
Проверьте, закрывает ли ваш VPS-провайдер требования продакшен-нагрузки. Если по важным для проекта пунктам есть пробелы, лучше устранить их до деплоя, а не во время первого инцидента.
Сервис замедлился, в мониторинге всплывают ошибки – нужно быстро понять, в чём причина. На VPS причин больше, чем на физическом сервере: к собственной нагрузке добавляются гипервизор и соседи по ноде. Вот метрики производительности, с которых начинают диагностику.
CPU: load average и steal time
В top видны сразу оба числа: load average и %st. Load average выше числа vCPU – повод проверить нагрузку, но это только ориентир: в это значение входят не только задачи, ожидающие CPU, но и процессы в ожидании ввода-вывода. На серверах с быстрым I/O или большим количеством потоков высокий load не всегда означает проблему с процессором. Если %st высокий, mpstat -P ALL 1 покажет, какие именно ядра страдают. На Cloud VPS %st важен: стабильно высокий показатель может говорить о задержке выделения CPU со стороны гипервизора, но сам по себе не доказывает оверселлинг.
Память и swap
free -m: смотрите столбец available, но помните, что Linux использует свободную RAM под файловый кэш. Если available низкий, а vmstat 1 показывает ненулевые si/so – система уходит в swap и задержки растут. Проверьте dmesg | grep -i oom, OOM-killer мог убить процесс.
Диск: iowait и latency
iostat -x 1: %iowait в CPU-блоке выше 10–15% может быть сигналом для проверки диска и очереди I/O. Нормальные значения зависят от типа нагрузки: для баз данных, очередей и файловых сервисов они могут отличаться. По устройствам – await (мс) и %util. На NVMe %util ненадёжен: 100% не означает полной загрузки диска. Смотрите await: для NVMe тревожно выше 1–2 мс, для сетевого хранилища – выше 20 мс.
Сеть: пропускная способность и потери
ss -s показывает TCP-соединения по состояниям. Ретрансмиты проверяйте отдельно: nstat -az | grep -i retrans. Команда показывает статистику TCP-стека ядра, поэтому она не отражает все возможные потери пакетов на уровне сети провайдера. Тревожен не сам ненулевой счётчик, а его рост при штатной нагрузке. На VPS виртуальный сетевой стек может добавлять задержки, а ifstat показывает текущую скорость передачи данных через интерфейс.
Первые 5 минут: чек-лист
• uptime – load average за 1, 5 и 15 минут
• top – steal time (%st) и топ потребителей CPU
• free -m – нагрузка на память и своп
• iostat -x 1 3 – await и %util по дискам
• nstat -az | grep -i retrans – ретрансмиты и потери пакетов
Зафиксируйте базовые значения при штатной работе – без них разобраться в отклонениях сложнее. Запустите этот мониторинг на своём VPS и сохраните вывод для будущих сравнений.
На свете есть не так много вещей, способных выбесить программиста. И лишь одна делает это с гарантией: оборзевшая машина, возомнившая себя умнее человека.
А значит снова пришло время карать и патчить!
Видите эти повторяющиеся записи справа? Так будет выглядеть буфер сообщений ядра (dmesg), если вам не повезло нарваться на этот баг.
Direct Rendering Manager (DRM)
Развитие современных видеокарт пошло по весьма.. сюрреалистичному пути:
производители страстно желают, чтобы выпускаемые устройства имели максимальную совместимость с модными открытыми ОС, но одновременно были закрытыми и неповторимыми, защищенными разнообразными патентами.
То что звучит как чистая шизофрения для человека с техническим образованием, будучи спущенным сверху в виде директивы, еще и подкрепленной серьезным бюджетом, породило на свет такую «хтонь» как binary blob.
Это когда основная часть управляющей устройством логики реализуется в виде специальной прошивки с защитой и обфрускацией — того самого «блоба».
Затем вокруг создается открытая часть ПО, которая линкуется с открытым ядром и/или окружением. А все это вместе и без смущения объявляется как частично беременна открытое решение.
The Direct Rendering Manager (DRM) is a subsystem of the Linux kernel responsible for interfacing with GPUs of modern video cards
Если кратко и цензурно, то это такая специальная дыра в ядре Linux, для максимально быстрой коммуникации между видеокартой и клиентским ПО, создаваемая в первую очередь ради видеоиг.. скажем так «медийных приложений, требующих аппаратного ускорения графики».
В угаре оптимизации «ядростроители» дошли до использования 3D-ускорения (GPU) даже для отрисовки терминала текстовой консоли (тот самый KMS):
И теперь мы все имеем клевый терминал в разрешении 1920×1280 со сглаживанием шрифтов, на котором что-то разобрать возможно лишь с лупой прищурившись.
Угар портирования
Под натиском волн малолетних специалистов, желающих «гонять игоры» на серверной ОС, не выдержали даже разработчики FreeBSD:
подсистема DRM и KMS, вместе с проприетарными блобами была перенесена из Linux и теперь вовсю используется в FreeBSD.
По-умолчанию, да.
Кстати с тех лет и до сих пор разработка DRM синхронизируется с апстримом (а это внезапно отдельный проект) и ядром Linux, заезжая в сборки FreeBSD вместе со всеми свежими багами в виде срезов исходников. Основная разработка при этом едет дальше.
Нетрудно догадаться, что отправлять багрепорты в проект drm-kmod, курируемый FreeBSD или апстрим ядра Linux при таком подходе равнозначно отправке в «Спортлото».
Заодно во FreeBSD были фактически похоронены альтернативные варианты:
старый текстовый TTY и Xorg-драйвер для видеокарт Intel пока еще существуют и собираются в виде пакетов, но вот их настройку и главное — все сопутствующие сбои в клиентском ПО вы теперь вынуждены отлавливать и исправлять самостоятельно.
«Интерес сообщества» к таким технологиям оказался утрачен.
В качестве вишенки на этом интересном торте из говна, добавлю что всенародно любимый браузер Google Chrome плохо работает без модуля KMS, поэтому заводить весь этот цирк с DRM и KMS приходится даже на откровенно винтажных машинах — ради работающего браузера.
И других вариантов уже фактически нет.
Как-то так выглядит процесс попадания обновлений DRM в FreeBSD. FreeBSD — крайний справа, увы.
Оборзевшая техника
Вся эта технологическая «многоножка» из разработчиков Intel с блобами, апстрима ядра Linux с любовью к тотальным переделкам на Rust, на практике приводит к тому, что в бедную FreeBSD постоянно попадают ломающие обновления, отследить и исправить которые «в моменте» не получается.
«Думали что работает» — говорят в таких случаях разработчики FreeBSD и советуют обновиться до -CURRENT версии.
Что для обычных людей и рабочего окружения на машине равносильно старому японскому ритуалу сеппуку, поскольку упадет и сломается вообще все.
В какой-то момент обновление пакета drm-kmod, содержащего тот самый порт подсистемы DRM из ядра Linux принесло мне такое:
drmn0: [drm] ERROR Fault errors on pipe A: 0x00000080
Ну принесло и принесло, ошибок много разных, исправляются далеко не все, дело это небыстрое и так далее.
Но только эта забивала собой весь буфер сообщений ядра!
Сообщений генерировалось настолько много, что dmesg — команда для отображения этого самого буфера, показывала только одну эту бесконечно повторяющуюся ошибку, как на скриншоте в шапке статьи.
Но самое веселое, что баг оказался с рогами и копытами совсем не специфичным и само сообщение означает буквально.. ничего.
Просто «что-то сломалось», в переводе с языка Intel.
Ну что, вы все еще любите проприетарные драйвера от уважаемых производителей?
Беглый поиск в репозитории, в котором ведется разработка подсистемы DRM (напоминаю, она ведется отдельно от ядра Linux) показал, что сообщений с этой ошибкой навалом:
88 репортов, только в этом довольно новом репозитории.
Положение дел
В итоге есть некий баг, с гнездом в районе прошивки видекарты Intel, который (судя по репортам) зверствует проявляет себя самым феерическим образом:
от спама сообщениями до мигания экрана и полного зависания системы.
Исправить своими силами этот баг нельзя, все «workaround» в сети по накалу дичи в рекомендациях напоминают известное шоу «Битва Экстрасенсов»:
нарисуйте ночью в поле пентаграмму из соли, разложите по углам загрузочные диски FreeBSD с 5й по 10ю и громко читайте Changelog задом наперед.
Первая заключается в том, что в свежих прошивках баг вроде бы исправили на стороне Intel, но чтобы эту прошивку поставить — нужна сборка модуля DRM для FreeBSD 15, которая еще не была выпущена на момент написания статьи:
Еще стоит рассказать, что прямо сейчас идет серьезная работа по перепиливанию DRM как в его основном проекте так и на стороне команды FreeBSD (в -CURRENT), поэтому даже пытаться бекпортировать текущую версию drm-kmod в 14.х ветку не стоит.
Также (к сожалению) не стоит рассматривать переезд на 15ю версию как гарантированное решение, поскольку есть уже открытые багрепорты и оттуда:
Хотя тут явно использовалась 6.1 версия.
Вторая хорошая новость заключается в том, что на двух моих ноутбуках, где проявляется данный баг все работает без критических сбоев — без мигания и зависаний системы. А само сообщение до недавних пор глушилось настройкой:
compat.linuxkpi.i915_disable_power_well="0"
Так что конкретно в моем случае, проблема заключается лишь в бесконечном затирании буфера сообщений ядра этой дурацкой и бессмысленной ошибкой:
drmn0: [drm] ERROR Fault errors on pipe A: 0x00000080
Которую мы и будем сейчас цинично глушить.
Аморальный патч
Разумеется так делать нельзя:
глушить сообщения об ошибках в ваших реальных проектах не стоит.
Хотя если в вашем проекте возникает ситуация, когда сообщение об ошибке генерируется по сотне раз за секунду — ну наверное вопрос уже к вам как к разработчику, допустившему такую дичь.
К счастью FreeBSD проект не мой, прямого доступа к разработчикам нет, а сам процесс разработки подсистемы DRM сильно напоминает известный фильм «Human Centipede».
Где (а главное — зачем) искать концы в такой ситуации не очень понятно, для примера багрепорты по ошибкам DRM в трекере ядра Linux сразу просят перенаправлять в отдельный проект, не разбираясь:
Так что было решено применить военную хитрость просто заглушить сообщение об ошибке в исходниках, пересобрав DRM из портов.
Так выглядит конечный результат после патча:
Как видите буфер ядра не забит этими дурацкими сообщениями.
Поскольку новая 15я по счету версия FreeBSD еще официально не вышла на момент написания статьи, я все еще использую 14.3, где максимально доступная версия DRM для этой ветки — 6.1.
Ее мы и будем жестоко патчить.
В портах она находится в этом каталоге:
/usr/ports/graphics/drm-61-kmod
Поиск в исходном коде по тексту сообщения об ошибке показал, что генерируется она всего в одном месте, в файле i915_irq.c:
if (fault_errors) drm_err(&dev_priv->drm, "Fault errors on pipe %c: 0x%08x\n", pipe_name(pipe), fault_errors); ..
Все что нужно сделать — закомментировать этот блок, начиная с условия.
И все, больше вы это проклятое сообщение не увидите, ура.
Для уменьшения работы мозгом у дорогих читателей, подготовил на этот раз готовый патч, который достаточно положить в специальный каталог и он автоматически применится при сборке drm-kmod.
Надо создать файл patch-i915_irq.c в каталоге /usr/ports/graphics/drm-61-kmod/files, затем вставить туда вот такое содержимое:
*** drivers/gpu/drm/i915/i915_irq.c.orig Tue Nov 18 17:17:39 2025 --- drivers/gpu/drm/i915/i915_irq.c Tue Nov 18 17:17:52 2025 *************** *** 2571,2585 ****
if (iir & gen8_de_pipe_underrun_mask(dev_priv)) intel_cpu_fifo_underrun_irq_handler(dev_priv, pipe);
fault_errors = iir & gen8_de_pipe_fault_mask(dev_priv); ! if (fault_errors) drm_err(&dev_priv->drm, "Fault errors on pipe %c: 0x%08x\n", pipe_name(pipe), ! fault_errors); }
if (HAS_PCH_SPLIT(dev_priv) && !HAS_PCH_NOP(dev_priv) && master_ctl & GEN8_DE_PCH_IRQ) { /*
Дальше просто перезапускаем сборку:
make clean make
Проверяем что изменения в файле i915_irq.cприменились и запускаем установку собранного пакета:
make reinstall
После чего перезагружаем систему.
Если все прошло удачно — дурацкое сообщение вас больше беспокоить не будет, если нет — компьютер взорвется система скорее всего зависнет при запуске, либо вас будет ожидать черный экран.
Но главное это разумеется хорошее настроение и поставленная на место машина, вернувшаяся к своей основной задаче служить людям.
P.S.
Ошибка действительно дурацкая, еще и наведенная — если дойдет до серьезных сбоев вроде мигания экрана (screen flickering), вы увидите дополнительные сообщения в логах, по которым можно продолжать искать реальную проблему.
Так что вопрос удаления этого сообщения чисто косметический и частично — лишней нагрузки, поскольку генерация сотен таких сообщений в секунду разумеется нагружала систему.
Сейчас будет еще одна «трешевая» история из мира открытого ПО, из тех что не рассказывают детям, дамам и сотрудникам ППС.
С добрым утром!
XFCE
Xfce это такое очень популярное рабочее окружение (Desktop Environment), яркий представитель опенсорса, который вы неоднократно могли видеть в моих статьях и скриншотах.
Одно время им пользовался даже сам Линус Торвальдс, мотивировав переезд чрезмерным ожирением KDE и уходом в лунатизм разработчиков Gnome.
Штука популярная и известная, некий баланс разумности и последний барьер, разделяющий откровенную гиковскую дичь вроде тайловых менеджеров и тяжеловесные современные среды, разрабатываемые большими командами при поддержке мировых корпораций.
БАГ
Разумеется в Xfce есть баги и недоработки, не такие феерические как например в KDE («Плазма не падает» ага), но тоже временами доставляющие и долгоживущие. Как раз об одном таком «долгожителе» и пойдет наш сегодняшний рассказ.
Как это выглядит в действии:
ноутбук засыпает, ноутбук просыпается и на экране внезапно появляется.. диалог «Display Settings».
Казалось бы мелочь, ну появляется и появляется (причем не на всех ОС и ноутбуках), б‑г с ним и без того проблем навалом.
Но во‑первых временами появляется несколько копий этого диалога, что огорчает куда сильнее, поскольку приходится их каждый раз закрывать. А во‑вторых автор не просто так два десятка лет занимается разработкой, чтобы позволить какой‑то программе творить беспредел.
Так что я полез за боевым топором компилятором.
Ресерч
Первый же беглый поиск дал понять, что это не осеннее обострение проблема есть далеко не только у меня, вот например сообщение с официального форума Xfce от 2021 года:
А вот об этой проблеме пишут на форуме Linux Mint:
Так что проблема действительно есть, причем именно в Xfce а не в конкретной ОС, дистрибутиве или настройках окружения.
Дальнейшие изыскания привели в багтрекер Xfce, к этому багу из 2013 (!) года:
Я насчитал двадцать (20) дублей, закрытых за все время жизни этого тикета, но поскольку с 2013го года сам трекер успел переехать с BugZilla на Gitlab (оригинальный тикет находится тут) — гарантированно что-то успело потеряться.
Несмотря на сильно отличающееся описание, если посмотреть переписку под тикетом — можно увидеть знакомые рога и копыта очертания бага с открытием диалога:
А вот это сообщение в обсуждении навело на возможное место в исходном коде, ответственное за проблему:
Разумеется с 2021го года логика в исходниках успела измениться до неузнаваемости и в актуальной на момент написания статьи версии 4.20 это место выглядит иначе:
Суть происходящего
При восстановлении из сна, происходит повторное включение монитора (какой сюрприз), которое вызывает отработку логики, отвечающей за поиск новых устройств вывода:
Из-за данной логики и происходит отображение диалога «Display Settings», по замыслу авторов — как приглашение к настройке нового устройства, когда например подключается второй монитор или проектор.
"Благими намерениями", вы правильно поняли.
Обратите внимание на вот такую проверку:
/* Start the display dialog according to the user preferences */ if (action == ACTION_ON_NEW_OUTPUT_SHOW_DIALOG) { ..
Чуть выше по коду в этом же файле displays-x11.c происходит чтение из настроек:
Таким образом по идее создателей, если в этом диалоге в поле «When display is connected» выставлено значение «Do nothing»:
Тогда никакого диалога при просыпании ноутбука появляться не будет.
Но есть нюанс.
Нюанс
У Xfce традиционно не очень хорошо с настройками — она их регулярно теряет и сбрасывает при обновлениях, перезаписывает новыми опциями и вообще всячески ломает.
Из‑за чего диалог «Display Settings» появляется снова и снова.
Я решил что хватит это терпеть видеть сей проклятый диалог при просыпании ноутбука более не желаю, поэтому применил спецсредства.
Решение
Думаю нетрудно догадаться, что окончательное решение диалогового вопроса оказалось очень простым:
/* Start the display dialog according to the user preferences */ if (action == ACTION_ON_NEW_OUTPUT_SHOW_DIALOG) { // const gchar *cmd = helper->outputs->len <= 2 ? "xfce4-display-settings -m" : "xfce4-display-settings"; // xfce_spawn_command_line (NULL, cmd, FALSE, FALSE, TRUE, NULL); g_print("Ignored 'Display Settings' dialog \n"); }
Да, весь блок (он такой один), отвечающий за запуск диалога «Display Settings» был самым банальным образом закомментирован в файле displays-x11.c. И нет, мне не стыдно.
Wayland
Несмотря на то что автор не пользуется Wayland, Xfce его поддерживает и в файле displays-wayland.c есть полностью аналогичное место, где также зашит вызов диалога «Display Settings».
Так что если вы используете Wayland и столкнулись с описываемой проблемой — теперь знаете где именно искать и что делать.
Однако поправить код в таком проекте это лишь начало, ключевая проблема — как это потом собрать и запустить.
Сборка
На самом деле мне сильно повезло, что исправление выше находится в небольшом и автономном консольном приложении xfsettingsd, исходники которого в свою очередь находятся в отдельном репозитории xfce4-settings.
Так что экстремальных приключений в виде сборки всего Xfce из исходников с последующей установкой удастся избежать.
Переключаемся на релизную ветку той версии Xfce, которая у вас уже установлена — не забываем, что мы правим лишь один небольшой сервис, а все остальное остается из пакетной версии:
git checkout origin/xfce-4.20 -b xfce-4.20
Вытаскиваем зависимые репозитории:
git submodule update --init --recursive
Запускаем сборку:
./autogen ./configure gmake
В каталоге xfsettingsd появится одноименный бинарник с измененной логикой.
Я не стал заморачиваться с отдельным каталогом в PATH и изучать доступные в Xfce механизмы переопределения путей, вместо этого просто подменив бинарник:
cp ./xfsettingsd/xfsettingsd /usr/local/bin/
И все, больше никаких надоедливых диалогов.
Так выглядит проверочное сообщение, добавленное вместо закомментированных вызовов:
Эпилог
Разумеется такое исправление никогда не примут в апстрим Xfce (занятый переездом на meson) и без навыков программирования вы обречены на вечные муки и страдания наблюдать этот диалог до скончания времен — пока при очередном обновлении не слетит конфигурация.
Добавлю, что сам этот функционал принудительного открытия диалога настроек при изменении оборудования — откровенно дурацкий, из серии «хотели как лучше» и точно нуждается в пересмотре.
Но повлиять «с моей галерки» на авторов Xfce разумеется никакой возможности нет.
