Ядро, systemd и потерянное время

Затем systemd оживает, но начинает писать

Нет, это dmesg, который сбрасывается в лог весь сразу, поэтому нет никакого потерянного времени. По поводу двухминутной паузы смотри systemd-analyze blame.

ты ведь в дебилизме замечен не был, создаешь впечатление адекватного человека

ЗАЧЕМ ТЕБЕ systemd?

Понятно. Тогда пошёл патчить xdm. А то в апстриме его никак не пропатчат. В итоге systemd не дожидается ответа, и перезапускает его в бесконечном цикле. Пришлось выставить бесконечный таймаут. В целом работает, но блокирует «systemd-analyze blame»:

# systemd-analyze blame
Bootup is not yet finished (org.freedesktop.systemd1.Manager.FinishTimestampMonotonic=0).
Please try again later.
Hint: Use 'systemctl list-jobs' to see active jobs

systemd вкручивают в стабильные бинарные дистрибутивы.

Пропатчил. systemd-analyze пишет, что проблема на стороне ядра:

# systemd-analyze
Startup finished in 2min 15.629s (kernel) + 19.226s (userspace) = 2min 34.856s
graphical.target reached after 19.216s in userspace

Перефразирую анона:

ты ведь в дебилизме замечен не был, создаешь впечатление адекватного человека

ЗАЧЕМ ТЕБЕ бинарные дистрибутивы? Тем более с 1700 райзеном.

Чтобы поменьше красноглазить.

А чо там красноглазить? У меня Ryzen 7 2700 чуток разогнанный, обновления Gentoo в фоне вообще не замечаю. Основные конфиги взял со старой машины, проводиться пришлось только с конфигурацией ядра.

Твоя проблема гуглится по запросу: google://random: crng init done.

И она достаточно распространена.

Я найду. Я ж и в Slackware половину библиотек и софта гнал впереди поезда. А потом пришёл в ужас. Потому, что руки не идеально ровные, и местами вылезало неожиданное. Хотя в целом всё работало. LFS с ядерной консолью у меня получается лучше ультракрасноглазить.

А в стабильных бинарных дистрибутивах я библиотеки не трогаю.

А в стабильных бинарных дистрибутивах я библиотеки не трогаю.

Так и я их в Gentoo не трогаю. Поставил amd64 в keywords глобально, для всяких llvm, mesa и xorg-server и ядра - ~amd64, чтобы получать свежие версии.

Значит, всё-таки ядро чего-то ждёт...

Это вместе с initramfs, если я не ошибаюсь. Нет простоев в dmesg?

Энтропию оно собирает, см. https://unix.stackexchange.com/a/442744

Он откатился на ядро, где был какой-то баг.

Спасибо, но зависание ядра происходит после разных строчек. Например, после

[    9.594722] usb-storage 1-6:1.0: USB Mass Storage device detected
[    9.595958] scsi host10: usb-storage 1-6:1.0
[   10.659241] scsi 10:0:0:0: Direct-Access     ADATA    HDD SH93              PQ: 0 ANSI: 0
[   10.660595] sd 10:0:0:0: [sdc] 976773168 512-byte logical blocks: (500 GB/466 GiB)
[   10.661729] sd 10:0:0:0: [sdc] Write Protect is off
[   10.662637] sd 10:0:0:0: [sdc] Mode Sense: 03 00 00 00
[   10.662756] sd 10:0:0:0: [sdc] No Caching mode page found
[   10.663662] sd 10:0:0:0: [sdc] Assuming drive cache: write through
[   10.701661]  sdc: sdc1
[   10.703317] sd 10:0:0:0: [sdc] Attached SCSI disk

Тебе уже писали про буферизацию.

Всё-таки причина была в drivers/char/random.c, спасибо.

Пропатчил ядро.

# systemd-analyze
Startup finished in 6.926s (kernel) + 22.651s (userspace) = 29.577s
graphical.target reached after 22.640s in userspace

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

Кстати, если кому вдруг нужен этот мегапатч:

--- a/drivers/char/random.c.orig        2019-06-03 20:41:50.360552733 +0300
+++ a/drivers/char/random.c     2019-06-03 20:42:03.400553819 +0300
@@ -428,7 +428,7 @@
  * its value (from 0->1->2).
  */
 static int crng_init = 0;
-#define crng_ready() (likely(crng_init > 1))
+#define crng_ready() (likely(crng_init > 0))
 static int crng_init_cnt = 0;
 static unsigned long crng_global_init_time = 0;
 #define CRNG_INIT_CNT_THRESH (2*CHACHA20_KEY_SIZE)

Круто... Вы откатываете драйвер btrfs, а ведь в неё постоянно запихивают новые фишки. И ещё этот ризен... Ходят слухи что его поддержка пока что очень далека до идеала и жить можно только на самых свежих ядрах.

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

Просто, с-д должно писать адекватные вещи, а не молча тупить. Тот же journal по дефолту имеет какой-то смешной буфер и находится только в памяти. Пока листаешь лог - вжик - а он уже закольцевался и начало недоступно.

Да причем тут память (кроме компиляции в zram/tmpfs), когда компиляция нагружает процессор неслабо?

скатывается

При том, что современные многоядерные процессоры чертовски хорошо переваривают нагрузки до 2-3 потоков на логическое ядро. Если компилить по числу ядер с низким приоритетом, да ещё cgrops задействовать вместо nice, то заметить эту нагрузку удастся только в каком нибудь тяжёлом шутере по просадке фпс.

Но всё это верно только пока не подошла к концу память...