Luks2 сверху RAID5, не монтирующегося правильно
Система: 64-разрядная Ubuntu 18.04.
У меня есть набег 5 массивов (md0) состоящий из 4 устройств (sdb1, sdc1, sdd1, sde1). Я зашифровал/dev/md0 как luks2 объем (crypt0), и я отформатировал/dev/mapper/crypt0 как lvm физический том, на который я поместил группу vg1 объема. Все хорошо работает.
Моя проблема состоит в том, что после перезагрузки, хотя/dev/md0 действительно существует, и mdadm-Ds показывает соответствующую информацию, и объем склепа/dev/mapper/crypt0 также существует, pvs не показывает/dev/mapper/crypt0 PV, и vg1 не появляется.
Если, однако, я даю команду "cryptdisks_stop crypt0", сопровождаемый "cryptdisks_start crypt0",/dev/mapper/crypt0 внезапно распознан как PV, VG и мой LVs обнаруживаются как нормальные. Используя hexdump на шоу/dev/mapper/crypt0, что изменения двоичных данных между остановкой и (ре) запускаются.
Моя первая мысль была то, что монтирование удач происходило до настраиваемого устройства набега. Но конечно монтирование перестало бы работать в этом случае, не оставило бы меня с устройством, содержащим неправильные данные?
Я боролся с этим в течение 2 дней теперь и был бы очень признателен за любые предложения.
FWIW, соответствующая строка в/etc/mdadm/mdadm.conf:
/dev/md0 metadata=1.2 name=maggie:0UUID=c32cf5ee:3470d676:87544e31:328f5d5f МАССИВА
Да, я выполнил обновление-initramfs-u-k все и проверил initramfs версию.
И строка в/etc/crypttab: (с некоторыми деталями, скрытыми здесь, но корректными)
crypt0/dev/md0 luks2, заголовок =
1 ответ
Решенный. Моя собственная глупость.
После борьбы с этим я решил сделать более подробный журнал процесса начальной загрузки путем питания командной строки Linux debug=2 параметр, и это сделало это.
"luks2" параметр в/etc/crypttab файле должен был быть просто "luks". Открытие диска с cryptdisk_start не дало ошибки вообще, но этого было достаточно, чтобы заставить systemd дросселировать, когда это встретилось с ним во время начальной загрузки.Моя вина.