Эльбрус на AltLinux p9 при резком отключении питания приходит в неконсистентное состояние (1) фс, и при всех дальнейших запусках переходит в maintaince mode и в этом состоянии предлагает нажать ctrl+D чтобы продолжить загрузку системы. Из состояния 1 повторное внезапное обесточивание (возможно пару раз) приводит в неконсистентное состояние (2) в котором система уже не загружается самостоятельно из-за отсутствия каких-то бинарных файлов. Из-за этого пришлось переустанавливать Альт на Эльбрусе. Фс используемая /boot/ - ext2, / - ext4
Не понял, в чем здесь ошибка, но прошу отреагировать.
Такого возможно добиться с любой доступной для записи файловой системой, особенно при активной записи на неё в момент отключения. Не делайте так. Для систем, которые подразумевают возможность отключения в любой момент -- порой подходит вариант исполнения "только для чтения".
Согласен с рекомендацией "не делайте так", "используйте ибп", и с комментарием "такого возможно добиться с любой доступной для записи файловой системой". При этом в ubuntu & mint на x86_64, crypto_luks+ext4 за пять лет и сотню отключений питания не было потери данных, а в p9 на e2k и ext4 каждый второй раз, а может и каждый первый раз наблюдаются разрушения, что может быть причиной? И на mipsel alt p9 на ext4 гораздо стабильнее, за десяток резких отключений не разрушилась система и продолжает загружаться не жалуясь на ошибки. Активная запись на диск при этом не производится. Как могут потеряться/испортиться бинарные файлы, если в них не производится запись? Чем я могу помочь в улучшении ситуации? Какие логи предоставить?
(Ответ для Avgust на комментарий #3) > Согласен с рекомендацией "не делайте так", "используйте ибп", и с > комментарием "такого возможно добиться с любой доступной для записи > файловой системой". Более того, есть и формальный пункт в документе ТВГИ.466535.181РЭ "ВЫЧИСЛИТЕЛЬНЫЙ КОМПЛЕКС «ЭЛЬБРУС 101-РС». Руководство по эксплуатации": --- 002.30.02 Выключение ВК Выключение ВК производится в следующей последовательности: - закрыть все рабочие программы и приложения; - дать приказ на завершение работы операционной системы; - дождаться завершения выполнения приказа; - выключить видеомонитор нажатием кнопки включения питания на его лицевой панели; - снять с блока питания БП корпуса Кс и видеомонитора первичное электропитание 220 В, 50 Гц. Примечание - Возможно принудительное выключение корпуса Кс (без корректного завершения работы ОС) путем длительного нажатия в течение 4-5 с кнопки включе- ния/выключения питания (рисунок 001.1 поз. 2) на передней стороне корпуса Кс. --- > При этом в ubuntu & mint на x86_64, crypto_luks+ext4 за пять лет и сотню > отключений питания не было потери данных, а в p9 на e2k и ext4 каждый второй > раз, а может и каждый первый раз наблюдаются разрушения, что может быть > причиной? У меня на x86 за более чем двадцать лет эксплуатации различных линуксов (по большей части альта), хоть и не сопровождающейся постоянными отключениями питания или ресетами, но всё-таки набравшей и такую статистику -- случаи серьёзного повреждения самых разных ФС были единичными (но были). При этом _полагаться_ на постояннное везение возможности не имею. Конкретно эльбрусы у меня на хозяйстве с 2015 года, сейчас их больше десятка. Разрушение ФС ловили один раз, связано оно было с не ожидавшимся разработчиками применением своп-файла (ядро 3.14 на тот момент было пропатчено только для своп-разделов, им надо уметь свои теги сохранять; mcst#3005, если что). Нештатных отключений/перезагрузок было, правда, немного -- машины в основном через ИБП подключены. Наиболее "невезучей" в плане ресетов оказалась моя рабочая 801-РС -- сочетание недостаточной устойчивости машин экспериментальной серии к статике (mcst#3137) с синтетическим креслом и частым подключением USB DVD, наверное, несколько десятков раз за последние год-два в сумме ресетилась. Все ext4 это выдержали. Ядро на ней сейчас ровно то же, что и в переданном вам дистрибутиве. Порой происходила и заметная дисковая активность в такие моменты. > И на mipsel alt p9 на ext4 гораздо стабильнее, за десяток резких > отключений не разрушилась система и продолжает загружаться не жалуясь на > ошибки. А отключения входят в программу испытаний? Интересно даже стало, чем было вызвано вот это: >>> из [неконсистентного] состояния 1 повторное внезапное обесточивание >>> (возможно пару раз) приводит в неконсистентное состояние (2) -- странно ожидать, что раненому станет лучше от ещё пары ударов кувалдой. Кстати, "каждый второй раз, а может и каждый первый" -- это если "поставили, отключили => сломалось; опять поставили, со второго (а может, и первого) отключения сломалось". Так понимаю, что утверждение было более эмоциональным, чем статистическим (иначе было бы уж совсем крайнее невезение какое-то). > Активная запись на диск при этом не производится. Как могут > потеряться/испортиться бинарные файлы, если в них не производится запись? Портятся, как правило, метаданные -- сами структуры ФС. > Чем я могу помочь в улучшении ситуации? Какие логи предоставить? Да как логи-то собирать при отключении питания? А выхлоп fsck -y без самой ФС будет малоинтересен даже специалистам по применяемой ФС (как-то видел сессию вытаскивания из комы ext3 при участии одного из её разработчиков -- bzzz@). Сам в подобных ситуациях стараюсь хотя бы экран сфотографировать: фото стереть проще, чем вспомнить, что там ещё подозрительного было. Если развал происходит во время ещё хоть какой-то работы системы -- сделать копию dmesg в tmpfs (и ни в коем случае не на проблемную ФС) и вытащить по сети наружу, если ещё возможно. Думаю, здесь может быть в разной мере осмысленным: - попытаться наступить на те же грабли целенаправленно ещё раз или несколько, если в цели испытания входит проверка на устойчивость к нештатным ситуациям; - попытаться произвести всё то же с ядром 4.19 (первая сборка уже есть); - поиграться в опции журналирования той ФС, которая разлетается (но с / это немножко заковыристо, надо make-initrd после изменения /etc/fstab); - [мне] попытаться воспроизвести на стендовом 101-РС. Для исключения подобных ситуаций в принципе возможно реализовать систему, работающую в режиме "только для чтения" -- на x86 сейчас такое делается буквально закатыванием гибридного ISO с альтом прямо на SSD/HDD, на e2k isohybrid надо адаптировать, но в принципе возможно (и это не единственный вариант). Но тогда надо продумывать конфигурирование "на лету" с применением исключительно сетевых средств, одноразовое конфигурирование с записью файлика на отдельный раздел, который штатно монтируется в режиме ro, либо разливку индивидуально преднастроенных образов. Но мне пока кажется, что это было удивительное невезение, а не правило (хотя лучше, когда "не везёт" при тестировании, чем при эксплуатации).
Таким образом, были нарушены условия эксплуатации компьютера, описанные в документации производителя. Это не ошибка оборудования и/или ОС. Если нужны иные требования по условиям эксплуатации, то прошу их явно сформулировать и обсудить с руководством всех заинтересованных сторон в переписке на соответствующем уровне. Спасибо.
