Это конечно справедливо, но невозможно решить в общем случае. Поскольку у нас
там фактически идёт исполнение одного сприкта, разные его части могут обрушить
его полностью. Можно конечно навесить обработчиков на всякие случаи ошибок, но
это в будущем.

Понимаю, но строго говоря -- происхождение проблемы не влияет на её
критичность... только на решаемость/сроки.

Там exit или сигналы трапать можно пытаться?  И получается ли изолировать модули
отдельными процессами (sh ...)? (не знаю, что именно там отвалилось -- как бы
выяснить?)

Стас, с этим у нас всё ещё глухо ?

оно не глухо, просто пока ещё не вставлено, а какое поведение должно быть?
Завершаться видимо ... а тогда в случае installer по идее без разницы как падать.

Вот в acc это надо будет вставить.

Так как раз от installer хочется иметь возможность пусть и с предупреждениями,
что на свою голову и всё взорвётся, но довести установку и иметь шанс
разобраться с новым/кривым железом, слепой читалкой или царапанным носителем уже
в живой системе.

См. #7291.

а если следующий шаг после взорвавшегося зависит от оного?
Зачем нужна такая детонация?

Значит следующий тоже взорвется.
А вот через один не взорвется.
Чем больше всего отработает, перед тем как придется лезть ручками все править --
тем лучше.

Ну install3 уже нет, а к install2 это ещё относится?

(In reply to comment #8)
> Ну install3 уже нет, а к install2 это ещё относится?

относится

Сейчас инсталлятор полностью основывается на alterator. Поэтому требование к
устойчивости относится к нему, а не к alterator-install2.

Component => alterator

apparently wontfix