При установке дистрибутива на базе p5 с kernel-image-std-def-2.6.32-alt20.M50P.1 на (внимание!) 128 МБ RAM возникают множественные отказы ядра (см. вложение), что делает установку невозможной. На большем объёме памяти установка работает нормально. На 2.6.30 тоже всё работат хорошо даже на 128 МБ RAM.
Created attachment 4656 [details] Вывод dmesg при установке
Уточнение. 128 -- не магическое число. При небольшом числе пакетов в дистрибутиве она наблюдается при установке с меньшим RAM. Важно, что на 30-м ядре с тем же RAM она не проявляется. Ошибка происходит на этапе выполнения post-install пакетов.
Поправка: на 5.1 те же симптоимы
(В ответ на комментарий №3) > Поправка: на 5.1 те же симптоимы У меня нет.
Похоже, что циклит /usr/lib/rpm/gtk-icon-cache.filetrigger
Выделил #24558
Машины с 128 мб памяти морально устарели. Отсюда вывод, либо мы беремся решать эту проблему, но тогда надо выпускать специальное ядро(до 2х недель работы). Либо просто на неё забиваем. Я считаю что поддержка всякого хлама нецелесообразна.
Собственно причина падения в том что кончилась оперативная память.
(В ответ на комментарий №8) > Собственно причина падения в том что кончилась оперативная память. Да. Но она кончилась из-за ошибки. Это же ядро прекрасно работает при установке на 96Mb другого образа с меньшим числом пакетов. Потому если не вылечить ошибку, то она будет выплывать и на 1Gb.
Там нет ошибки. В логах есть только сообщения о out of memory killer и task hangup. Несмотря на всю страшность логов.
(В ответ на комментарий №10) > Там нет ошибки. В логах есть только сообщения о out of memory killer и task > hangup. Несмотря на всю страшность логов. Да, в ядре ошибки нет. gtk-icon-cache.filetrigger выжирает всю память.
(In reply to comment #10) > Там нет ошибки. В логах есть только сообщения о out of memory killer и task > hangup. Несмотря на всю страшность логов. oom killer -- это вообще не вопрос к ядру. Меня гораздо больше интересует природа самой первой ошибки на 675-й секунде, которая I/O error. Это похоже на баг.
Ещё есть drive timeout, из за которого собственно task hangup был. Но это все как то связано. Стоит кстати проверить на разных железках, везде ли там есть этот drive timeout
(В ответ на комментарий №13) > Ещё есть drive timeout, из за которого собственно task hangup был. Но это все > как то связано. Стоит кстати проверить на разных железках, везде ли там есть > этот drive timeout Этот лог, кстати, от установки в KVM
(In reply to comment #11) > gtk-icon-cache.filetrigger выжирает всю память. Если команда gtk-update-icon-cache --force --quiet "$dir" выжирает всю память, то вешайте баг на gtk-update-icon-cache.
(В ответ на комментарий №15) > (In reply to comment #11) > > gtk-icon-cache.filetrigger выжирает всю память. > > Если команда > gtk-update-icon-cache --force --quiet "$dir" > выжирает всю память, то вешайте баг на gtk-update-icon-cache. #24558 Кажется, она выжирает не всю доступную память, а много памяти. И это как-то зависит от иконок.
Обсуждаем в 24558
(В ответ на комментарий №12) > Меня гораздо больше интересует природа самой первой ошибки на 675-й секунде, > которая I/O error. Это похоже на баг. I/O error постоянно ловлю на server-light в момент записи скриптами /etc/hosts После загрузки пишется всё хорошо. Где-то ошибка в aufs ?
(В ответ на комментарий №18) > I/O error постоянно ловлю на server-light в момент записи скриптами /etc/hosts > > После загрузки пишется всё хорошо. Где-то ошибка в aufs ? dmesg в студию.
