дублирование раздела /boot

симлинки вроде не подойдут.

наверно, оптимально в скрипт update-grub вписать где-то в начале просто команду cp на второй раздел

Зачем вообще дублировать возобновляемые, свободно доступные данные? По-моему таки всё «системное» имеет наименьшую ценность, и резервировать надо пользовательские данные.

Что у тебя за SSD такие, что ты ждёшь, когда они сдохнут?

ой, не тупи. это не ответ/решение по вопросу вообще

Гуля, linux raid1 lvm grub - как-то так. «мыж» не «телепаты» догадаться что у вас и как в части загрузки.

Это не ответ, правда. Но если честно — умерший /boot и впрямь не такая большая проблема. Из соображений аварийного восстановления лучше отдельная флешка с ПО для этого.

Да что ты ему говоришь, он же тебе сейчас в ответ нахамит.

Вы тоже не до конца правы. Я попытался «пованговать» за ТС. Предположим у нас есть два «бутовых» харда, данные ведь могут быть где угодно. Задача в случае выхода из строя одного, обеспечить возможность загрузки со второго. Вроде ничего «криминального» в задаче ТС нет.

умерший /boot и впрямь не такая большая проблема.

сам /boot здесь не причём(хотя могут быть самосборные ядра и удалён deb пакет)
наверное,дело в том, что если диск сдохнет, ОС не загрузится и придётся накатывать и загручик куда то?

я хочу сделать удобнее, ты отговариваешь меня сделать удобнее. это форум антилинуксоид?

Делай raid в таком случае под /boot и ставь загрузчик на оба диска.

grub сможет загрузиться с mdadm raid1 ? ФС некритична, ext2 скорее всего

Да

Не всегда. Тут была тема, вот прямо недавно, про «копейку7» баг у нее говорят есть. Но если говорить про «не из каробки» то конечно Да.

Тут была тема, вот прямо недавно, про «копейку7» баг у нее говорят есть.

Какая тема, если про то, что в случае отключения или выхода из строя одного из дисков ядро сценарий в Initramfs от CentOS не собирает RAID и как следствие не монтируется корневая файловая система, то при чём же здесь grub и raid?

Давеча как в прошлую пятницу ставил CentOS 7 и Debian 9 на RAID1 вместе с загрузчиком и всё работает, к тому же версия мета информации RAID 1.2.

Давай ссылку на тему.

Какая тема, если про то, что в случае отключения или выхода из строя одного из дисков ядро сценарий в Initramfs от CentOS не собирает RAID и как следствие не монтируется корневая файловая система

Ага, оно самое.

то при чём же здесь grub и raid?

Ну если по отдельности рассматривать, «туалетную бумагу», «попу», «пуговицы», то кажется действительно не причем.

Ага, оно самое.

о в случае отключения или выхода из строя одного из дисков ядро сценарий в Initramfs от CentOS не собирает RAID и как следствие не монтируется корневая файловая система

Ну в таком случае у тебя пробелмы с логикой.

Давай думать логически, в той теме у автора загружалось ядро и initramfs, а потом появлалась ошибка и всё проваливалось в Initramfs SHell.

Т.е. делаем вывод, что загрузчик, даже в случае отключения одного из дисков ЗАПУСКАЕТСЯ. Т.е. загрузчик работает и считывает образ ядра и initramfs.

Т.е. проблемы работе загрузчика с RAID нет. Почитай тему, и ты увидишь там мой коментарий с описанием почему эта проблема возникает, сравнение и разбор запуска с RAID в случае Debian и CentOS сделан мной же.

Grub2 умеет и raid, и много что ещё для вторичного загрузчика(в /boot который). Но нужно ещё удостовериться, что первичный(и полуторный) загрузчик установится на оба диска.

разбор запуска с RAID в случае Debian и CentOS сделан мной же.

Просто отлично!(это без шуток, очень отличный разбор) Я тогда ради интереса начал подобный разбор, но не успел, только до деба добрался, вы меня опередили.
Теперь по существу. Учитывая, что вы не то что «в курсе событий», а являетесь тем кто разобрал все, тем более вам должно быть понятнее

если по отдельности рассматривать, «туалетную бумагу», «попу», «пуговицы»

Ну можно сделать linux raid level 1 из разделов и поместить /boot на массив

да, но если у тебя efi, то что делать с efi разделом, так до конца и не ясно

тем более вам должно быть понятнее

Нет, мне не понятно, если ТС сделает RAID только для /boot, то не вижу каких-бы то ни было проблема в запуске системы, в независимости от того какие кривые стартовые скрипты помещены в intiramfs разработчиками дистрибутива.

Опять же, к примеру на Debian всё работает нормально, а в случае centos проблема лишь в сценарии в initramfs.

Осознал, виноват, думал о своем. А вы исключительно про задачу топика писали, вот и недопонимание возникло.

Опять же, к примеру на Debian всё работает нормально, а в случае centos проблема лишь в сценарии в initramfs.

Да и не только на дебе.

Ну можно сделать linux raid level 1 из разделов и поместить /boot на массив

А как лучше сделать, через mdadm или lvm mirror?

чтобы было автоматическая синхронизация содержимого /boot, но и чтобы граб(2) мог загрузить ОС ?

Первая часть - rsync из cron от root.

Вторая часть - учить команды grub, чтобы «ручками» перенаправить его на запасной раздел.

у меня в fstab записано ro на этот раздел , надеюсь поможет от поломки

Ты слишком много определённости в вопрос влил, вопросы должны быть общими и минимально конкретизированными и вливать информацию либо если её прямо запрашивают, либо надо ты решил выбрать ветку обсуждения, либо надо обсуждение оживить.
В твоём случае вопрос правильно звучать будет так:

Хочу подстраховаться на случай издыхания ssd, как сделать так чтобы граб(2) мог загрузить ОС после того, как SSD из-за сбоя станет доступным только для чтения?

Ответ:
Сделай так чтобы граб работал с раздела только для чтения.
Первому грабу при загрузке по моему без разницы доступен раздел для чтения или нет.

без uuid-метки было легче... теперь одним угадыванием sda sdb не обойдёшься

издыхания
только для чтения

что за чушь? из 2 ссд у меня дохло 2 и безвозвратно, никаким RO и не пахнет. либо крестик сними, либо рясу надень.

Значит у тебя очень старые ssd, про новые говорят что они уходят в ro.
Сам я не видел и по этому не знаю.

Но ведь смысл выделенного /boot как раз в том, что оно НЕ LVM. По идее, /boot располагается на обычном разделе. Я бы сделал на linux raid.

решено. дефолт мдадм рэйд1 сделал