Раздел подкачки не распознал (Дисковод с UUID = … еще не готов или не существует),

У меня была такая же проблема при использовании зашифрованного раздела подкачки. Ни общее Swap FAQ , решение Puny Geek для «cryptswap1 еще не готово или не присутствует» сообщение , ни ответ Брайама на на этот вопрос [ 1113] решил проблему для меня - иногда своп был доступен, иногда нет. После многих перезагрузок и некоторых поисков, я думаю, что нашел основную причину:

Похоже, что я был не единственным, кто столкнулся с этой проблемой , поскольку, как описано здесь , лучшим решением было бы связать раздел подкачки через его идентификатор диска вместо его пути /dev/sd*. Это можно найти, запустив

ls -l /dev/disk/by-id/

, в котором перечислены идентификаторы дисков для всех разделов, включая раздел подкачки, который в моем случае был

ata-TOSHIBA_MQ01UBD100_73JATD5GT-part3 -> ../../sdb3

Дважды проверьте в программе, подобной Disk Utility, что часть -> ../../sdb* этой строки действительно является разделом, который вы намереваетесь использовать для обмена, так как это (как я уже говорил) иногда может менять имена. Как всегда, имейте это в виду:

Осторожно: возиться с cryptsetup и дисковыми устройствами опасно для данных и ОС. Я лично сделал полную резервную копию на отдельном диске, а затем отключил его, чтобы убедиться, что он не будет вовлечен в любую неудачу.

Затем отредактируйте файл /etc/crypttab, используя ссылку ID вместо «сырого» пути, в моем случае эта строка

cryptswap1 /dev/disk/by-id/ata-TOSHIBA_MQ01UBD100_73JATD5GT-part3 /dev/urandom swap,cipher=aes-cbc-essiv:sha256

Я думаю, этот метод должен использоваться по умолчанию для новых установок, так как, очевидно, никогда нельзя быть уверенным в путях /dev/sd* ... что меня несколько беспокоит, так как у меня есть ощущение, что существует гораздо больше сценариев и программного обеспечения, которые все еще полагаются на эти пути (вместо идентификаторов, меток или UUID) остаются неизменными при перезагрузках.

TODO:

Я не проверял, работает ли возобновление выхода из спящего режима с этой настройкой, поскольку, похоже, это зависит от UUID (которого у моего раздела подкачки не было ), как указано на этой странице: https://altinukshini.wordpress.com/2012/10/15/devmappercryptswap1-is-not-ready-yet-or-not-present/

[ 1129] Обновление:

Спящий режим пока работает нормально. Надеюсь, что это решает эти проблемы и для других!

Короткий ответ:

Проблема UUID:

У Вас должно быть это в /etc/crypttab:

cryptswap1 /dev/sda4 /dev/urandom swap,cipher=aes-cbc-essiv:sha256

и эта строка в конце /etc/fstab

/dev/mapper/cryptswap1 none swap sw 0 0

Удостоверьтесь, что Вы не используете uuid в crypttab файле.

Приостановите проблему:

Теперь давайте использовать прием для нормализации поведения подкачки прямо перед перезагрузкой или завершением работы:

Создайте сценарий /etc/init.d/cryptswap.sh с этой внутренней частью:

#!/bin/bash
/etc/init.d/cryptdisks-early restart

Сделайте это исполняемым файлом с:

sudo chmod +x /etc/init.d/cryptswap.sh

Чтобы сделать вещи правильно, давайте использовать ссылки и числа, чтобы заставить его выполниться в правильный момент при движении или для перезагрузки или для завершения работы:

cd /etc/rc6.d
sudo ln -s ../init.d/cryptswap.sh S10cryptswap.sh
cd /etc/rc0.d
sudo ln -s ../init.d/cryptswap.sh S10cryptswap.sh

Важной вещью здесь является номер 10 на имя, потому что сценарий должен работать перед S40, который начинает удалять подкачку; еще позже другой сценарий удалит шифруемые устройства. Точка является исходными сбоями последовательности, и нам нужен перезапуск, чтобы позволить ей пройти гладко.

