Как mdустройства собираются при загрузке в Ubuntu? Действительно ли /etc/mdadm/mdadm.confуместный фактор здесь?

Мой mdadm.confзвук, и я проверил это, находясь в среде спасательного CD. При запуске mdadm -A --scanон находит и назначает имена устройств по желанию. mdadm.confСодержит AUTO -allвынимать все автоматизм от сборки массивов.

Что мне нужно сделать, так это уметь автоматически собирать mdустройства, как указано во mdadm.confвремя загрузки, или что при сборке он учитывает super-minorзначение для массива 0,9 и name(по-видимому <hostname>:<super-minor>) для массивов 1,2 и делает правильную работу без него mdadm.conf. Какой кусок головоломки мне не хватает?

У меня следующая проблема. Есть два mdустройства с RAID1 ( md0и md1) и одно с RAID6 ( md2). Я имею в виду их по нужным названиям устройств. md0имеет версию метаданных 0.9, два других имеют версию 1.2. md0карты /и другие две не имеют отношения к загрузке .

Загрузочный диск разделен на GPT. На нем есть клей "BIOS Boot Partition" ( sda1). grub-install --no-floppy /dev/sdaсообщает об успехе.

• md0 == sda3 + sdb3
• md1 == sda2 + sdb2
• md2 == sdc + sdd + sde + sdf + sdg + sdh
• sda1и sdb1"BIOS Boot Partition" каждый

GRUB2 доволен /boot/grub/devicemapя дал , и я добавил part_gpt, raid, mdraid09и ext2к модулям для предварительной нагрузки в GRUB2.

Поскольку у меня все еще был корневой том в среде аварийного восстановления, я просто смонтировал все, а затем chrootвставил в него:

mkdir /target
mount /dev/md0 /target
mount -o bind /dev /target/dev
mount -o bind /dev/pts /target/dev/pts
mount -o bind /sys /target/sys
mount -o bind /proc /target/proc
chroot /target /bin/bash

Оттуда я сбрасываю super-minorна md0(с метаданными 0,9) и nameна md1и md2. Я также проверил, что это работает с помощью mdadm --detail .... Помимо этого я настроил /etc/default/grub, запустить, update-grubа также grub-install --no-floppy /dev/sdaи grub-install --no-floppy /dev/sdb.

После этого при загрузке меня всегда закапывают в initramfsоболочку восстановления, поскольку корневая файловая система не может быть смонтирована. Причина, по- /proc/mdstatвидимому , после проверки заключается в том, что соответствующее mdустройство даже не собирается и не запускается. Не говоря уже о том, что два других диска (метаданные версии 1.2) получают номер устройства где-то в диапазоне 125..127.

Примечание: GRUB2 появляется с загрузочного диска. Так что, по крайней мере, он был вставлен правильно. Проблема заключается в переходе от начальной rootfsк правильной корневой файловой системе.

Базовый процесс загрузки

надрываться

1. Grub читает свой диск, md, файловую систему и т. Д. Код из MBR.
2. Grub находит свой раздел / boot и считывает с него все остальное. Включая конфигурацию и любые модули, которые указывает конфигурация, необходимо загрузить.
3. Grub следует инструкциям в конфигурации, которые обычно говорят ему загрузить ядро ​​и initramfs в память и выполнить ядро.

Существует резервный режим, когда Grub не может прочитать файловую систему - либо потому, что не было достаточно места для встраивания всего этого кода в загрузочную запись, либо потому, что он не знает файловую систему или слои под ней. В этом случае GRUB встраивает список секторов и читает код из них. Это гораздо менее надежно и лучше избегать. Это может даже быть в состоянии сделать ядро ​​и initramfs подобным образом (не уверен).

ядро

Затем ядро ​​берет на себя управление и выполняет основную аппаратную инициализацию. Этот этап довольно быстрый. Затем ядро ​​распаковывает initramfs в tmpfs и ищет /initна этом tmpfs. Затем он выполняется (в обычном смысле, ядро ​​работает на этом этапе) /init. Это, кстати, простой старый скрипт оболочки.

Initramfs

Вы можете извлечь initramfs вручную, выполнив что-то вроде mkdir /tmp/foo; cd /tmp/foo; zcat /boot/initrd.img-3.8-trunk-amd64 | cpio -idmv.

