ZFS на LUKS, не распознанном при начальной загрузке

У меня есть 6 физических дисков в RAID-Z2, который я намереваюсь один за другим преобразовать в устройства dm-склепа.

Мой процесс был примерно:

  1. dd if=/dev/zero of=/dev/sdf
  2. Создайте файл ключей /etc/crypttab.d/crypt-1.key
  3. cryptsetup luksFormat /dev/sdf
  4. Добавить crypt-1 <raw-disk-uuid> /etc/crypttab.d/crypt-1.key luks кому: /etc/crypttab
  5. cryptsetup luksOpen /dev/sdf crypt-1
  6. zfs replace my_pool <raw-disk-uuid> /dev/mapper/crypt-1

После того как перепосеребрение было закончено (который хорошо работал), я перезагрузил машину для проверки установки прежде, чем продолжиться к другим дискам. То, что я нашел, однако, было этим маркированный ZFS crypt-1 как UNAVAIL.

ls /dev/mapper проверенный, что dm-склеп активировал контейнер LUKS правильно. Выполнение zpool online my_pool crypt-1 причины ZFS, чтобы начать повторно серебрить, но затем завершает и возобновляет здоровую операцию способом секунд.

Я предполагаю, что устройство dm-склепа просто не загружается, когда ZFS сначала пробует к доступам my_pool? Действительно ли это - вопрос порядка загрузки, или я должен использовать другой идентификатор для устройства LUKS в /etc/crypttab? Как я удостоверяюсь, что ZFS видит эти устройства LUKS на перезагрузке?

Это - a systemd поле (Дуга), если это имеет значение.

Спасибо!


РЕДАКТИРОВАНИЕ 1:

Во время cryptsetup создания я использовал идентификаторы SCSI (например. /dev/sdf) инициализировать устройство с LUKS. Однако в /etc/crypttab Я указываю устройства через UUID базового физического диска. cryptsetup утилита, чувствительная к тому, как Вы определяете цели? Другими словами, сделайте я должен восстановить мой cryptsetup и передайте его диск UUID вместо имени SCSI?


РЕДАКТИРОВАНИЕ 2:

Я вижу следующее ls -alsvh /dev/disk/by-id:

0 lrwxrwxrwx 1 root root  10 Jul  8 08:18 dm-uuid-CRYPT-LUKS1-6bed03ceaafe4539a375536d11309ff0-locker-1 -> ../../dm-0

Из того, что я знаю, если это находится в /dev/disk/by-id это - по определению? - не подлежащий изменению (даже через перезагрузки). Я заменю определение dm-crypt-name locker-1 в моей шпульке с идентификационным именем /dev/disk/by-id/dm-uuid-CRYPT-LUKS1-6bed03ceaafe4539a375536d11309ff0-locker-1 и сообщите. Тот же диск, тот же контейнер LUKS, просто другой способ обратиться к нему.


РЕДАКТИРОВАНИЕ 3:

Мое предложение от редактирования № 2 выше не работало. Я должен был вытереть диск и пере -cryptsetup устройство, потому что ZFS не позволил бы мне заменять устройство собой. После того, как перепосеребрение было завершено, я перезагрузил и zpool status DEGRADED и устройство dm-uuid-CRYPT-LUKS1-71e12fa7dc034d919e800ba89aec3b17-locker-1 UNAVAIL.

Стоит отметить это locker-1 действительно появляется в ls /dev/disk/by-id а также lsblk, таким образом, это загружается правильно. Я могу проверить это путем выполнения:

zpool online inground dm-uuid-CRYPT-LUKS1-71e12fa7dc034d919e800ba89aec3b17-locker-1

Который выходит чисто и возвращает устройство в пул.

Возможно, это происходит из-за порядка загрузки различных модулей во время начальной загрузки? Возможно, активация устройств dm-склепа сделана таким образом, что ZFS начинает импортировать пулы, прежде чем контейнер LUKS будет правильно открыт?

4
задан 9 July 2014 в 14:26
1 ответ

Вы можете попытаться экспортировать свой пул, затем выполнить symlink узлов устройств, вызывающих составные устройства, например /dev/vdevs, и запустить

zpool import -d /dev/vdevs poolname

Если vdev найден таким образом, то вы можете сделать symlinking перед импортом zpool в загрузочном процессе (или через udev, или через скрипт) в качестве обходного пути.

.
0
ответ дан 3 December 2019 в 04:26

Теги

Похожие вопросы