Странности OpenRC - После установки и первого обновления загружается только с толкача

Я тут на днях ставил Calculate Desktop XFce (x86) на еще одну машинку и столкнулся с инетерсным эффектом. На третий комп ставлю эту систему и первый раз такое вижу.

Суть в том, что после установки всех программ и обновления всего чего только можно через cl-update система не загружается. А точнее говоря - недозагружается. Отрабатывает загрузчик (GRUB), загружается как следует выругавшись ядро, за ним init, запускается OpenRC. И последний даже начинает загрузку, но дойдя до строчки " * Caching service dependencies …" система замирает на пару секунд, потом выводит ту же строчку еще раз следом и на этом все. В таком состоянии оно может висеть 15 минут. Дольше ждать не пробовал, но, думаю, и за полдня ничего не поменяется.

Но это - не самое забавное. Прикол в том, что загрузить систему таки можно, причем начиная сразу после второго “Caching…-а”. Для этого нужно в этот момент нажимать на любые клавиши на клавиатуре (кроме “I”, которая вызывает “интерактивный режим”, в котором вход в терминал не работает, вызывая уже тотальное зависание, а от всего остального толку мало, и клавиш-модификаторов типа Alt, Shift и т.д.). Цифры, буквы, Enter, пробел - все работает одинаково. Каждое одно нажатие на клавишу позволяет загрузить еще одну очередную службу. И если поелозить по клавиатуре как следует, то можно дойти таки до либо xdm и графического входа в систему либо (если xdm отключить) - текстового приглашения на ввод имени пользователя. При этом сами службы после своего “пинка” стартуют штатно и после такой загрузки вся система работает нормально.

Я уже пробовал отключать в runlevel-ах все что только можно и даже отключать параллельную загрузку служб в OpenRC - ничего при этом не менялось кроме того, что чем меньше служб - тем меньше раз надо стукнуть по клавиатуре. Также попробовал в том же /etc/rc.conf включать и расширенный вывод и логи, но ничего относящегося к этому эфекту не нашел - все что в получающихся логах есть относится к загрузке самих служб своими скриптами, но не к тому, что их собственно загружает. Попробовал я и из загруженой уже системы этот кэш зависимостей командой “rc-update -u” обновить, что проходило успешно, но эффекта также никакого не возымело. Разумеется, переустанавливать пакет OpenRC я тоже пробовал и изменений также от этого никаких.

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

Есть возможность показать вывод dmesg?
Хватает ли свободного место на всех разделах (df -h)?

Вывод dmesg сразу после “принудительной загрузки” - в приложении dmsages (25.8 KB) . Я так понимаю, этот разыв во времени с 3-х до 13 секунд:
[ 3.028114] EXT4-fs (sdb1): re-mounted. Opts: (null)
[ 3.074849] EXT4-fs (sdb1): re-mounted. Opts: (null)
[ 3.253184] dracut: Switching root
[ 13.004990] udevd[3175]: starting version 3.2.5
[ 13.434160] vboxdrv: loading out-of-tree module taints kernel.
[ 13.436841] vboxdrv: Found 4 processor cores
[ 13.452815] vboxdrv: TSC mode is Invariant, tentative frequency 3292518826 Hz
[ 13.452817] vboxdrv: Successfully loaded version 6.0.10 (interface 0x00290008)
[ 13.475711] udevd[3175]: starting eudev-3.2.5
это как раз то время пока я до udev-а систему кнопкой догружал.

Что касается свободного места - по версии df -h в корне занято 16%, а в /var/calculate - 14%. Свободны десятки гигабайт. Но система свежеустановленая, да и каталога /home в этот раз у меня тоже нет - по совету из руководства заменил его на символьную ссылку на отдельный раздел /var/calculate/home, куда перетащил все содержимое. Так что оно полюбому забится чем-нибудь вроде кэша браузера и не могло.

Обратил внимание на этот кусок

[    1.562963] ACPI BIOS Error (bug): Could not resolve [\_SB.PCI0.SAT0.SPT1._GTF.DSSP], AE_NOT_FOUND (20180810/psargs-330)
[    1.563012] ACPI Error: Method parse/execution failed \_SB.PCI0.SAT0.SPT1._GTF, AE_NOT_FOUND (20180810/psparse-516)
[    1.563333] ata2.00: ATA-10: WDC WD1003FZEX-00K3CA0, 01.01A01, max UDMA/133
[    1.563336] ata2.00: 1953525168 sectors, multi 16: LBA48 NCQ (depth 32), AA
[    1.563521] ACPI BIOS Error (bug): Could not resolve [\_SB.PCI0.SAT0.SPT0._GTF.DSSP], AE_NOT_FOUND (20180810/psargs-330)
[    1.563580] ACPI Error: Method parse/execution failed \_SB.PCI0.SAT0.SPT0._GTF, AE_NOT_FOUND (20180810/psparse-516)
[    1.563942] ACPI BIOS Error (bug): Could not resolve [\_SB.PCI0.SAT0.SPT1._GTF.DSSP], AE_NOT_FOUND (20180810/psargs-330)
[    1.563989] ACPI Error: Method parse/execution failed \_SB.PCI0.SAT0.SPT1._GTF, AE_NOT_FOUND (20180810/psparse-516)
[    1.564043] ata1.00: ATA-8: ST500DM002-1BD142, KC45, max UDMA/133
[    1.564046] ata1.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 32)
[    1.564299] ata2.00: configured for UDMA/133
[    1.565051] ACPI BIOS Error (bug): Could not resolve [\_SB.PCI0.SAT0.SPT5._GTF.DSSP], AE_NOT_FOUND (20180810/psargs-330)
[    1.565112] ACPI Error: Method parse/execution failed \_SB.PCI0.SAT0.SPT5._GTF, AE_NOT_FOUND (20180810/psparse-516)
[    1.565187] ata6.00: ATAPI: TSSTcorp CDDVDW SH-224DB, SB01, max UDMA/100
[    1.565370] ACPI BIOS Error (bug): Could not resolve [\_SB.PCI0.SAT0.SPT0._GTF.DSSP], AE_NOT_FOUND (20180810/psargs-330)
[    1.565444] ACPI Error: Method parse/execution failed \_SB.PCI0.SAT0.SPT0._GTF, AE_NOT_FOUND (20180810/psparse-516)

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