Именно!

Примечание: это - грязный взлом, и это может произойти, что перезапуск не может зафиксировать то независимо от того, что продолжается иногда. Кто-то среди разработчиков, отвечающих и за подкачку и за cryptsetup, должен пойти глубоко и видеть, почему после приостановки подкачку оставляют в состоянии, которое делает swapoff /dev/mapper/cryptswap1 и /etc/init.d/cryptdisks-early stop сбой. При выполнении тех команд, Вы будете видеть, что swapoff жалуется на заголовок своп-файла. Кроме того, Вы будете видеть cryptdisks-early отправка "сбоя" при попытке остановиться /dev/mapper/cryptswap1.

Дублирование/история:

Сначала я думал, что его проблема была подключена к поведению ядра libblk, вероятно, ошибка (не предназначенный). Кажется, что проблеме редактировали таблицу разделов различные "файловые системы". Ядро отказывается заполнять /dev/disk/by-uuid/ потому что это обнаруживает несколько подписей файловых систем, редактируя таблицу разделов. Это казалось важным, учитывая, что сценарий /usr/bin/ecryptfs-setup-swap использование UUID к ссылкам это создает для /etc/crypttab.

Фиксация должна быть должна воссоздать все разделы от той же файловой системы путем начальной загрузки на некоторых живых медиа. См.: http://forums.fedoraforum.org/showthread.php?t=288890

Однако это не работает, потому что ecryptfs/crypttab "переформатировал" раздел подкачки на каждой начальной загрузке; Вы не видите uuid для раздела подкачки после выполнения ecryptfs-setup-swap и перезагрузка, потому что Вы, как не предполагается. это означает это после начальной загрузки, привычка раздела быть найденным crypttab, если ссылается uuid, как указано в другом ответе.

При продолжении возможная фиксация должна была бросить использовать uuids и просто заменить их в/etc/crypttab с другой нотацией: только/dev/sdXX работает, потому что другие потеряны, когда mkswap выполняется в crypttab сценариях. Это - способ, которым форумы предлагают решить проблему. Выполнение этого требуется.

Это не работало полностью все же. Я размышлял, что была некоторая ошибка в crypttab (/etc/rcS.d/S26cryptdisks-early -> /etc/init.d/cryptdisks-early -> /lib/cryptsetup/cryptdisks.functions). Таким образом, я пошел, роя там и ничего не нашел. На самом деле, выполнение /etc/init.d/cryptdisks-early restart работы, хорошо когда-то загруженные, /dev/mapper/cryptswap1 ссылка сгенерирована.

Одна возможная фиксация, которую я видел в той точке, должен был переместить подкачку в "файл", который занимает все место в разделе подкачки. Это грязно, требует точки монтирования, и т.д. Идея состоит в том, что Вы создали бы файл размера всего раздела, который будет смонтирован, как регулярный ext4 в говорит что подкачка / и использование зашифрованный файл как подкачка. Что-то вроде этого:

1. В формате GParted как ext4; заметьте, что это отформатирует раздел и генерирует новый UUID; не использовать sudo mkswap /dev/sdXX так как раздел будет автоматическим, смонтировался, если отмечено как подкачка

2. sudo mkdir /swap

3. ls -l /dev/disk/by-uuid/

4. sudo gedit /etc/fstab # добавить UUID=XXXXXXXXXXXXXXXXXXXXXXXXX /swap ext4 defaults 0 2

5. sudo mount /dev/sdXX /swap

6. sudo dd if=/dev/zero of=/swap/swapfile bs=1024 count=800000

7. sudo mkswap /swap/swapfile

8. sudo swapon /swap/swapfile

9. sudo ecryptfs-setup-swap

Но я ненавидел его, таким образом, я не попробовал его.

Другой возможная фиксация, которую я видел, должен был настроить ручной отказ от автоматизированного поколения случайного ключа, как это: http://wiki.drewhess.com/wiki/Creating_an_encrypted_filesystem_on_a_partition#External_links

