Чиним Plymouth в Debian 8 (а возможно и еще где-то)

    TL;DR Захотелось поставить на старый нетбук Debian 8, сказано — сделано. В целом все работает, но вот вместо красивой заставки при загрузке — бегущие строки загрузки ядра и сервисов. Не красиво. В чем же проблема? Будем разбираться.



    Итак, лежит у меня старый (уже) нетбук ASUS 1201N. В принципе он и ранее использовался для чего-нибудь типа поправить из консоли конфиг или посмотреть видосик в поездке. Но современный софт не оставляет шансов — работать на нем ныне уже практически невыносимо. Ну или если у вас ну очень спокойный темперамент, то может и пойдет. Установка SSD помогла не особо.

    И тут типичный гик скажет: так поставь на него Linux, все залетает! (нет). Формально если у вас под виндой тормозит Firefox или Chrome, то в Linux будет картина плюс-минус та же самая. К этому добавляется то, что на моем нетбуке свежие KDE и Gnome ведут себя еще менее отзывчиво чем винда, с секундными лагами интерфейса «нажал-нажалось». В общем, наш удел MATE desktop, консоль, vim, музычка, иногда видосики, какие потянут. Но суть не в этом.

    В чем же проблема?


    Итак, установлен Debian 8, закрытый драйвер nVidia, душа просит дальнейшей эстетики, установлен plymouth. Но вместо симпатичной загрузочной анимации в лучшем случае видим три текстовые точки и ползущий снизу прогрессбар



    В худшем сообщение

    error : unexpectedly disconnected from boot status deamon

    Первый подход


    Первым делом в wiki дебиана подсказывают, что это все из-за закрытых драйверов, нету там framebuffer адекватного, поэтому поставь uvesafb.

    Расписывать не буду, так как подробная инструкция приведена здесь: wiki.debian.org/ru/Plymouth

    Идея в целом понятна, способ в частности позволяет поставить более высокое разрешение в системной консоли и т.д.

    Но вот незадача, plymouth в Debian 8 версии 0.9.0 по прежнему отказывается работать. Либо текстовая тема, либо ошибка. Я перелопатил с десяток статей по настройке правильных параметров для uvesafb, но увы.

    Второй подход


    Следующий этап, надо дебажить. В общем благодаря дебагу и гуглению удалось напороться на следующий тред: www.linux.org.ru/forum/desktop/12848541

    Если вкратце, проблема в связке plymouth и uvesafb. Последнюю вполне можно использовать с ним, но она не ставит своему устройству флаг boot_vga — т.е. первичный экран, с которого происходит загрузка. Plymouth же очень хочет видеть этот флаг и не найдя его обламывается с той самой ошибкой.

    Дальнейшее гугление позволило найти также чуть более адекватный патч:

    Index: plymouth-0.9.0/src/libply-splash-core/ply-device-manager.c
    ===================================================================
    --- plymouth-0.9.0.orig/src/libply-splash-core/ply-device-manager.c
    +++ plymouth-0.9.0/src/libply-splash-core/ply-device-manager.c
    @@ -101,12 +101,13 @@ device_is_for_local_console (ply_device_
        * card the kernel is using for its console. */
       device_path = udev_device_get_syspath (device);
       asprintf (&bus_device_path, "%s/device", device_path);
    +  ply_trace ("Testing device path %s\n", bus_device_path);
       bus_device = udev_device_new_from_syspath (manager->udev_context, bus_device_path);
     
       boot_vga = udev_device_get_sysattr_value (bus_device, "boot_vga");
       free (bus_device_path);
     
    -  if (boot_vga != NULL && strcmp (boot_vga, "1") == 0)
    +  if (boot_vga == NULL /* framebuffer case */ || strcmp (boot_vga, "1") == 0)
         for_local_console = true;
       else
         for_local_console = false;
    

    Дело за малым — пересобрать пакет.

    Решение


    Первым делом нам понадобятся devscripts и build-essential

    $ apt install devscripts build-essential

    Далее собственно сорцы plymouth:

    
    $ apt-get source plymouth
    $ cd plymouth-0.9.0
    

    Тут нам надо добавить новую запись в debian/changelog или просто поправить самую последнюю, чтобы номер версии отличался от официального, иначе при следующем обновлении системы к вам опять вернется родной пакет без патча. Например 0.9.0-9+fbfix.

    Далее кладем патч в папку debian/patches под любым именем, например fix-bootvga-for-uvesafb.patch, не забываем также добавить его в файл debian/patches/series.

    Далее все как обычно, выполняем:

    
    $ dpkg-buildpackage -us -uc -nc -b
    

    Ставим полученные deb, ставим понравившуюся тему.

    
    $ sudo plymouth-set-default-theme -R spacefun
    $ sudo update-grub2
    $ sudo update-initramfs -u
    

    Радуемся красивым сплэшам при загрузке и выключении компьютера.



    Да, если вы не обратили внимание, фикс должен также помочь починить plymouth для raspberry pi и возможно других миниатюрных машинок.
    Share post

    Comments 28

      +2
      На кой черт он нужен? То время которое он потратит на загрузку себя и картинки, лучше потратить на загрузку необходимого же.

      ntfs@ntfs-GB-BSi3A-6100 ~ $ uptime
      01:30:58 up 2 days, 3:09, 2 users, load average: 0,56, 0,56, 0,38

      • UFO just landed and posted this here
          0
          Топик про нетбук. Не исключено, что у автора такая же ситуация, как была у меня: у знакомой есть нетбук, которому не хватает мощности. после установки 12.04+LibreOffice+Firefox+Chrome, машинка стала работать значительно шустрее, чем на 7. Не думаю, что кукольных дел мастер будет считать консольный вывод «красивее и приятнее»
            0
            Не верю я в «значительно шустрее». Тормозит не сама система, а приложения, потому что слишком тяжелы для проца. Хоть заоптимизируйся.
              0
              Приложения — это и есть сама система.

              Под торможением чаще всего подразумевается временная задержка между нашим действием и реакцией системы. Ну или просто временные задержки.
              Это можно понять примерах нескольких задач на нескольких ПК:

              Вот представьте себе КОМПИЛЯЦИЮ приложения. На эталонном 8-ядерном Core i7 с технологиями гиппер-триппер, это приложение скомпилируется за 5 минут. На другом 2-ядерном Атлоне, за 10 минут. Но никому не придет в голову назвать это «тормозами», верно? Просто процессор медленнее компилирует.

              А теперь представьте себе Unity или Gnome3. На эталонном Core i7, после нажатия мышкой на кнопке меню (или как там его, Activities) меню открывается мгновенно, на другом 2-ядерном Атлоне спустя две секунды, и как раз ЭТО мы называем тормозами.
              Но ведь меню отображается корректно, без тормозов. Задержка не в отрисовке, а именно во времени реакции системы.

              И вот на время реакции системы как раз и влияет оптимизация. Как приложения, так и ядра, поскольку приложение работает через вызовы ядра.

              Могу углубиться в детали.

              Есть такое понятие в ОС, как шедулер задач. Это небольшой модуль многозадачного ядра, который выделяет всем работающим процессам небольшие кванты времени на их исполнение. Это время может выделяться равными порциями, или в зависимости от аппетита процесса, или в зависимости от его приоритета, или в зависимости от еще много чего. В зависимости от частоты выделения кванта времени этому процессу, зависит его плавность, но еще это влияет на потребление ресурсов CPU, если процесс ничего не выполняет, но время ему все равно передается. Приведу пример на гипотетическом языке, чтобы вы поняли о чем речь:

              repeat
              1. ReadMouseCursorPosition;
              2. Delay(100);
              3. DrawMouseCursor;
              4. Delay(100);
              5. ReadKeyboard;
              6. Delay(100);
              7. DrawKeyboardSymbolOnDisplay;
              8. Delay(100);
              until

              Так вот чем МЕНЬШЕ будет значение Delay, и чем быстрее (оптимизированнее) будет ReadKeyboard, тем плавнее будет двигаться курсор мыши, поскольку чаще будет опрашиваться. Но вместе с тем, чем меньше будет значение Delay, тем активнее будет работать процессор, поскольку независимо от того, будет курсор двигаться или стоять на месте — процессор будет переключаться на эту задачу. Как-то так.

              Скажу на своем примере. После перекомпиляции ядра и игре с параметрами шедулера и CPU, система работает раза в полтора-два отзывчивее.
                0
                Статью по диагонали читали? Unity, Gnome, KDE имеют очень заметный лаг просто при пользовании интерфейсом. У винды интерфейс отзывчивей себя ведет. Chrome если тормозит в винде, то в Linux он менее тормозным не становится. Тяжелые пакеты и загружаются медленно и интерфейс имеют неотзывчивый.
                Учитывая что платформе уже где-то лет 8-9, ковыряния с шедулером и перекомпиляции просто не стоят свечь. Кстати FreeBSD на нем пересобирал все полностью из портов, на скорости отразилось чуть.
                  0
                  Chrome тоже стал отзывчивее. Памяти конечно меньше жрать не стал, но перекомпиляция ядра отразилась на лагах при скроллинге, открытии новой вкладки и отображении контента с большим количеством JS.

                  Ну и плюс ко всему, стала быстрее грузиться, выключаться, перестала терять вафлю и так далее.
                  Отзывчивее стали все интерактивные приложения. Ессесно gcc быстрее работать не стал :)
            0
            Только заставить их работать ламерам не дано ;)

            А вообще, i did it for lulz. Да какая разница зачем оно мне?
          +2
          У меня в годы баловства с Linux системами были другие проблемы. Я хотел, чтобы загрузочная картинка не мерцала в консоль на финальных этапах загрузки. На сколько я понимаю, по умолчанию в дистрибутивах, будь то UBUNTU, например, до сих пор сие не побеждено и, если загружать систему с более-менее медленного HDD, в завершающем этапе перед стартом X-server оно все равно моргнет в консоль, вывалив весь загрузочный лог на экран на пару секунд. Есть ли способ победить это?
            0
            SSD. Чё-то там моргнуло, вводишь пароль, моргнули квадратики с иконками (KDE), появился рабочий стол. Всё.
              +1
              Мне весь этот лог загрузки вообще нравился больше чем сплеш экраны. Была в этом какая-то крутизна :)
                +1
                Да, лучше сделать то же самое на винде. И убрать графическую часть по минимуму. Только консоль и Волков Коммандер )
                  0
                  В винде можно тоже включить более подробный вывод этапов загрузки:

                  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
                  "VerboseStatus"=dword:00000001

                0
                оно все равно моргнет в консоль, вывалив весь загрузочный лог на экран

                Под eOS на медленном ноутбуке такого не замечал, хотя перед стартом иксов оно всё-же моргает в tty. quiet в грабе прописан?
                Алсо, соглашусь с hzs, используйте SSD.

                Загрузка Arch с SSD
                image

                  0
                  Почему у вас так долго грузится ядро? Вы что до сих пор юзаете рамдиск?
                +1
                Как ни странно, старое железо редко упирается в процессор. Обычно проблемы возникают из-за малого количества памяти и низкого быстродействия дисковой системы.
                Именно поэтому приходится отказываться от KDE — оно не будет быстро работать на машинах с менее чем 4Гб памяти. XFce в последнее время тоже разжирел, так что оптимальный вариант на данный момент — LXDE, благо его пока ещё не успели перевести на Qt (но грозятся, что уже вот-вот).
                На LXDE можно собрать систему, отжирающую меньше 250Мб оперативки при полной загрузке, это примерно как Windows XP. Свободная память особенно важна, если планируется использовать современные браузеры, которые жрут её в невообразимых количествах.
                Далее дисковая система. SSD помогает, но только при условии, что количество операций записи сведено к минимуму. После монтирования файловой системы с атрибутами noatime/nodiratime и отключения журналирования, время загрузки ОС и старта программ снижается весьма существенно.
                Затем нужно выбрать браузер. Поскольку современный браузер — это самая тормознутая штука из всех известных человечеству, его выбор крайне важен. Firefox не годится, т.к. он и на современных-то машинах подлагивает — там с обработкой событий UI явные проблемы. Тем более не годится Chromium: я не знаю, что там с ним майнтейнеры сотворили, но под Debian это самый медленный из браузеров. Та же Opera по ощущениям вдвое быстрее работает, хоть и на том же самом движке.
                Можно использовать специальные браузерные сборки типа Epiphany и Palemoon — они тормозят несколько меньше, но зато там прилично глюков и странностей.
                Радикальное решение проблемы — использование нативных программ для веб-сервисов, а браузера собственно для просмотра html-страничек. Так, для чтения почты вместо совершенно тормознутого GMail использовать Sylpheed или иной легковесный почтовый клиент. Вместо соцсетей — RSS-клиент, куда грузятся предварительно сформированные ленты.
                А собственно для html неплохо подходит браузер links2 в графическом режиме. Да, Хабр тоже из него отлично читается, пусть и в режиме read only. И даже картинки все видны без проблем.
                  0
                  Попробуйте Enlightenment — на нём ещё легче получится.
                  Я на компьютере с всего 256 оперативки его запускал, ещё и в Google что-то искал, то ли через NetSurf, то ли через Dillo.
                  А сам комп — как клиент RDP используется, с принтером подключенным.
                  0
                  Очевидные места для оптимизации: в районе графики (кривой драйвер даже топовой дискретной видеокарте будет тупить до невозможности), zram для экономии памяти.

                  Тем, кто говорит, что «бегущие строчки не тормозят систему» — тормозят. Причина в том, скроллинг — это маленькое видео (надо перерисовывать весь экран), так что «бегущие строчки» тормозят систему куда больше, чем статичная картинка с маленькой анимацией.
                    0
                    Если говорить про мой случай, то памяти там 4 ГБ, видеокарта nVidia ION. Сам MATE Desktop бегает вполне шустро, нативные приложения тоже нормально по отзывчивости. А вот Chrome плюс современный сайт == пытка. KDE или Gnome вполне могут из-за драйвера видео тормозить, но я что-то подозреваю что все-таки слишком слаб сам проц.
                      0
                      Мсье не знает как работает вывод stdout ?)

                      1. Тормозит не вывод на экран, а подгрузка картинки + ее распаковка + ее вывод.
                      2. Вывод при этом все равно идет, только не на видимую область, так что работа двойная.
                      3. Если процесс выполняется быстрее чем происходит вывод на экран — он завершается и система выполняется далее. Вы можете сами в этом убедиться, если на каком-нить удаленном сервере с тормознутым интернетом выполните find;date > current.txt и замеряете разницу между временем завершения процесса и завершением получения вами последнего символа.
                      4. Более скажу, на секунду загружает даже переключение режима графики. В этом вы можете убедиться если переконфигурите grub без всяких мокрописечных фонов и графики 1920х1080.

                      Чтобы понять очевидные места для оптимизации, надо понять что именно не нравится в работе системы.
                        0
                        Ждем подробную статью с цифрами, графиками, замерами скорости загрузки с plymouth и без в разных графических режимах.
                          0
                          Зачем? Это все уже давно прохавано. systemd-analyze blame в помощь.
                            0
                            Ок, напишите про это.
                              0
                              Про что написать? Либо я вас не понимаю, либо вы меня.

                              systemd-analyze blame
                              6.873s dev-sda2.device
                              2.144s abrtd.service
                              2.129s ModemManager.service
                              2.125s NetworkManager.service
                              2.002s dnf-makecache.service
                              1.772s mcelog.service
                              1.771s gssproxy.service
                              1.738s bluetooth.service
                              1.616s packagekit.service
                              1.409s proc-fs-nfsd.mount
                              1.093s plymouth-start.service
                              1.072s fedora-readonly.service
                              947ms systemd-udevd.service
                              935ms accounts-daemon.service
                              919ms systemd-tmpfiles-setup-dev.service
                              755ms polkit.service
                              753ms iio-sensor-proxy.service
                              701ms systemd-rfkill@rfkill1.service
                              660ms abrt-ccpp.service
                              478ms systemd-journald.service
                              471ms cups.service
                              453ms dev-sda3.swap
                              439ms gdm.service

                              Что из строчки «1.093s plymouth-start.service» вам не понятно? Сколько будет 6.873s минус 1.093s?
                                0
                                Как это согласуется с тем, что systemd грузит сервисы параллельно? На каком основании вы просто вычитаете? Давайте пруфы что без плимута серьезно быстрее грузится.
                                  0
                                  Что вы подразумеваете под «серьезно быстрее»?

                                  На Cel 2840 \ eMMC — 1 секунда, на Core i3 6100 \ PCIE SSD — 68 мс, на Cel 353 \ древний SSD (Asus EeePC 4G) — 12 секунд. Могу еще на Pentium 2020\SSD SATA3 попробовать, если интересно.

                                  Но я до сих пор не могу понять, какие пруфы вам нужны того, что с отключенным сервисом система грузится быстрее, чем с включенным?

                                  Эти статьи про оптимизацию ходили в интернете еще лет 7 назад.
                                    0
                                    Я про сравнение, а вы мне какие-то цифры кидаете. Где сравнение до и после?
                                    — 48
                                    — 25
                                    — что 25?
                                    — а что 48?
                        0
                        Так-то скроллинг в текстовом режиме делается аппаратно со времён MDA (т.е. с 1981 г.). Просто не все этим заморачиваются. Зачем, если сервак включается один раз, три года работает, после чего уходит на свалку?

                      Only users with full accounts can post comments. Log in, please.