Это чудо. Каким-то образом я восстановил работоспособность массива. Вот что я сделал:
Я подключил все три диска и перезапустил (снова с живым -сеансом USB ). Оглядываясь назад, можно сказать, что manjaro не был лучшим выбором для среды восстановления, поскольку в нем уже был установлен mdadm, и в результате он уже пытался запустить массив (как /dev/md127 ). Я обнаружил это при попытке вручную запустить массив.
mdadm --assemble --scan
Когда я это сделал, он пожаловался, что уже есть активный массив (или что-то в этом роде ). Я вспомнил, что /dev/md127 иногда запускается автоматически, поэтому я остановил этот массив и попытался вручную запустить свой.
mdadm --stop /dev/md127
mdadm --assemble --scan
Это тоже не сработало. Затем я попытался указать разделы на каждом диске для использования при сборке массива.
mdadm --assemble /dev/md0 /dev/sdb1 /dev/sdc1 /dev/sdd1
Это сработало! Затем я проверил состояние массива с помощью mdadm --examine /dev/md0
. Как ни странно, он сказал, что массив состоит из 3/3 дисков. Когда я проверил cat /proc/mdstat
, не было никаких указаний на то, что диск 2 массива перестраивался (, помните,изначально диск 2 был исключен из массива после отключения питания ). Произошло какое-то чудо, и диск 2, который восстанавливался в ледяном темпе, когда я выключил компьютер, должен был быть в порядке, и на этот раз mdadm каким-то образом принял его в массив.
Затем я попытался получить доступ к массиву, чтобы скопировать мои данные на новый диск, который я купил. Это не сработало. Простое перечисление содержимого каталога приводило к зависанию команды ls
. В dmesg
снова было множество ошибок ввода-вывода, конкретно относящихся к диску 3 (\dev\sdd ).
Я попытался отменить команду ls
, и мне потребовалось несколько попыток CTRL -C и несколько минут ожидания, прежде чем я снова получил командную строку. В этот момент меня попытались еще раз проверить массив с помощью mdadm --examine /dev/md0
. Затем он распознал диск 3 как аппаратный сбой и исключил его из массива. В массиве теперь только диск 1 (/dev/sdb, полностью исправный диск ), и диск 2 (/dev/sdc, диск, который изначально был выкинут из массива в самом начале всего этого ).
Я еще раз попытался получить доступ к массиву, и теперь это сработало! Я смог просмотреть все свои файлы с помощью ls
и даже с помощью файлового браузера. В этот момент я начал копировать все свои важные файлы на дополнительный диск, который я купил. Я почти закончил этот процесс.
В конце концов, это хорошее напоминание о том, что я регулярно делаю резервные копии своих файлов на отдельном устройстве. У меня была привычка это делать, но последние год или два я проявлял небрежность. Извините, если этот пост получился слишком длинным и не самым конкретным. Я не помню точных результатов каждой команды.
TL;DR Я выключил компьютер и перестал паниковать. Затем у меня было время, чтобы составить план подхода к проблеме. Это хорошее напоминание о том, что необходимо поддерживать резервные копии дат -–-.
В данном случае проблема возникла с сервером dhcp (6-е окно, которое открывается и тут же обслуживает ). Клиенту просто не дают IP.
Проблема может заключаться в механизмах безопасности используемого вами дистрибутива. Например, в apparmor
и SELinux. В моем случае все сводилось к apparmor.
Я обнаружил, что демон dhcpd не может получить доступ к файлу конфигурации, расположенному в папке /tmp/fluxspace/
. Ему тоже нужно что-то в папке /var/
.
Чтобы убедиться, что проблема в apparmor, выполните команду :dmesg | grep dhcp
. Если в выводе есть строка apparmor="DENIED"
, то проблема в apparmor.
Есть 2 решения проблемы:
"подход Kali Linux" :просто отключите apparmor. Это можно сделать с помощью команды sudo systemctl disable apparmor
. Затем вам необходимо перезагрузиться. Это полностью отключит apparmor в вашей системе (для всех программ ).
"менее деструктивный подход" :если вы не хотите отключать демон apparmor (, что, вероятно, правильно, если он изначально был активен ), вы можете изменить для него профиль dhcp сервера. Для этого откройте файл /etc/apparmor.d/usr.sbin.dhcpd
любым удобным редактором. Если вы прокрутите этот файл, вы увидите строки типа /usr/lib/something/* r,
. Вам нужно будет вставить 4 строки рядом с ними:
/tmp/* rw,
/tmp/** rw,
/var/* rw,
/var/** rw,
После этого нужно сохранить изменения и либо перезагрузить компьютер, либо перезагрузить профиль apparmor командой sudo service apparmor reload
.
После этого точка доступа Fluxion должна работать правильно.
П.С. На самом деле, изменения в профиле dhcp, которые я предложил, можно сделать гораздо более жесткими без последствий для флюксиона. Настройки я сделал с прицелом на будущее -если мне нужно будет использовать dhcp с другой программой из репозитория Kali, чтобы возможно не было необходимости заново редактировать файл профиля apparmor для dhcp. Подробнее можно прочитать здесь .