Итак, лежит у меня старый (уже) нетбук 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 и возможно других миниатюрных машинок.
Комментарии (28)
vectro73
01.04.2017 10:41+2У меня в годы баловства с Linux системами были другие проблемы. Я хотел, чтобы загрузочная картинка не мерцала в консоль на финальных этапах загрузки. На сколько я понимаю, по умолчанию в дистрибутивах, будь то UBUNTU, например, до сих пор сие не побеждено и, если загружать систему с более-менее медленного HDD, в завершающем этапе перед стартом X-server оно все равно моргнет в консоль, вывалив весь загрузочный лог на экран на пару секунд. Есть ли способ победить это?
hzs
01.04.2017 20:44SSD. Чё-то там моргнуло, вводишь пароль, моргнули квадратики с иконками (KDE), появился рабочий стол. Всё.
EnigMan
01.04.2017 23:44+1Мне весь этот лог загрузки вообще нравился больше чем сплеш экраны. Была в этом какая-то крутизна :)
mad_god
02.04.2017 01:23+1Да, лучше сделать то же самое на винде. И убрать графическую часть по минимуму. Только консоль и Волков Коммандер )
phoenixee
02.04.2017 12:31В винде можно тоже включить более подробный вывод этапов загрузки:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
"VerboseStatus"=dword:00000001
Sacra
02.04.2017 12:31оно все равно моргнет в консоль, вывалив весь загрузочный лог на экран
Под eOS на медленном ноутбуке такого не замечал, хотя перед стартом иксов оно всё-же моргает в tty. quiet в грабе прописан?
Алсо, соглашусь с hzs, используйте SSD.Загрузка Arch с SSD
Alexey2005
03.04.2017 00:46+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. И даже картинки все видны без проблем.Magister7
07.04.2017 23:29Попробуйте Enlightenment — на нём ещё легче получится.
Я на компьютере с всего 256 оперативки его запускал, ещё и в Google что-то искал, то ли через NetSurf, то ли через Dillo.
А сам комп — как клиент RDP используется, с принтером подключенным.
amarao
03.04.2017 14:04Очевидные места для оптимизации: в районе графики (кривой драйвер даже топовой дискретной видеокарте будет тупить до невозможности), zram для экономии памяти.
Тем, кто говорит, что «бегущие строчки не тормозят систему» — тормозят. Причина в том, скроллинг — это маленькое видео (надо перерисовывать весь экран), так что «бегущие строчки» тормозят систему куда больше, чем статичная картинка с маленькой анимацией.
divanikus
03.04.2017 16:23Если говорить про мой случай, то памяти там 4 ГБ, видеокарта nVidia ION. Сам MATE Desktop бегает вполне шустро, нативные приложения тоже нормально по отзывчивости. А вот Chrome плюс современный сайт == пытка. KDE или Gnome вполне могут из-за драйвера видео тормозить, но я что-то подозреваю что все-таки слишком слаб сам проц.
ntfs1984
04.04.2017 02:45Мсье не знает как работает вывод stdout ?)
1. Тормозит не вывод на экран, а подгрузка картинки + ее распаковка + ее вывод.
2. Вывод при этом все равно идет, только не на видимую область, так что работа двойная.
3. Если процесс выполняется быстрее чем происходит вывод на экран — он завершается и система выполняется далее. Вы можете сами в этом убедиться, если на каком-нить удаленном сервере с тормознутым интернетом выполните find;date > current.txt и замеряете разницу между временем завершения процесса и завершением получения вами последнего символа.
4. Более скажу, на секунду загружает даже переключение режима графики. В этом вы можете убедиться если переконфигурите grub без всяких мокрописечных фонов и графики 1920х1080.
Чтобы понять очевидные места для оптимизации, надо понять что именно не нравится в работе системы.divanikus
04.04.2017 03:16Ждем подробную статью с цифрами, графиками, замерами скорости загрузки с plymouth и без в разных графических режимах.
ntfs1984
04.04.2017 17:45Зачем? Это все уже давно прохавано. systemd-analyze blame в помощь.
divanikus
04.04.2017 18:15Ок, напишите про это.
ntfs1984
04.04.2017 19:18Про что написать? Либо я вас не понимаю, либо вы меня.
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?divanikus
04.04.2017 21:02Как это согласуется с тем, что systemd грузит сервисы параллельно? На каком основании вы просто вычитаете? Давайте пруфы что без плимута серьезно быстрее грузится.
ntfs1984
04.04.2017 23:09Что вы подразумеваете под «серьезно быстрее»?
На Cel 2840 \ eMMC — 1 секунда, на Core i3 6100 \ PCIE SSD — 68 мс, на Cel 353 \ древний SSD (Asus EeePC 4G) — 12 секунд. Могу еще на Pentium 2020\SSD SATA3 попробовать, если интересно.
Но я до сих пор не могу понять, какие пруфы вам нужны того, что с отключенным сервисом система грузится быстрее, чем с включенным?
Эти статьи про оптимизацию ходили в интернете еще лет 7 назад.divanikus
04.04.2017 23:53Я про сравнение, а вы мне какие-то цифры кидаете. Где сравнение до и после?
— 48
— 25
— что 25?
— а что 48?
vanxant
04.04.2017 03:41Так-то скроллинг в текстовом режиме делается аппаратно со времён MDA (т.е. с 1981 г.). Просто не все этим заморачиваются. Зачем, если сервак включается один раз, три года работает, после чего уходит на свалку?
ntfs1984
На кой черт он нужен? То время которое он потратит на загрузку себя и картинки, лучше потратить на загрузку необходимого же.
ntfs@ntfs-GB-BSi3A-6100 ~ $ uptime
01:30:58 up 2 days, 3:09, 2 users, load average: 0,56, 0,56, 0,38
pfemidi
Нафига эти картинки при загрузке/выгрузке? Я наоборот их всегда выключаю (в Fedora они by default) и делаю так, чтобы были «бегущие строки загрузки ядра и сервисов», так и красивее, и приятнее, и видно что грузится, а что нет. Картинки для ламеров!
nett00n
Топик про нетбук. Не исключено, что у автора такая же ситуация, как была у меня: у знакомой есть нетбук, которому не хватает мощности. после установки 12.04+LibreOffice+Firefox+Chrome, машинка стала работать значительно шустрее, чем на 7. Не думаю, что кукольных дел мастер будет считать консольный вывод «красивее и приятнее»
divanikus
Не верю я в «значительно шустрее». Тормозит не сама система, а приложения, потому что слишком тяжелы для проца. Хоть заоптимизируйся.
ntfs1984
Приложения — это и есть сама система.
Под торможением чаще всего подразумевается временная задержка между нашим действием и реакцией системы. Ну или просто временные задержки.
Это можно понять примерах нескольких задач на нескольких ПК:
Вот представьте себе КОМПИЛЯЦИЮ приложения. На эталонном 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, система работает раза в полтора-два отзывчивее.
divanikus
Статью по диагонали читали? Unity, Gnome, KDE имеют очень заметный лаг просто при пользовании интерфейсом. У винды интерфейс отзывчивей себя ведет. Chrome если тормозит в винде, то в Linux он менее тормозным не становится. Тяжелые пакеты и загружаются медленно и интерфейс имеют неотзывчивый.
Учитывая что платформе уже где-то лет 8-9, ковыряния с шедулером и перекомпиляции просто не стоят свечь. Кстати FreeBSD на нем пересобирал все полностью из портов, на скорости отразилось чуть.
ntfs1984
Chrome тоже стал отзывчивее. Памяти конечно меньше жрать не стал, но перекомпиляция ядра отразилась на лагах при скроллинге, открытии новой вкладки и отображении контента с большим количеством JS.
Ну и плюс ко всему, стала быстрее грузиться, выключаться, перестала терять вафлю и так далее.
Отзывчивее стали все интерактивные приложения. Ессесно gcc быстрее работать не стал :)
divanikus
Только заставить их работать ламерам не дано ;)
А вообще, i did it for lulz. Да какая разница зачем оно мне?