[devel] Не переключается в графический режим
Dmitry V. Levin
ldv на altlinux.org
Вт Ноя 6 00:32:16 MSK 2018
On Mon, Nov 05, 2018 at 11:57:20PM +0300, Leonid Krivoshein wrote:
>
> 05.11.2018 21:54, Dmitry V. Levin пишет:
> > On Mon, Nov 05, 2018 at 08:25:26PM +0300, Andrey Savchenko wrote:
> > [...]
> >> Реальная проблема в том, что на обсуждаемом этапе загрузки random
> >> ещё не нужен, но используется. Очередная глупость от systemd.
> > $ git grep -Fnw initialize_libgcrypt
> > src/basic/gcrypt-util.c:9:void initialize_libgcrypt(bool secmem) {
> > src/basic/gcrypt-util.c:30: initialize_libgcrypt(false);
> > src/basic/gcrypt-util.h:14:void initialize_libgcrypt(bool secmem);
> > src/import/pull-job.c:324: initialize_libgcrypt(false);
> > src/journal/fsprg.c:253: initialize_libgcrypt(false);
> > src/journal/fsprg.c:289: initialize_libgcrypt(false);
> > src/journal/fsprg.c:308: initialize_libgcrypt(false);
> > src/journal/fsprg.c:335: initialize_libgcrypt(false);
> > src/journal/fsprg.c:374: initialize_libgcrypt(false);
> > src/journal/journal-authenticate.c:417: initialize_libgcrypt(true);
> > src/resolve/resolved-dns-dnssec.c:852: initialize_libgcrypt(false);
> > src/resolve/resolved-dns-dnssec.c:1171: initialize_libgcrypt(false);
> > src/resolve/resolved-dns-dnssec.c:1284: initialize_libgcrypt(false);
> >
> > Который из них залипает на стадии ранней загрузки?
>
> Извиняюсь, если кого ввёл в заблуждение: там говорилось о разработчиках
> в красной шляпе и они у себя там чего-то наотлаживали, при этом была
> оговорка, что ничего похожего в нашем гите я не нашёл. Даже предлагал
> решать проблему без оглядки на RedHat. Тем не менее, на моей машине:
>
> # systemd --version
> systemd 237
В Сизифе systemd-239-alt3.
> +PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP
> +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS
> +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid
>
> # strings /lib/systemd/systemd | grep /dev/random
> /dev/random
> /dev/random
>
> То есть, теоретически, "залипать" может "САМ"! :) Но у меня равно как и
> у большинства ничего не залипает. IMHO: systemd может не быть
> непосредственным виновником, но его асинхронность в ряде конфигураций
> может привести к тому, что "залипнет". Если бы факт наполненности пула
> можно было бы сделать зависимостью, но увы, это величина не постоянна.
>
> Видимо этой проблеме уже присвоена CVE:
> https://access.redhat.com/security/cve/cve-2018-1108 , её пытаются
> решить с последними ядрами:
>
> 4.16: https://bugzilla.redhat.com/show_bug.cgi?id=1572944
> 4.17: https://bugzilla.redhat.com/show_bug.cgi?id=1572916
> 4.18: https://bugzilla.redhat.com/show_bug.cgi?id=1639840
>
> 4.19:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3243a89dcbd8f5810b72ee0903d349bd000c4c9d
> - good news, "Здравствуй, доверие"! :)
>
> Но первый вопрос -- как это всё касается нас и касается ли вообще? Есть
> такой прецедент:
>
> https://lists.altlinux.org/pipermail/sisyphus/2018-November/367280.html
>
> Логи пока доступны. Едва ли по ним будет ясна проблема. Но из них ясно,
> что НАШ systemd использует /dev/urandom на стадии инициализации журнала.
> Да, ещё не инициализированный, но на этом он точно не залипает. Если там
> что и может залипать, то скорее NetworkManager или то, что зависит от
> сети и без чего почему-то не стартуют иксы. Возможно, стоит попросить
> отключить пока haveged и показать systemd-analaze critical-chain? Есть
> вообще какие-то способы (от initramfs до финальной загрузки) поймать
> всех, кто читает из /dev/random?
Пожалуйста, не надо валить всё в одну кучу.
В первую очередь воспроизведите проблему сами,
а потом уже предлагайте гипотезы и берите в руки отладчики.
И выкиньте haveged куда подальше.
--
ldv
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя : signature.asc
Тип : application/pgp-signature
Размер : 801 байтов
Описание: отсутствует
Url : <http://lists.altlinux.org/pipermail/devel/attachments/20181106/1700bac6/attachment.bin>
Подробная информация о списке рассылки Devel