думается, install3 лучше быть более устойчивым к сбоям отдельных модулей -- сейчас выпадение, скажем, timezone приводит к провалу настройки xorg (вот только что наблюдал в init 7 на машинке, где попытался при установке вернуться из xorg в timezone)
Это конечно справедливо, но невозможно решить в общем случае. Поскольку у нас там фактически идёт исполнение одного сприкта, разные его части могут обрушить его полностью. Можно конечно навесить обработчиков на всякие случаи ошибок, но это в будущем.
Понимаю, но строго говоря -- происхождение проблемы не влияет на её критичность... только на решаемость/сроки. Там exit или сигналы трапать можно пытаться? И получается ли изолировать модули отдельными процессами (sh ...)? (не знаю, что именно там отвалилось -- как бы выяснить?)
Стас, с этим у нас всё ещё глухо ?
оно не глухо, просто пока ещё не вставлено, а какое поведение должно быть? Завершаться видимо ... а тогда в случае installer по идее без разницы как падать. Вот в acc это надо будет вставить.
Так как раз от installer хочется иметь возможность пусть и с предупреждениями, что на свою голову и всё взорвётся, но довести установку и иметь шанс разобраться с новым/кривым железом, слепой читалкой или царапанным носителем уже в живой системе. См. #7291.
а если следующий шаг после взорвавшегося зависит от оного? Зачем нужна такая детонация?
Значит следующий тоже взорвется. А вот через один не взорвется. Чем больше всего отработает, перед тем как придется лезть ручками все править -- тем лучше.
Ну install3 уже нет, а к install2 это ещё относится?
(In reply to comment #8) > Ну install3 уже нет, а к install2 это ещё относится? относится
Сейчас инсталлятор полностью основывается на alterator. Поэтому требование к устойчивости относится к нему, а не к alterator-install2. Component => alterator
apparently wontfix
