Чтото тормозит загрузку линукса?

а на devuan'е проблем нету ;)

grub к этому моменту уже работал с sda4. Это значит, что диск уже полностью готов.

grub к этому моменту уже работал с sda4. Это значит, что диск уже полностью готов.

Абсолютно неверно. GRUB работает с дисками через вызовы BIOS (ну или UEFI). Linux работает с устройствами напрямую, с помощью своих драйверов. Поэтому, когда Linux получает управление, он переинициализирует контроллеры и опрашивает диски заново. Это может занимать время.

Так понял, что он ждет появления даного устройства в /dev?

Почти. Он ждёт, пока udev даст отмашку. Устройство появляется (см. выше), udev его замечает, опрашивает, прогоняет через правила, и только после этого помечает его как пригодное к использованию. Это тоже может занимать какое-то время.

А что происходит в это время? Как посмотреть, чем в это время udev занят?

Хороший вопрос. Попробуй увеличить вербозность логов udev — я не помню, как это делать.

На devuan'е о быстрой загрузке и мечтать не приходится, так что таких проблем там действительно нет ;)

он уже примонтирован (mounted) в это время.

А чем тогда занимется device.sda4

Чем угодно. Может проверяет диск утилитой fsck. А может это просто общее время обращения к диску разных демонов. Я не знаю. Но с чего ты решил, что время на твоих графиках, занимаемое dev-sda4 — это именно монтирование диска? В логе команды mount работают без пауз. Кроме того, посмотрел сейчас в сети, у всех dev-sdaN занимает минимум несколько секунд. Ты же не будешь утверждать, что у всех диск так долго монтируется.

Изменение около 0.5с.

А стоит ли из-за полусекунды отказываться от проверки диска и рисковать данными? Я бы вернул 1.

Я так и сделал.

Чем угодно. Может проверяет диск утилитой fsck.

Это ведь работа с фс. А монтирование (включая fsck) действительно происходит очень быстро.

Те всеровно непонятно что происходит за эти несколько секунд.

всеровно непонятно что происходит за эти несколько секунд

Так intelfx тебе же предложил увеличить детализацию логов udev. Гугл вроде советует udevadm monitor, если я всё правильно понял, например в этой статье.

Ну и вообще посмотреть разные другие логи, может и в них увеличить детализацию по возможности. Я бы обратил внимание на kde, а потом на wifi, как уже говорил.

Кроме того, ошибки пофиксил бы. Если службы, которые сбоят из-за ошибок, тебе не нужны, так отключи их, — быстрее будет. А если нужны, то исправь. В любом случае при возникновении ошибки часто тратится дополнительное время, например на повторные попытки найти что-то или прочитать какой-то файл.

Ну и ненужные сервисы можно поотключать. Но это надо делать осторожно, чтоб не стало хуже. На эту тему тоже гуглятся статьи, например эта, и не только. Только, беря на вооружение подобные статьи, я бы тыщу раз подумал над каждым советом. Может автору статьи что-то из перечисленного и не нужно, а для тебя может оказаться критичным.

Ну и ненужные сервисы можно поотключать. Но это надо делать осторожно, чтоб не стало хуже. На эту тему тоже гуглятся статьи, например эта, и не только. Только, беря на вооружение подобные статьи, я бы тыщу раз подумал над каждым советом. Может автору статьи что-то из перечисленного и не нужно, а для тебя может оказаться критичным.

Что-то мне это все напоминает...

а...

https://lifehacker.ru/2017/01/30/disable-windows-services/

На devuan'е о быстрой загрузке и мечтать не приходится, так что таких проблем там действительно нет ;)

Ну-да, ну-да :)

У ТС крыса, как понял 2 минуты.

У меня на ноуте от нажатия кнопки включения питалова до загрузки крысы (с учетом ввода пароля LUKS на хомяк, имени пользователя и его пароля) - 30 сек...

:)))

Ну и ненужные сервисы можно поотключать.

