+++ Данная ошибка создана размножением ошибки 27407 +++ Created an attachment (id=5477) oom в dmesg При установке Simply Linux 6.0.1 c образа altlinux-6.0.1-simply-i586-ru-live-cd.iso на машину с 248M RAM установщик ловит OOM на шаге "установка пакетов" (после разметки диска), переходит к установке загрузчика и завершается без сообщений об ошибках. Вывод dmesg прилагается. swap-раздел размером 218M был создан при автоматической разметке диска. Ошибки нет, если при RAM = 248M назначить руками swap = 512M. Так как дистрибутив хорошо работает при RAM=128--256M, желательно делать бОльший swap при автоматической разбивке и предупреждать при ручной разбивке, что swap-раздела < 512M не хватает.
Мне на беглый взгляд не очень нравится патч, предложенный в #27407. Я бы не стал его прикладывать как есть.
(В ответ на комментарий №1) > Мне на беглый взгляд не очень нравится патч, предложенный в #27407. Я бы не > стал его прикладывать как есть. Это proof of concept. Напускать unsquashfs на уже смонтированный в /.ro образ избыточно и кушает память.
(In reply to comment #1) > Мне на беглый взгляд не очень нравится патч, предложенный в #27407. А чем?
2sem: в преддверии регулярной публикации образов pre-p7 эта бага становится актуальной. Есть идеи?
(В ответ на комментарий №4) > 2sem: в преддверии регулярной публикации образов pre-p7 эта бага становится > актуальной. Есть идеи? 2mike, boyarsh, sem: ping Мы собираем в том числе легкие live-образы, которые работают на <=256Mb, а установить их из Live не можем. Не уверен, что нужно обязательно предупреждать при ручной разбивке, достаточно замечания в подсказке. Но вот почему бы не увеличить swap?
Да, я в конце прошлой недели помнил эту багу, работая над livecd-install. Делать ещё раз unsquashfs действительно кажется избыточным; мало того, на весьма быстрых CPU при 512M RAM в виртуальной машине нагрузка на процессор при разливке составляет что-то около 20%, т.е. образ заливается в несколько раз дольше, чем мог бы (при этом ISO лежит на довольно быстром диске, а sda -- на tmpfs; судя по "лампочкам", в них совсем не упираемся). Но нужно не потерять работоспособность progress bar.
Created attachment 5681 [details] патч с плавным progress bar (В ответ на комментарий №6) > Но нужно не потерять работоспособность progress bar. Пример в патче.
Created attachment 5682 [details] патч с плавным progress bar
Ночью промахнулся, bug 27407 comment 10 лучше было сюда. vx8400@ предложил адаптивный алгоритм расчёта процента выполнения с внесением поправки "на лету", но если ориентироваться на размер, а не иноды -- оптимальнее выглядит его же вчерашнее предложение выполнить оценку размера тарбола с live-системой заранее при сборке stage2, когда у нас заведомо достаточно мощностей и памяти, да и кэш горячий; а трогать лишний раз болванку или флэшку всё-таки накладно. Подумаю над этим и постараюсь сделать ещё один подход после более неприятных блокеров bug #27685. PS: потребление памяти при установке regular-icewm (i586) было около 93M.
(В ответ на комментарий №9) > PS: потребление памяти при установке regular-icewm (i586) было около 93M. Поясните: при установке с каким-либо из обсуждавшихся тут изменений в установщике live?
(In reply to comment #10) > > PS: потребление памяти при установке regular-icewm (i586) было около 93M. > Поясните: при установке с каким-либо из обсуждавшихся тут изменений в > установщике live? Именно. Варианты с tar и cp особо не отличались. Своп не задействовался вовсе (VM с 512M RAM, на 256M формально проверить не успевал, но по free и так было понятно, что должно влезть).
(В ответ на комментарий №11) > (In reply to comment #10) > > > PS: потребление памяти при установке regular-icewm (i586) было около 93M. > > Поясните: при установке с каким-либо из обсуждавшихся тут изменений в > > установщике live? > Именно. Варианты с tar и cp особо не отличались. Своп не задействовался вовсе > (VM с 512M RAM, на 256M формально проверить не успевал, но по free и так было > понятно, что должно влезть). Тогда, если не будет возражений sem@, нужно собирать с этим изменением, пусть пользователи тестируют.
Оно ещё не готово, т.е. как минимум 205% можно получить запросто. :)
(В ответ на комментарий №13) > Оно ещё не готово, т.е. как минимум 205% можно получить запросто. :) Это шашечки. Пусть они и важны, но надо бы начать проверять как оно едет. Впрочем, снизить до 140% было бы неплохо.
До 102% в случае regular-icewm снизили, а вот дальше -- или усложнение рантайма с адаптивной оценкой расхождения (уже разработанное и предложенное vx8400@), или подготовка точного размера заранее, или мухлёж типа реализованного в текущем варианте: http://git.altlinux.org/gears/a/alterator-livecd.git?p=alterator-livecd.git;a=blob;f=alterator-livecd/backend3/livecd-install;h=d93ce39b65d369740afcab712a31d97e32087360;hb=HEAD#l133
(В ответ на комментарий №15) > До 102% в случае regular-icewm снизили, а вот дальше -- или усложнение рантайма > с адаптивной оценкой расхождения (уже разработанное и предложенное vx8400@), > или подготовка точного размера заранее, или мухлёж типа реализованного в > текущем варианте: > http://git.altlinux.org/gears/a/alterator-livecd.git?p=alterator-livecd.git;a=blob;f=alterator-livecd/backend3/livecd-install;h=d93ce39b65d369740afcab712a31d97e32087360;hb=HEAD#l133 Небольшой мухлеж допустим. :-)
Created attachment 5686 [details] > ... усложнение рантайма с адаптивной оценкой расхождения (В ответ на комментарий №16) > усложнение рантайма с адаптивной оценкой расхождения:
А есть смысл сохранять старый вариант с unsquashfs? Я бы его выкинул совсем и рассчитывал на то, что у нас всегда смонтирован образ в /.ro. > > Оно ещё не готово, т.е. как минимум 205% можно получить запросто. :) > > Это шашечки. Пусть они и важны, но надо бы начать проверять как оно едет. > Впрочем, снизить до 140% было бы неплохо. Вся сложность тут как раз в правильном прогресс-баре, тестировать просто копирование файлов я не вижу особого смысла.
Последний вариант патча похоже не рабочий. Да и вообще построить соответствие между количеством записей в tar и реальным размером не так просто. Я склонюсь к мысли сделать простой вариант, отталкиваясь от количества файлов, а не их размера. Это будет не слишком плавный прогресс-бар, но общий прогресс выполнения работы вполне покажет. Впрочем, поиграюсь еще с rsync, может получится взять размер файлов из его вывода.
(In reply to comment #19) > Я склонюсь к мысли сделать простой вариант, отталкиваясь от количества файлов, > а не их размера. Это будет не слишком плавный прогресс-бар, но общий прогресс > выполнения работы вполне покажет. Такая реализация в виде грязного наброска уже есть, но "в лоб" разъезд получился вида 140% вместо 102% (дело было ночером и уже внимания не хватило вникать, возможно, это были хардлинки -- оценка по du -i, счёт по выводу cp -av). > Впрочем, поиграюсь еще с rsync, может получится взять размер файлов из его > вывода. Не трать зря время -- в свежайшем rsync вроде бы как что-то сделали, но ресурсоёмкое на начальном этапе; в сизифном мане соответствующие опции упоминаются, но бинарник отнекивается. См. тж. http://serverfault.com/questions/219013/showing-total-progress-in-rsync-is-it-possible IMHO пока наиболее практичным выглядит вариант с выполнением строгой оценки при сборке и счёта по тому же показателю -- сейчас под руками тоже грязный вариант с tar, тестирования живьём он ещё не проходил (т.к. пока квант времени на эту багу закончился в пользу выкатывания стопки образов). Если хочешь, могу наброски попытаться выделить и прицепить -- просто этот вариант удобнее всего проверять в комплекте с дополненным ещё одним хуком профилем.
(В ответ на комментарий №19) > Последний вариант патча похоже не рабочий. works for me. Что не работает?
(В ответ на комментарий №20) > (In reply to comment #19) > > Я склонюсь к мысли сделать простой вариант, отталкиваясь от количества файлов, > Такая реализация в виде грязного наброска уже есть, но "в лоб" разъезд > получился вида 140% вместо 102% (дело было ночером и уже внимания не хватило > вникать, возможно, это были хардлинки -- оценка по du -i, счёт по выводу cp > -av). И все-таки мне кажется это самым простым вариантом. > > Впрочем, поиграюсь еще с rsync, может получится взять размер файлов из его > > вывода. > Не трать зря время -- в свежайшем rsync вроде бы как что-то сделали, но > ресурсоёмкое на начальном этапе; в сизифном мане соответствующие опции > упоминаются, но бинарник отнекивается. См. тж. > http://serverfault.com/questions/219013/showing-total-progress-in-rsync-is-it-possible Да, я знаю. Похоже апстрим слишком рано обновил man page. Но может удастся обойтись и тем что есть. > IMHO пока наиболее практичным выглядит вариант с выполнением строгой оценки при > сборке и счёта по тому же показателю -- сейчас под руками тоже грязный вариант > с tar, тестирования живьём он ещё не проходил (т.к. пока квант времени на эту > багу закончился в пользу выкатывания стопки образов). Мне кажется это совершенно излишним усложнением. Большой точности не надо, надо просто что-то показать пользователю, чтобы ему было не слишком скучно смотреть на картинку. (В ответ на комментарий №21) > > Последний вариант патча похоже не рабочий. > works for me. > Что не работает? У меня в тестовом скрипте на базе этого патча прогресс начинался сразу с 80+ и быстро доходил до 100 задолго до конца работы. Вообще checkpoints никакого отношения к размеру не имеют, если я правильно понял документацию.
(В ответ на комментарий №22) > У меня в тестовом скрипте на базе этого патча прогресс начинался сразу с 80+ и > быстро доходил до 100 задолго до конца работы. Как это воспроизвести? С 80% может начинаться при размере самой большой директории <~100 блоков. > Вообще checkpoints никакого отношения к размеру не имеют, если я правильно > понял документацию. --сheckpoint=X выводит число записанных блоков через каждые X записанных блоков.
> > У меня в тестовом скрипте на базе этого патча прогресс начинался сразу с 80+ и > > быстро доходил до 100 задолго до конца работы. > > Как это воспроизвести? С 80% может начинаться при размере самой большой > директории <~100 блоков. Не знаю, я просто копировал код из патча в тестовый скрипт. Но может где и ошибся. В любом случае предложенный вариант выглядит слишком усложненным и не надежным. У меня в гите есть простой вариант, где progress bar может и не такой плавный, но для данной задачи должно хватить. Тестировал только тестовым скриптом, в самом alterator-livecd еще не проверял. http://git.altlinux.org/people/sem/packages/?p=alterator-livecd.git;a=commit;h=33a273035ae6fd0ea21f257c6a5dde596726ccef
alterator-livecd-0.8.0-alt1 -> sisyphus: * Thu Jan 10 2013 Mikhail Efremov <sem@altlinux> 0.8.0-alt1 - Don't use unsquashfs, just copy files (closes: #27786).