Initramfs отвечает за загрузку всех драйверов, запуск udev и поиск корневой файловой системы. Это шаг, который вам не удался - он не может найти корневую файловую систему, поэтому выручает.

После завершения initramfs она монтирует корневую файловую систему и передает управление в / sbin / init.

Загрузка системы

На данный момент ваш инициатор вступает во владение - я думаю, что Ubuntu в настоящее время использует выскочку.

Что сломано

Я не совсем уверен, что не работает (отчасти, признаюсь, потому что я гораздо лучше знаком с тем, как он работает в Debian, чем с Ubuntu, хотя он похож), но у меня есть пара предложений:

• У initramfs есть своя копия mdadm.conf. Возможно, вам просто нужно бежать, update-initramfs -uчтобы исправить это.
• Посмотрите на загрузочные сообщения. Там может быть ошибка. Избавьтесь от «quiet» и «splash» и, возможно, добавьте «verbose» в строку ядра, чтобы увидеть их.
• В зависимости от используемого хранилища может потребоваться установить параметр rootdelay.
• Когда вы выводите в командную строку, у вас не так много команд, но у вас есть mdadm. Попробуйте выяснить, что пошло не так. Если вы решите проблему, загрузка может продолжиться.

Ладно, я узнал, что мне не хватает всего лишь одного куска. Эти initrdизображения не были обновлены после переделывая mdadm.conf.

Так что я сделал?

Я загрузился в спасательную систему установочного компакт-диска Ubuntu Server. Выберите выполнить оболочку из среды установщика и не использовать корневую файловую систему. Затем (комментарии с добавлением #):

cat /proc/mdstat
# It showed me md125, md126 and md127
# Stop those:
mdadm -S /dev/md125
mdadm -S /dev/md126
mdadm -S /dev/md127
# Assemble the root volume (meta-data version 0.9)
mdadm -Av --update=super-minor --run /dev/md0 /dev/sda3 /dev/sdb3
# Assemble the other two arrays, updating the names (meta-data version 1.2)
mdadm -Av --update=name --run /dev/md1 /dev/sda2 /dev/sdb2
mdadm -Av --update=name --run /dev/md2 /dev/sdc /dev/sdd /dev/sde /dev/sdf /dev/sdg /dev/sdh
# Check the outcome:
cat /proc/mdstat
# See preferred minor and names:
mdadm --detail /dev/md0
mdadm --detail /dev/md1
mdadm --detail /dev/md2
# All is fine, so proceed ...
# Create directory for the chroot:
mkdir /target
# Mount root volume on it
mount /dev/md0 /target
mount -o bind /dev /target/dev
mount -o bind /proc /target/proc
mount -o bind /sys /target/sys
mount -o bind /dev/pts /target/dev/pts
# Now chroot into it:
chroot /target /bin/bash
# Fix up the GRUB device map to match what 'mdadm --detail' gives as UUID:
nano /boot/grub/devicemap

нано

Я пользуюсь, nanoпотому vimчто буквально у меня болит голова из-за тупого терминала. Вы можете использовать Ctrl+, xчтобы выйти (предложит сохранить, Ctrl+ kобрезать текущую строку, Ctrl+ uвставить строку обрезки, Ctrl+ oсохранить буфер.

Это звучит сложно, но может быть сделано и с bashодной строкой (хотя и длинной):

for i in /dev/disk/by-id/md-uuid-*; do DEV=$(readlink $i); echo "(${DEV##*/}) $i"; done|sort|tee /boot/grub/devicemap

Это использует текущие имена mdустройств и их UUID и создает devicemapдля просмотра GRUB2. Таким образом, предполагая, что все было сделано правильно, у вас уже должны быть правильные имена устройств.

Далее:

# Edit the grub config
nano /etc/default/grub

Убедитесь, что он содержит:

GRUB_PRELOAD_MODULES="part_gpt raid mdraid09 ext2"

если вы настроили свой /или /bootраздел для метаданных версии 1.2, используйте mdraid1xвместо mdraid09.

Дальше:

# Update the initrd images
update-initramfs -c -k all

Этот шаг был недостающим звеном . Это, очевидно, гарантирует, что mdadm.confэффект вступает в силу при загрузке.

# Install GRUB2 on the two drives eligible for booting, just to be sure
grub-install --no-floppy /dev/sda
grub-install --no-floppy /dev/sdb
# Make the latest config take effect
update-grub

После этого выйдите chrootи перезагрузитесь.