Что-то мне это все напоминает... а... https://lifehacker.ru/2017/01/30/disable-windows-services/

Ну, это естественно, что разные десктопные оси «из коробки» (а у ТС'а — Mint, типичная изкоробочная ось) ведут себя похоже. Другие оси могут вести себя прямо противоположно: не запускать ничего, кроме самого необходимого. Оба подхода имеют свои достоинства и недостатки. Для простого пользователя (не красноглазика) лучше подойдёт изкоробочный подход. А так, чтоб всё, что надо, из коробки работало, а что не надо — нет, так это свой дистр пилить надо. Но проще ведь включить нужные или отключить ненужные сервисы.

И да, я совсем не горячий поклонник системд, но в данном случае он тут ни при чём. На sysv было бы то же самое.

Наблюдаю чушь... На моменте

[    1.866939]  sda: sda1 sda2 sda3 sda4
[    1.867282] sd 3:0:0:0: [sda] Attached SCSI disk

Startup finished in 4.085s (kernel) + 19.171s (userspace) = 23.256s

что разные десктопные оси «из коробки» (а у ТС'а — Mint, типичная изкоробочная ось) ведут себя похоже

А что там особенного отключать то?

cups ?

там, если не ошибаюсь по дефолту ни sshd ни exim'а в загрузке нет...

да и вся эта троица даже на железе начала века фатально загрузку десктопа не тормозила

30

Startup finished in 4.085s (kernel) + 19.171s (userspace) = 23.256s

ну вот осталось тебе прибавить время на bios и grub чтоб признать свою не правоту на счет неспешности загрузки devuan :)))

Это в любом случае сравнение жопы с пальцем, пригодное только для того, чтобы надувать ЧСВ технолуддитов (ну или наоборот). Ты сравниваешь непонятно что непонятно с чем на непонятно каком железе. Если подготовишь стенд — с удовольствием померяюсь, правда, systemd всё равно не про скорость загрузки, это всё сугубо побочка.

что разные десктопные оси «из коробки» (а у ТС'а — Mint, типичная изкоробочная ось) ведут себя похоже

А что там особенного отключать то?

А шут его знает. Судя по логам, там readahead что-то не находит. По идее, он должен ускорять работу. Но может и тормозить загрузку. Можно его попробовать отключить, например, и посмотреть, что будет (ничего страшного точно не произойдёт, только время запуска системы и приложений может измениться в ту или иную сторону).

Возможно, ещё что-то ненужное имеется, я детально логи не анализировал.

по дефолту ни sshd

Вот sshd я у себя как раз наоборот всегда включаю первым делом. Про уязвимости в sshd я ничего не слышал, систему тоже не особо грузит, а вот резервный вход по сетке, если вдруг иксы зависнут и даже на ctrl+alt+backspace перестанут реагировать, иметь полезно, имхо.

надувать ЧСВ

самокритично так :)

Напомню

intelfx> На devuan'е о быстрой загрузке и мечтать не приходится

:)

Про уязвимости в sshd я ничего не слышал, систему тоже не особо грузит

я сразу порт дефолтный меняю и проверяю что руту вход запрещен

наверное у меня паранойя :)))

Такое ощущение, что systemd прибавляет туда еще и время перед монтированием корневой фс (напр когда происходит инициализация usb оборудования).

https://text-share.com/view/6ab40961

