В рамках автоматизированной системы создания виртуальных машин блочное устройство монтируется во временную папку (/ tmp / something). Различные сценарии устанавливают и настраивают виртуальную машину перед ее первым запуском.
Недавно что-то изменилось, временное монтирование занято и отказывается размонтировать. Пытаясь определить, что еще может держать файл открытым, я проверил:
Тесты запускаются с правами root
Ни один из вышеперечисленных тестов не дал результатов, указывающих на использование файловой системы, однако umount -f по-прежнему жалуется «Устройство или ресурс занят» / «Устройство занято».
Какие еще тесты я должен попробовать, чтобы найти истинную первопричину и, таким образом, надеюсь, исправить застрявшее монтирование без перезагрузки в системе, которую я сейчас не могу перезагрузить в течение некоторого времени, а также предотвратить повторение этого?
Также / сомнительно / (но я не знаю, как это проверить) загружены модули ядра из временного монтирования, поскольку во временном монтировании установлена другая версия Linux, чем на хосте.
правки
Если это часть процесса сборки, я предполагаю, что вам все равно потребуется перезагрузка в какой-то момент. Попробуйте вставить в процесс "ленивый" размонтирование. Использовать umount -l /tmp и посмотрите, поможет ли это вам преодолеть этот барьер в процессе.
Одна причина umount может потерпеть неудачу, если основной IP-адрес удаленного устройства изменился.
Я видел это, когда я удаленно монтировал ноутбук со своего настольного сервера. Первое монтирование происходит с IP-адресом A. Хотя перезагрузка ноутбука дает ему адрес B, мой рабочий стол продолжает записывать адрес A как адрес ноутбука. Я вижу это, когда проверяю IP-адрес, возвращаемый mount команду и сравнив ее с текущим адресом ноутбука.
umount -lУ нас та же проблема, но, похоже, она возникает только в том случае, если корневой файловой системой виртуальной машины является ext4. ext3 работает корректно. Я знаю, это звучит странно, но это может быть ошибка ядра, описанная в http://www.phoronix.com/scan.php?page=news_item&px=MTIxNDQ
Если это так, мы должны просто дождаться исправления ядра ИЛИ не устанавливать новую виртуальную машину на основной машине. Установка его из временного запуска Linux в качестве виртуальной машины работает правильно, потому что машина перезагружается без перезагрузки основной машины.
Вы пробовали ext3? Если нет, попробуйте установить на ext3, вы можете преобразовать его в ext4 позже, если использование ext4 имеет решающее значение (и это описано в http://www.debian-administration.org/article/643/Migrating_a_live_system_from_ext3_to_ext4_filesystem)