После исследования немного ручного места проведения, я так или иначе починил вещи путем выполнения что /usr/bin/ecryptfs-setup-swap делает сначала (проверьте его, чтобы видеть, как это работает, это просто редактирует /etc/crypttab и /etc/fstab) и затем вручную запуская скрипт, которые работают на начальной загрузке: /etc/init.d/cryptdisks-early restart; Но это повредилось снова. Заново обдумав о проблеме резюме, я нашел шаблон. Это повреждается на перезагрузке, которая следует за приостановкой и остается поврежденной. Для перефиксации его нужно сделать:

sudo /etc/init.d/cryptdisks-early restart

После этого подкачка смонтирована успешно и без worning, пока Вы не приостанавливаете. Это - то, куда сценарий, предложенный в коротком ответе, прибывает из.

У меня была та же проблема, и я нашел решение, которое работало на меня в этом сообщении.

В основном:

1. Открытый fstab:

   sudo gedit /etc/fstab
   

2. Измените эту строку:

   /dev/mapper/cryptswap1 none swap sw 0 0
   

   к этому:

   /dev/mapper/cryptswap1 none swap sw,noauto 0 0
   

3. Затем перейдите в

   sudo gedit /etc/rc.local
   

   и сразу прежде

   exit 0
   

   добавьте эти две строки:

    sleep 5
    swapon /dev/mapper/cryptswap1
   

Если Вы затем хотите проверить, что Ваша ПОДКАЧКА на самом деле смонтирована и работающий открытый много использующих RAM приложений, и проверьте его через терминальный ввод:

free -m

Просто используйте незашифрованную подкачку

... и сохраните / домой зашифрованным

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

Это говорит нам, что мы на самом деле имеем дело с двойной ошибкой:

1. UUID диска подкачки переопределяется системой шифрования, и
2. Во время начальной загрузки существует проблема тайм-аута.

Эти мысли также отражаются в комментариях к принадлежащей ошибке, зарегистрированной в Launchpad. Однако с незаконченным перемещением от Выскочки к systemd, мало сделано для разрешения ошибки на существующих системах LTS.

На данном этапе следующие мысли пришли в мою голову:

1. Во время установки системы я попросил только шифровать мой \home раздел, ничто иное.
2. Риски, связанные с то, что не зашифровали раздел подкачки, скорее ограничены.
3. Это составило Канонически для взятий за ум. Я не потрачу впустую больше времени с этим.

Так, вот мое решение восстановить подкачку как нормальную, незашифрованную подкачку, не имея необходимость переустанавливать целую операционную систему.

1. Если Вы поэтому уже не сделали, установка blkid: $ sudo apt-get install blkid
2. Править /etc/crypttab и удалите целое cryptswap1 строка: $ sudo nano /etc/crypttab
3. Запустите GParted с меню параметров настройки системы.
4. Вы будете видеть раздел с восклицательным знаком. Это должно быть дефектным разделом подкачки. Тщательно выберите его и переформатируйте его к a linux-swap раздел. Применив эту операцию, Вам сообщают о новом UUID восстановленного нормального раздела подкачки. Вам предлагают возможность сохранить эту информацию. Если Вы не делаете, знаете, что можно всегда получать новый UUID из командной строки с blkid: $ sudo blkid

5. Теперь, пора восстановить /etc/fstab к его старой славе: $ sudo nano /etc/fstab

   • Удалите всю строку, содержащую ссылку на /dev/mapper/cryptswap1.
   • Не прокомментируйте старое swap строка путем удаления хеша # перед UUID=....
   • Теперь, замените старый UUID новым, полученным ранее.
   • Выпишите файл путем удара Ctrl+O и выхода nano с Ctrl+X.
6. После того, как сделанный все это, можно уже начать использовать новую незашифрованную подкачку с: $ sudo swapon -a
7. Это решение переживает обе "горячих" перезагрузки и завершение работы с "холодным" перезапуском.