LINUX.ORG.RU

Ответ на: комментарий от nillerusr

Инфы катастрофически мало, вариантов катастрофически много.
1. Ты в каком окружении? В том, которое настраиваешь, или в каком-то chroot/qemu/виртуальной машине etc.?

Вчера спокойно все ставилось

2. Что делал со вчерашнего дня?
3. Когда в последний раз обновлял gcc, glibc musl?
4. emerge -pvuND что говорит?
5. Покажи make.conf?
6. Что выдают команды:

$ mount
$ ls -la /var/lib/portage
$ ls -la /var/db/pkg
7. Покажи логи ядра после операции?

Kroz ★★★★★ ()
Ответ на: комментарий от nillerusr

TD;DR: убери тюнинг под свой проц и другие оптимизации.

1. (Приоритет 2, как ни странно)
По началу моей гипотезой было то, что что-то не так с записью в /var/lib/portage или /var/db/pkg или корень. С аттрибутами, конечно, было очень маловероятно, но ядро могло запросто перемонтировать раздел в read-only при каком-то сбое. Поскольку у тебя chroot (надеюсь, ты загружался с LiveUSB на том же процессоре, а не используешь какие-то кросс-архитектурные приёмы), я не совсем понимаю как трактовать твой вывод mount. Во-первых, я не нахожу запись для корневого раздела, во-вторых, не очень понимаю куда подмонтирована целевая система; наверное к /mnt/system, но он у тебя read-only. Против это гипотезы говорит то, что до обновления всё работало, да и скорее всего были бы сообщения об ошибке. Но я бы всё равно не сбрасывал этот вариант со счетов.

Вобщем, рекомендую воспроизвести проблему, посмотреть лог ядра на предмет всевозможных ошибок (вообще весь лог ядра), проверить с помощью touch запись в корень, /var/lib/portage и /var/db/pkg. Если ты ты компилил ядро с поддержкой конкретного чипсета, а есть возможность использовать generic driver, то сделать это.

2. (Приоритет 1)
Если я правильно понял, ты кастомизировал флаги компиляции. Я не хочу обсуждать правильно ты это сделал или нет, но я бы вернул дефолтные, которые шли в stage3. Это, кстати, отлично укладывается в сценарий «всё работало - обновил мир - начались глюки».

Я еще иногда делал так: развернул stage3, никакой оптимизации, загрузился в систему (без всяких chroot, эмуляторов, виртуальных машин), перекомпилил мир emerge -ev world, перегрузился опять в систему, только после этого доустанавливал софт. Это позволяет выявить глюки на ранних стадиях. По-хорошему еще тесты написать, для проверки работы системы. Только после того как всё заработало, медленно и аккуратно что-то оптимизируй, запуская тесты на обратную совместимость и для оценки результата оптимизации.

Аналогично c ядром: Linux-2.6.38.6-perf-armv7l-with-gentoo-2.6 . Я не знаю этого ядра, но похоже, что там что-то с заточкой на performance. Плюс, я подозреваю, что ты там понаотключал «что-то ненужное». Поставь для начала гентушное или ванильное ядро, ничего не отключай, включи только то, что критично для загрузки системы. Как заставишь систему работать, только после этого оптимизируй, с тестами на обратную совместимость и для оценки результата оптимизации.

Да, еще. Есть много холливоров по поводу обновления glibc/musl и gcc/.... Железобетонных аргументов ни одна из сторон предъявить не может. Так что я бы рекомендовал, исключить glibc/musl и gcc из ежедневных обновлений, а когда решишься обновить что-то из этого - после обновления перекомпилить мир emerge -ev world (а случае gcc еще и libtool); да, это означает, что ты два раза перекомпилишь эти пакеты: первый раз при обновлении обновление, второй - при перекомпиляции мира.

P. S. Да, я предлагаю переразвернуть систему со stage 3.

Kroz ★★★★★ ()
Ответ на: комментарий от Kroz

Это андроидовое ядро, корневой каталог есть, он rw. Другие ядра увы накатить не получится. И вообще я не буду трогать пока ядро и флаги, лучше вывод strace пока посмотрю

nillerusr ()