~_> systemd-analyze 
Startup finished in 4.979s (kernel) + 13.691s (userspace) = 18.670s
~_> systemd-analyze blame
          4.943s dev-sda4.device
          3.590s NetworkManager.service
          3.071s grub-common.service
          3.054s irqbalance.service
          2.579s console-setup.service
          2.310s loadcpufreq.service
          2.203s gpu-manager.service
          1.972s networking.service
          1.464s binfmt-support.service
          1.391s alsa-restore.service
          1.245s console-kit-log-system-start.service
          1.212s iio-sensor-proxy.service
          1.211s systemd-user-sessions.service
          1.068s thermald.service
           910ms speech-dispatcher.service
           882ms systemd-logind.service
           876ms polkitd.service
           870ms hddtemp.service
           624ms systemd-udevd.service
           605ms keyboard-setup.service
           595ms setvtrgb.service
           550ms rsyslog.service
           471ms lm-sensors.service
           469ms systemd-tmpfiles-setup-dev.service
           442ms dns-clean.service
           431ms systemd-tmpfiles-clean.service
           384ms dev-mqueue.mount
           380ms dev-hugepages.mount
           380ms sys-kernel-debug.mount
           377ms systemd-journald.service
           358ms proc-sys-fs-binfmt_misc.mount

Такое ощущение, что systemd прибавляет туда еще и время перед монтированием корневой фс (напр когда происходит инициализация usb оборудования).

Шут его знает, что он туда прибавляет. А чем нынешняя скорость не устраивает? 23 секунды вроде не так уж медленно? Но если хочется ускорить, я бы с readahead поэкспериментировал. Только её надо тестировать не только на влияние на скорость загрузки, но и на влияние на скорость запуска приложений. Потому что при отключении первое может ускориться, а второе — замедлиться.

Startup finished in 4.085s (kernel) + 19.171s (userspace) = 23.256s

Startup finished in 4.979s (kernel) + 13.691s (userspace) = 18.670s

И чего поотключал?

Про уязвимости в sshd я ничего не слышал

я сразу порт дефолтный меняю

Разумно. Главное, потом не забыть, на какой.

и проверяю что руту вход запрещен

А это зачем? Ведь su или sudo можно и после входа выполнить?

Из самого заметного - readahead, brltty, accountservice, ntp, openvpn, modemmanager, убрал лишний swap, тккак он подключается из initrd

и проверяю что руту вход запрещен

А это зачем? Ведь su или sudo можно и после входа выполнить?

Сканеры-боты долбятся на root@ и другие распространённые логины. Зачем их искушать? А юзернейм они не знают.

readahead

Этот сервис теоретически должен заранее подгружать часто используемые файлы. Я не очень верю в эффективность подобных оптимизаций, но хрен его знает... я бы потестил, не стали ли медленнее после этого загружаться другие программы.

ntp

А вот это имхо зря. Автоматически синхронизировать часы на компе — штука полезная.

убрал лишний swap, тккак он подключается из initrd

А что за «лишний»? И присутствует ли он после убирания лишнего?

Сканеры-боты долбятся на root@ и другие распространённые логины. Зачем их искушать? А юзернейм они не знают.

Тоже верно. Я всегда воспринимал пароль, а не логин, как защиту. Но, с другой стороны, в дополнение к паролю почему бы и ему не выполнять ещё и защитную функцию?

swap подключается еще на моменте initrd (скорее всего установщик минта позаботился). А в fstab из рутфс он просто дублировался.

А по поводу ntp - он ожидал подключения во время загрузки. ИМХО гораздо проще перенести его разовый запуск куда нибудь в крон.

А без readahead мне просто спокойнее. Всегда напрягали демоны, которые привносят плавающие сайдэффекты.

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

swap подключается еще на моменте initrd (скорее всего установщик минта позаботился). А в fstab из рутфс он просто дублировался.

Кстати да, не обратил внимания, что он у тебя в fstab был прописан. У меня такого нет. Хотя я не думаю, что на этапе чтения fstab он повторно монтируется. Впрочем, в любом случае, в fstab он не нужен.

А по поводу ntp - он ожидал подключения во время загрузки. ИМХО гораздо проще перенести его разовый запуск куда нибудь в крон.

Тоже верно. Хоть legolegs и предупредил о возможных проблемах. Но это только если они возникнут. Да и в течение суток (если вызов ntpdate или sntp из крона сделать раз в сутки) время вряд ли собьётся даже на секунду.

Всегда напрягали демоны, которые привносят плавающие сайдэффекты.

Согласен.