Во-первых, я предпочитаю упомянуть, что нашел и прочитал этот.
Я запускаю Debian Jessie со стандартным ядром 3.16. Я вручную определил массив RAID1. Но он не собирается автоматически во время загрузки. Таким образом, после попытки смонтировать FS, описанную в / etc / fstab, systemd возвращается к некоторой деградированной оболочке. Если эта строка в fstab прокомментирована, то процесс загрузки завершится, НО массив RAID недоступен. Сборка вручную не вызывает ошибок. Тогда монтаж FS несложный.
При ручной сборке массив выглядит так:
root@tinas:~# cat /proc/mdstat
Personalities : [raid1]
md0 : active (auto-read-only) raid1 sdc1[0] sdd1[1]
1953382464 blocks super 1.2 [2/2] [UU]
bitmap: 0/15 pages [0KB], 65536KB chunk
unused devices: <none>
Вот отрывок из команды blkid:
/dev/sdd1: UUID="c8c2cb23-fbd2-4aae-3e78-d9262f9e425b" UUID_SUB="8647a005-6569-c76f-93ee-6d4fedd700c3" LABEL="tinas:0" TYPE="linux_raid_member" PARTUUID="81b1bbfe-fad7-4fd2-8b73-554f13fbb26b"
/dev/sdc1: UUID="c8c2cb23-fbd2-4aae-3e78-d9262f9e425b" UUID_SUB="ee9c2905-0ce7-2910-2fed-316ba20ec3a9" LABEL="tinas:0" TYPE="linux_raid_member" PARTUUID="11d681e5-9021-42c0-a858-f645c8c52708"
/dev/md0: UUID="b8a72591-040e-4ca1-a663-731a5dcbebc2" UUID_SUB="a2d4edfb-876a-49c5-ae76-da5eac5bb1bd" TYPE="btrfs"
Информация с fdisk:
root@tinas:~# fdisk -l /dev/sdc
Disque /dev/sdc : 1,8 TiB, 2000398934016 octets, 3907029168 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
Type d'étiquette de disque : gpt
Identifiant de disque : C475BEB1-5452-4E87-9638-2E5AA29A3A73
Device Start End Sectors Size Type
/dev/sdc1 2048 3907029134 3907027087 1,8T Linux RAID
Здесь я не уверен, правильно ли указано значение типа «Linux RAID», поскольку я читал, что ожидается 0xFD, но это значение, похоже, недоступно через fdisk с таблицей разделов GPT.
Спасибо за вашу помощь
Редактировать :
Из journalctl -xb Я могу найти один след:
Apr 14 15:14:46 tinas mdadm-raid[211]: Generating udev events for MD arrays...done.
Apr 14 15:35:03 tinas kernel: [ 1242.505742] md: md0 stopped.
Apr 14 15:35:03 tinas kernel: [ 1242.513200] md: bind<sdd1>
Apr 14 15:35:03 tinas kernel: [ 1242.513545] md: bind<sdc1>
Apr 14 15:35:04 tinas kernel: [ 1242.572177] md: raid1 personality registered for level 1
Apr 14 15:35:04 tinas kernel: [ 1242.573369] md/raid1:md0: active with 2 out of 2 mirrors
Apr 14 15:35:04 tinas kernel: [ 1242.573708] created bitmap (15 pages) for device md0
Apr 14 15:35:04 tinas kernel: [ 1242.574869] md0: bitmap initialized from disk: read 1 pages, set 0 of 29807 bits
Apr 14 15:35:04 tinas kernel: [ 1242.603079] md0: detected capacity change from 0 to 2000263643136
Apr 14 15:35:04 tinas kernel: [ 1242.607065] md0: unknown partition table
Apr 14 15:35:04 tinas kernel: [ 1242.665646] BTRFS: device fsid b8a72591-040e-4ca1-a663-731a5dcbebc2 devid 1 transid 8 /dev/md0
/ proc / mdstat Я только что понял, что сразу после загрузки модуль raid1 не загружается!
root@tinas:~# cat /proc/mdstat
Personalities :
unused devices: <none>
root@tinas:~#
Таким образом, я добавил raid1 модуль к / и т.д. / модуливыпустила update-initramfs -u.
Вот соответствующий журнал:
avril 15 12:23:21 tinas mdadm-raid[204]: Generating udev events for MD arrays...done.
avril 15 12:23:22 tinas systemd-modules-load[186]: Inserted module 'raid1'
avril 15 12:23:22 tinas kernel: md: raid1 personality registered for level 1
Но массив все еще не собран:
root@tinas:~# cat /proc/mdstat
Personalities : [raid1]
unused devices: <none>
Может быть, это связано с тем, что модуль raid1, кажется, загружается после создания событий udev?
Интересная ссылка, но слишком общая
Я попытался dpkg-reconfigure mdadm : Ничего нового...
Если кто-нибудь знает, как получить следы от udev, было бы здорово. Я раскомментировал udev_log = info линия в /etc/udev/udev.conf но ничего нового не вижу ...
поиск загруженных модулей
root@tinas:~# grep -E 'md_mod|raid1' /proc/modules
raid1 34596 0 - Live 0xffffffffa01fa000
md_mod 107672 1 raid1, Live 0xffffffffa0097000
raid1 загружен, потому что я добавил его в /etc/modules, иначе раньше он загружался.
uname -r
root@tinas:~# uname -r
3.16.0-4-amd64
/etc/mdadm/mdadm.conf
root@tinas:~# cat /etc/mdadm/mdadm.conf
# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#
# by default (built-in), scan all partitions (/proc/partitions) and all
# containers for MD superblocks. alternatively, specify devices to scan, using
# wildcards if desired.
#DEVICE partitions containers
# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes
# automatically tag new arrays as belonging to the local system
HOMEHOST <system>
# instruct the monitoring daemon where to send mail alerts
MAILADDR root
# definitions of existing MD arrays
ARRAY /dev/md/0 metadata=1.2 UUID=a930b085:1e1a615b:93e209e6:08314607 name=tinas:0
# This configuration was auto-generated on Fri, 15 Apr 2016 11:10:41 +0200 by mkconf
Я только что заметил кое-что странное: последняя строка /etc/mdadm/madm.conf автоматически создается командой mdadm -Es и показывает устройство под названием / dev / md / 0 а когда я вручную собираю массив, я получаю / dev / md0 который я использовал при создании массива с mdadm --create...
Кроме того, я получил эту информацию из подробного update-initramsfs :
Adding module /lib/modules/3.16.0-4-amd64/kernel/drivers/md/raid10.ko
I: mdadm: using configuration file: /etc/mdadm/mdadm.conf
I: mdadm: will start all available MD arrays from the initial ramdisk.
I: mdadm: use `dpkg-reconfigure --priority=low mdadm` to change this.
Таким образом, я попробовал, но он просто не работает: нет массива после перезагрузки.
В /etc/mdadm/madm.conf я изменил имя устройства ARRAY с / dev / md / 0 на ARRAY / dev / md0
Я также заметил, что в то время как в initramfs busybox после выполнения mdadm --assemble --scan ARRAY создается как / dev / md0 и помечен как активен (только для автоматического чтения)
Я только что понял initramfs прочее. Я знал, что ядро использует какой-то RAM-диск, но не знал больше. Сейчас я понимаю, что этот initramfs должен содержать все данные, необходимые для собрать RAID-массив при загрузке в пользовательском пространстве. Таким образом, важность обновления этого статического файла /boot/initrd.img-версия чтобы отразить все важные изменения.
Поэтому я подозревал, что мой файл /boot/initrd.img-3.16.0-4-amd64 был беспорядочным, и попытался создать новый, выполнив эту команду:
# обновление-initramfs -t -c -v -k 3.16.0-4-amd64
Обратите внимание, что у меня там только одно ядро и, следовательно, только один соответствующий initramfs.
Но после перезагрузки я снова столкнулся с оболочкой initramfs, потому что ядру не удалось смонтировать файловую систему / dev / md0, используемую в / etc / fstab.
Я уже проверил состояние сервера, находясь в busybox:
Вот тогда мое ручное вмешательство:
mdadm --assemble --scan
/proc/mdstat утверждает, что устройство / dev / md0 активный и только автоматическое чтение. Итак, я выдаю:
mdadm --readwrite /dev/md0
перед выходом из busybox.
Вы можете зеркалировать диски с помощью самой btrfs, вместо того, чтобы создавать эту файловую систему поверх программного рейда: mkfs.btrfs -d raid1 /dev/sdc /dev/sdd
В противном случае попробуйте:
umount /dev/md0 if mounted
mdadm --stop /dev/md0
mdadm --assemble --scan
mv /etc/mdadm/mdadm.conf /etc/mdadm/mdadm.conf.bak
/usr/share/mdadm/mkconf > /etc/mdadm/mdadm.conf
Если cat /proc/mdstat показывает правильный вывод, затем создайте свою файловую систему и смонтируйте ее, используйте blkid чтобы получить UUID для / dev / md0 и соответственно отредактировать / etc / fstab.
Если у вас все еще есть проблемы, вы можете попробовать это, прежде чем приступать к приведенным выше инструкциям:
mdadm --zero-superblock /dev/sdc /dev/sdd
mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdc1 /dev/sdd1
Я тестировал это на системе, работающей под управлением Debian Jessie с ядром 3.16.0-4-amd64, и записал таблицы разделов gpt на два блочных устройства, которые я зеркалировал вместе. Массив правильно собран при загрузке и смонтирован, как указано.
У меня была аналогичная проблема, хотя мой тип раздела - MBR (он же «DOS»), а не GPT. Так что я не уверен, насколько это связано с вашей собственной проблемой. Я хотел опубликовать его здесь как ответ, потому что внимательно прочитал ваш вопрос, пытаясь решить свою проблему.
Мои симптомы были очень похожи в том, что / boot находится на mdadm RAID1, / находится на LVM на другом mdadm RAID1, и ядро загружается нормально, но не может смонтировать корневую файловую систему, потому что группа томов, содержащая его, не может быть найдена. Оказалось, что это произошло потому, что ни одно из устройств RAID1 на самом деле не работало, хотя были загружены правильные модули ядра.
В моем случае проблема заключалась в том, что я установил тип раздела для устройств, лежащих в основе моего устройства RAID1, на тип FD («Linux RAID Autodetect»). Изменение типа на DA («Данные, отличные от FS») устранило проблему.
Я получил идею от https://raid.wiki.kernel.org/index.php/Partition_Types
Ситуация возникла из-за того, что я ранее выполнял разбиение вручную в процессе установки Debian и выбрал этот тип раздела (это было когда-то, когда я впервые начал использовать Linux RAID до того, как начальные RAM-диски были чем-то вроде, правильный выбор).
Что ж, я бы хотел найти решение, но сервер не работал 10 дней, я решил его обновить, удалил все доказательства преступления. Сначала попробовал перейти с jessie на testing. Это не удалось. Итак, я наконец произвел чистую установку Debian Testing.
Не знаю, откуда взялась проблема, но почти уверен, что она возникла после некоторого обновления. Несколько сообщений на форуме заставили меня подумать, что это связано с ядром 3.16.0-4-amd64, но это предположение.
Не знаю, как отметить вопрос ЗАКРЫТО ...