https://www.kernel.org/doc/html/v4.19/admin-guide/kernel-parameters.html

В начале загрузки CL выделить верхнее (свежее) ядро затем нажать на E для редактирования и в параметрах груба, где есть строка с vmlinuz в конце её добавить libata.noacpi и после редактирования нажать F10 .
Возможно это исправит. Если это помогло тогда уже окончательно поправить в /etc/default/grub
и далее закрепить изменения командой

# grub-mkconfig -o /boot/grub/grub.cfg

Не могу показать наглядно т.к. у меня lilo.
https://wiki.gentoo.org/wiki/GRUB2/ru

Попробовал добавить libata.noacpi в параметры загрузки ядра. Эффекта никакого, только ошибок при загрузке ядра стало выдавать больше. Встает ровно на том же месте и таким же образом.

Попутно я еще попробовал пересобрать ядро и перезаписывать initrd, добавить обратно UEFI-раздел со второго диска, который я удалял ранее чтобы тот глаза не мозолил, решив, что, может, его отсетствие /dev/sda1 при наличии /dev/sda2 и 3 смущает. Но нет - дело не в этом. Помятуя про старые проблемы с ядрами попробую я еще пошаманить и откатить версию до 4.14.138, но что-то я подозреваю, что это тоже не поможет…

Попробовал поставить calculate-sources-4.14.138. Эффект - похожий. С этим ядром OpenRC работает в графическом режиме загрузки вместо тескта выводя красивую картинку с вращающимся индикатором под ней, но точно так же висит пока не нажмешь какую-нибудь клавишу.

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

Cлучаем нет ли чего нехорошего в /var/log/Xorg.0.log или в других Xorg.*.log?
Маловероятно, но все же.

Я кажется нашел что-то похожее
https://unix.stackexchange.com/questions/411039/gentoos-openrc-hangs-forever-in-caching-service-dependencies

Посмотрел я этот вариант со stackexchange. Только я решил не гадать кто из скриптов может создавать проблемы, а просто взял весь /etc/init.d и все runlevel-ы и скопировал с гарантированно рабочей системы и заменил, удалив все что осталось. Ничего при этом не поменялось. При этом как он там запускал ps, прерывая загрузку через SysRq мне не очень понятно.

В итоге мне эти пляски с бубном надоели и я уже корневой раздел снес и переустановил систему. Накатил все основные настройки и все обновил, тут же перезагрузившись. Пока запуск происходит без проблем.

Так что пока план такой: буду продолжать потихоньку вбивать настройки и доставлять пакеты небольшими группами до примерно прошлого состояния, все по ходу документировать и ждять момента появления глюка. Но не факт что он появится. Дело в том, что я в этот раз сразу после установки первым делом заменил основные конфиги и, главное, make.conf годным безопасным вариантом, где отключил параллельное испольнение заданий emerge-ем. И у меня уже был опыт с funtoo когда я пытался запускать сразу несколько толстых emerge-ей (типа содержащих qtwebengine или сборку firefox из исходников) в параллель, которые отрабатывали всю ночь и тоже с совершенно непредсказуеммыми глюками в результате, причем конфиги засирались самым странным образом в самых неожиданных местах.

Знакомая ситуация.
https://wiki.calculate-linux.org/en/working_with_calculate
https://old.calculate-linux.org/main/ru/makeconf
https://wiki.gentoo.org/wiki//etc/portage/make.conf/ru
https://wiki.gentoo.org/wiki/Ccache
https://wiki.gentoo.org/wiki/Safe_CFLAGS

В общем, система полностью переустановлена, все находится в том же виде как и до того, но эффекта так и не проявилось. Для желающих посмотреть как выглядит такое поведение можете в файле /etc/rc.conf поставить rc_parallel=“NO” и rc_interactive=“YES”. Я без понятия что это было, почему такое может происходить при прямо противоположных настройках OpenRC, и где конкретно и как что было нарушено.

Могу пока только посоветовать быть аккуратнее с обновлениями, особенно - крупными и содержащими при этом системные пакеты, в файле /etc/portage/make.conf/custom.cldx иметь строчку
EMERGE_DEFAULT_OPTS="${EMERGE_DEFAULT_OPTS} --jobs=1"
и не запускать несколько emerge-ей одновременно. Была ли проблема связана с этим я точно не знаю, но кроме этого момента, а также порядка установки пакетов и ввода настроек отличий между рабочей и некорректной последовательностью действий особо никаких нет. Если это не оно - тогда это какой-то внешний случайный фактор типа обновления пакетов в репозиториях как раз в процессе когда их часть проходила установку, но это уже чисто удача тогда и ничего с этим не поделаешь, не иконки же на компьютер клеить в самом деле.

На этом эксперимент считаю завершенным и спасибо всем написавшим выше свои мнения и предложения на этот счет.

В мае отвалилось ВСЕ. Бутнул с рекавери. Через eselect выбрал гентушный профиль,сделал проверку обновлений, затем опять поставил профиль кальки.Еще раз обновил через emerge. Работает.