Использование udevadm для ожидания сканирования scsi для завершения внутри initramfs?

Где проблема: я использую ArchLinux с archzfs, а привязка zfs в моих initramfs иногда пытается (и не удается) импортировать пулы слишком рано, прежде чем scsi-сканирование всех дисков, используемых ZFS, будет завершено. Это приводит к сбою загрузки, поскольку zfs используется в моей системе также как корневая файловая система. Чтобы решить эту проблему, я ищу некоторую команду, которая блокирует выполнение крюка zfs (это просто скрипт пера, сохраненный и исполняемый внутри изображения initramfs) до завершения сканирования scsi.

Как это относится к udevadm: если бы я использовал linux ядро ​​до 3.6, я бы просто добавил modprobe scsi_wait_scan ; rmmod scsi_wait_scan ; modprobe scsi_wait_scan ; rmmod scsi_wait_scan ; блокировать выполнение крюка zfs до завершения сканирования scsi. Однако я использую ядро ​​4.4, и этот модуль недоступен. Я думаю использовать вместо этого udevadm settle , но я не совсем уверен, действительно ли это полезно для такого использования. Это связано с тем, что в ArchLinux уже есть крюк udev, который выполняется до привязки zfs и делает следующее:

run_hook() { msg ":: Triggering uevents..." udevadm trigger --action=add --type=subsystems udevadm trigger --action=add --type=devices udevadm settle }

Итак, следуя https://bugs.launchpad.net/ironic-python-agent/+bug/1551300, я решил вместо этого добавить две строки в zfs hook (до импорта zfs)

# Force udev to list all devices, will block until scsi scan is completed udevadm trigger --verbose --dry-run --type=devices --subsystem-match=scsi_disk udevadm settle

Имеет ли это смысл? Или я должен попробовать что-то другое? Проблема с тестированием решения заключается в том, что проблема возникает только изредка, а это значит, что даже если я перезагружу компьютер несколько раз, не увидев его снова, это не гарантирует, что проблема была исправлена. Итак, заданный здесь вопрос заключается не в том, чтобы исправить мои initramfs для меня, а для подтверждения (или отказа), может ли udevadm использоваться для ожидания завершения сканирования scsi, и если так – как.

One Solution collect form web for “Использование udevadm для ожидания сканирования scsi для завершения внутри initramfs?”

Интересно, что, по-видимому, удевадм оседает, не препятствует загрузке zfs, прежде чем сканирование устройств scsi завершилось. Я, наконец, исправил проблему, вызывая синхронное сканирование scsi, например

 bronek@gdansk ~ % cat /etc/modprobe.d/zfs.conf # Enforce synchronous scsi scan, to prevent zfs driver loading before disks are available options scsi_mod scan=sync 
  • Изменить раздел дисковой части ZFS Raid
  • zfs-fuse: включение сжатия не влияет
  • Неверный порядок запуска службы, когда не загружается в однопользовательский режим
  • Создать RAID-Z2 в деградированном состоянии?
  • Получение уровня версии FreeBSD для загрузочной среды ZFS, которая смонтирована, но не загружена
  • ZFS под Linux, это работает?
  • Ошибка экспорта / импорта ZPool
  • Как заменить диск в резервном пуле ZFS?
  • ZFS Pools Nestable?
  • ZFS ACL (NFS4 ACL)
  • Почему я не могу импортировать пул ZFS без разделения диска данных на fdisk?
  • Linux и Unix - лучшая ОС в мире.