Коммитом 2893f2c735f1678e49b9586bcce5aac22eada4a1 в alterator-vm был изменён метод разбивки по умолчанию с plain на lvm; это предъявляет дополнительные требования к содержанию дистрибутива и не было никак обосновано. Предлагаю откатить ровно этот коммит -- кому нужны дополнительные возможности, тот пусть обеспечит наличие всего требуемого в образе. Баг повешен по результатам сегодняшнего совещания, на котором было упомянуто как регрессия. Могу подготовить NMU.
Миша, это тестовый пример профиля, ни к чему не обязывающий. Если ты сделаешь другой профиль _в своём дистрибутиве_, то там будет другая конфигурация по умолчанию.
это же пример профиля, он используется, когда нет дистроспецифичного -- то есть, примерно никогда. я могу наверное переименовать его в sample или вообще убрать, поскольку именно как sample он и предполагался с самого начала.
нет, только пожалуйста, не надо убирать. Переименовать отличная идея, заодно выясним кто и зачем его использует.
Напоролись в LiveCD образовательного дистрибутива -- там vm-profile.scm оказался в installer-distro. Что пример -- понимаю, но лучше пусть он всё-таки имеет больше шансов ещё и рабочим оказаться. Если переименовать -- насколько помню, "из коробки" alterator-vm в инсталерах станет неприменимым для авторазбивки в тех случаях, когда сейчас годится. То есть это будет другая регрессия.
в livecd нужно включать другой профиль.
А про какие дополнительные требования к содержанию дистрибутивов ты пишешь ? У нас есть дистрибутивы без lvm ?
(В ответ на комментарий №5) > в livecd нужно включать другой профиль. Чем он должен отличаться? (В ответ на комментарий №6) > А про какие дополнительные требования к содержанию дистрибутивов ты пишешь ? Очевидно, наличие пакета make-initrd-lvm (и вообще-то lvm2 тоже). > У нас есть дистрибутивы без lvm ? У нас бывают образы без lvm и ломать универсальные компоненты вижу странным. Ну, нарушение принципа наименьшего удивления, работоспособности из коробки, всё такое.
Это изменение было сделано год назад, похоже что потребность в его откате надумана. Ну и да, я уверен в том, что отсутствие в дистрибутивах поддержки lvm является серьёзнейшей ошибкой автора такого дистрибутива. В любом случае - пример конфига мне не очень интересен, но хотелось бы что бы он было максимально функциональный, в том числе и с поддержкой lvm.
Антон, я собирался эту просьбу повесить тогда же, как только заметил -- но тогда уже заполненную багу решил не отправлять, сказав добавить конфиг в образ. Примеры конфигов в самых разных вариантах положить в документацию alterator-vm было бы неплохо (готов приложить руку), но усложнение без сколь-нибудь внятной причины ситуации по умолчанию всё-таки считаю регрессией. Против твоей уверенности в полезности lvm есть моя уверенность в ненужности усложнений на ровном месте, а также бухтёх gremlin@ о том, что в dm известны арифметические ошибки (и он порой видит их последствия у других) -- в любом случае вкусы хороши уж тем, что бывают разные, но логику пока не отменяли. Могу расписать дерево ситуаций, но надо ли?.. PS: помнишь, как для школьного терминального сервера была сделана авторазбивка с raid (там было осмысленно так)? По твоей логике следует и это воткнуть в штатный конфиг, потому что и функция же ж хорошая, и иллюстрирует; по моей -- простое стоит делать простым, сложное -- возможным.
давайте я ещё раз попробую: обсуждаемое изменение было сделано в примере, таковым это файл считался всегда, поскольку очевидно, что некоей разбивки по умолчанию, пригодной для всех случаев, просто не существует, поэтому: я готов выслушать предложения по изменениям в этом файле/с этим файлом, чтобы более ясно донести ровно эту мысль -- как-то: переименовать, убрать, написать БОЛЬШИМИ БУКВАМИ DO NOT USE IN PRODUCTION -- что-то ещё ?
Миша, почему наличие lvm в дистрибутиве нужно (если он устанавливается через alterator-vm), так это то, что с помощью alterator-vm в ручном режиме lvm делается без проблем и ты получишь незагружаемую систему (evms таскает с собой реализацию lvm и ему для этого никаких тулзов не надо). В общем по мне так ошибки тут нет. Дальнейшую дискуссию продолжать смысла не вижу.
(In reply to Anton Farygin from comment #8) > Это изменение было сделано год назад, похоже что потребность в его откате > надумана. Когда заметил, тогда и повесил -- я сейчас x86 редко занимаюсь. > Ну и да, я уверен в том, что отсутствие в дистрибутивах поддержки lvm > является серьёзнейшей ошибкой автора такого дистрибутива. Это твоя позиция. Моя диаметрально противоположна. При этом на моей стороне тот тривиальный довод, что предлагать вместо опирающегося на заведомо присутствующее в дистрибутиве опирающееся на то, что надо положить (притом не являющееся технически необходимым) -- значит на ровном месте увеличивать шансы на неработоспособность суммы. (In reply to Anton Farygin from comment #11) > Миша, почему наличие lvm в дистрибутиве нужно (если он устанавливается через > alterator-vm), так это то, что с помощью alterator-vm в ручном режиме lvm > делается без проблем и ты получишь незагружаемую систему (evms таскает с > собой реализацию lvm и ему для этого никаких тулзов не надо). Это не довод, а сообщение об _ошибке_ в alterator-vm, который умеет делать медвежью услугу -- сравни с поведением по mkfs.* (не предлагать создать те ФС, утилиты для которых не найдены). > В общем по мне так ошибки тут нет. Дальнейшую дискуссию продолжать смысла > не вижу. Верю тебе, но поскольку alterator-vm на сейчас не только часть KWorkstation, а и часть любого дистрибутива альта -- придётся попросить мнение руководства, раз не удалось самостоятельно тебя убедить в деструктивности таких изменений. (In reply to Sergey Bolshakov from comment #10) > обсуждаемое изменение было сделано в примере, таковым это файл считался > всегда, поскольку очевидно, что некоей разбивки по умолчанию, пригодной > для всех случаев, просто не существует, поэтому: > я готов выслушать предложения по изменениям в этом файле/с этим файлом, > чтобы более ясно донести ровно эту мысль -- как-то: переименовать, убрать, > написать БОЛЬШИМИ БУКВАМИ DO NOT USE IN PRODUCTION -- что-то ещё ? Боюсь, в случаях, когда она по факту применяется -- её по факту уже не заметили. Ну и опять же с точки зрения хоть какой-то работоспособности по умолчанию хотя бы корень сделать, если есть где -- вполне логично (плюс, возможно, ESP в случае EFI или что ещё особенного в случае других фирмварей -- это уже за рамками данной баги и местами уже висит). И всё равно не понял: зачем тогда захламлять неиспользуемый пример ещё и lvm?
Нет, lvm по умолчанию это обязательно и не регрессия. Все дистрибутивы готовы к этом изменению, а кто не готов - сделает соответствующий профиль. То, что ты не понимаешь как работает lvm не является поводом откатывать данное изменение. Считай это мнением руководства с моей стороны.
Добавлю, что если за два года это никому не помешало, то твои _требования_ неразумны и надуманны. Как перечисляли выше - данный файл является примером, показывающим возможности alterator-vm, и с lvm в том числе. Не хотите его использовать - не надо. Так и происходит в 100% профилей дистрибутивов.
Можно добавить другой пример, полагаю. Мне кажется, что это вопрос не "начальства", а релиз-менеджеров. А если хочется устроить обсуждение, то нужно посмотреть и описание т Ъ как это сделано "у них". Не потому, что там правильно, а чтобы расширить число участник ков обсуждения. :)
Это вопрос разработчиков alterator-vm. Какой им захотелось пример вставить в пакет, такой и вставили. Если нужен другой пример - можно добавить и его, но ошибка должна быть именно об этом, а не об откате lvm в example разбивки. А тратить время на бесполезное с точки зрения продуктивности обсуждение не нужно.