Моя старая установка (FC11) достигла EOL, и я попытался переустановить FC14 в его корневой файловой системе RAID1.
У меня сейчас возникли подозрения, что теперь, после установки, ФС не полностью обыскивается. Вопрос в том, правда ли это подозрение, и если да, то как это исправить.
[root@atlas dev]# cat /proc/mdstat
Personalities : [raid1]
md127 : active raid1 sda[0]
732571648 blocks super external:/md0/0 [2/1] [U_]
md0 : inactive sdb[1](S) sda[0](S)
4514 blocks super external:imsm
unused devices: <none>
[root@atlas dev]#
md127 выглядит как дочерний контейнер md0, но в качестве явного устройства указывает sda [0], но не sdb. Я полагаю, что я убегаю от sda, читая это, а sdb не работает.
Проблема в том, что с тех пор в FS произошли некоторые действия, поэтому нельзя считать, что оба диска синхронизированы. sdb, вероятно, нужно пересобрать. Однако у меня есть полная резервная копия, поэтому я готов пойти на просчитанный риск.
Обратите внимание, что файловая система является корневым устройством. (однопользовательский режим?)
Также приветствуются любые объяснения того, как читать вывод mdstat. Я предполагаю, что мне нужно как-то добавить sdb из контейнера md0 в md127.
Выдержка ядра:
dracut: Starting plymouth daemon
dracut: rd_NO_DM: removing DM RAID activation
pata_marvell 0000:03:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
pata_marvell 0000:03:00.0: setting latency timer to 64
scsi6 : pata_marvell
scsi7 : pata_marvell
ata7: PATA max UDMA/100 cmd 0xcc00 ctl 0xc880 bmdma 0xc400 irq 16
ata8: PATA max UDMA/133 cmd 0xc800 ctl 0xc480 bmdma 0xc408 irq 16
dracut: Autoassembling MD Raid
md: md0 stopped.
md: bind<sda>
md: bind<sdb>
dracut: mdadm: Container /dev/md0 has been assembled with 2 drives
md: md127 stopped.
md: bind<sda>
md: raid1 personality registered for level 1
md/raid1:md127: active with 1 out of 2 mirrors
md127: detected capacity change from 0 to 750153367552
md127: p1 p2
md: md127 switched to read-write mode.
вывод --detail --scan:
ARRAY /dev/md0 metadata=imsm UUID=e14582dd:1863c14a:fb0d98f0:5490080b
ARRAY /dev/md127 container=/dev/md0 member=0 UUID=c0cf0b37:bc944eec:ac93d30e:ee2f423e
/etc/mdadm.conf:
# mdadm.conf written out by anaconda
MAILADDR root
AUTO +imsm +1.x -all
ARRAY /dev/md0 UUID=e14582dd:1863c14a:fb0d98f0:5490080b
ARRAY /dev/md127 UUID=c0cf0b37:bc944eec:ac93d30e:ee2f423e
Обновить:
Дождавшись большей части дня, я укусил пулю, проверил свои резервные копии, загрузился в однопользовательском режиме и там я мог просто mdadm --manage / dev / md127 --add / dev / sdb
Восстановление заняло около 3 часов (сверхурочные неоплачиваемые). Вроде все работает и выглядит целым.
Я также помню, что вмешивался в fakeraid, прежде чем решил перейти на программный RAID, хотя и на других дисках. Может быть, md0 - это пережиток, что-то, что проскользнуло из-за плохо восстановленного / и т.д., а затем билось, пока не заработало. Однако при следующей переустановке он взорвался мне в лицо. Эксперименты, чтобы заставить его работать, вероятно, зарезервировали для него некоторую информацию.
Страшно то, что оба массива теперь содержат одни и те же диски, И что md0 ненадолго активируется во время загрузки. Я получаю предупреждения, которые, кажется, сигнализируют о том, что md127 является потомком md0, что немного пугает удаление. Но я выкопаю загрузочный диск и на следующий день проверю его, у меня будет время для системного администрирования. (после создания инкрементной полной резервной копии, конечно же)
md127 имеет два раздела (большой рут + своп), оба смонтированные. md0 не активен (и я не решаюсь активировать его, так как он разделяет диски), поэтому я не знаю, какие у него разделы.
Поскольку md127 теперь работает (2/2 UU), теперь необходимо выяснить, можно ли безопасно удалить md0 (md127 дочерний элемент md0?), И если да, то как избежать проблем при будущих установках.
Возможно, потребуется удалить и некоторые метаданные на диске, чтобы их не забрала следующая установка.
Правильнее всего сначала выяснить, какой раздел смонтирован. Затем вам нужно деактивировать другой, чтобы вы могли извлечь из него диск. Затем увеличьте смонтированный диск в mdadm, чтобы добавить к нему новый диск, и программное обеспечение md синхронизирует текущий смонтированный раздел с другим диском. После этого cat'ing / proc / mdstat должен отображать только одно устройство md с обоими перечисленными дисками (и, вероятно, одно все еще синхронизируется). (и, возможно, исправить fstab)
Многое из того, что здесь нужно повторять, не буду, так как linux raid вики довольно хорош и содержит большую часть документации, которую вам нужно прочитать (и с хорошими примерами).
Однако большинство людей забывают, что ядру Linux требуется initramfs, содержащий необходимую информацию о диске. Поэтому каждый раз, когда вы меняете конфигурацию md, разумно воссоздать initramfs с помощью dracut:
dracut -v --mdadmconf new_image.img KERNEL-VERSION-STRING
Затем укажите grub на new_image.img.
Раньше я совершал ошибку, забыв об этом после удаления диска из массива, и в конечном итоге загрузился с одного диска, а не с должным образом зеркального диска. Ситуация очень похожа на ту, в которой вы оказались.