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

  • Я думаю, что у меня был зашифрованный раздел подкачки, потому что я решил зашифровать мой домашний каталог во время установки. Я полагаю, что это то, что линия с /dev/mapper/cryptswap1 ... в моем /etc/fstab это все о.

  • Я сделал что-то, чтобы поменять своп, потому что при следующей загрузке я получил сообщение (перефразировано):

    Дисковод для /dev/mapper/cryptswap1 еще не готов или отсутствует. Подождите, чтобы продолжить. Нажмите S, чтобы пропустить, или M, чтобы восстановить вручную.

    (Как примечание стороны, нажатие S или M, казалось, не сделало ничего, отличного от просто ожидания.)

  • Вот что я попробовал:

    1. Это руководство о том, как исправить раздел подкачки, не монтирующий. Однако в приведенном выше mkswap Сбой команды, потому что устройство занято.
    2. Поэтому я загрузился с живого USB, запустил GParted, чтобы переформатировать раздел подкачки (который обнаружился как неизвестный тип fs), и подключился к сломанной системе, чтобы снова попробовать это руководство. Я тоже поправил /etc/initramfs-tools/conf.d/resume а также /etc/fstab чтобы отразить новый UUID, сгенерированный при форматировании раздела как подкачки. Это все еще не сработало; вместо /dev/mapper/cryptswap1 отсутствует "Диск с UUID = [ UUID раздела подкачки] еще не готов или отсутствует..."
    3. Поэтому я решил начать заново, как будто я никогда не создавал раздел подкачки. С Live USB я полностью удалил раздел подкачки (который снова отображается в GParted как неизвестный тип fs), удалил записи подкачки и cryptswap в /etc/fstab а также удалены /etc/initramfs-tools/conf.d/resume а также /etc/crypttab, На этом этапе основную систему не следует считать сломанной, поскольку нет раздела подкачки и нет инструкций по его монтированию, верно? Я не получил никаких ошибок при запуске. Я следовал тем же инструкциям по созданию и шифрованию раздела подкачки, начиная с создания раздела подкачки, хотя я думаю, fdisk сказал, что перезагрузка была необходима, чтобы увидеть изменения.

  • Я был уверен, что третий процесс, описанный выше, сработает, но проблема все еще сохраняется.

  • Некоторая актуальная информация (/dev/sda8 это раздел подкачки):

    • /etc/fstab файл:

      # /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    nodev,noexec,nosuid 0       0
# / was on /dev/sda6 during installation
UUID=4c11e82c-5fe9-49d5-92d9-cdaa6865c991 /               ext4    errors=remount-ro 0       1
# /boot was on /dev/sda5 during installation
UUID=4031413e-e89f-49a9-b54c-e887286bb15e /boot           ext4    defaults        0       2
# /home was on /dev/sda7 during installation
UUID=d5bbfc6f-482a-464e-9f26-fd213230ae84 /home           ext4    defaults        0       2
# swap was on /dev/sda8 during installation
UUID=5da2c720-8787-4332-9317-7d96cf1e9b80 none            swap    sw              0       0
/dev/mapper/cryptswap1 none swap sw 0 0

    • вывод sudo mount:

      /dev/sda6 on / type ext4 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
/dev/sda5 on /boot type ext4 (rw)
/dev/sda7 on /home type ext4 (rw)
/home/undisclosed/.Private on /home/undisclosed type ecryptfs (ecryptfs_check_dev_ruid,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs,ecryptfs_sig=cbae1771abd34009,ecryptfs_fnek_sig=7cefe2f59aab8e58)
gvfs-fuse-daemon on /home/undisclosed/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=undisclosed)

    • вывод sudo blkid (Обратите внимание, что /dev/sda8 пропал, отсутствует):

      /dev/sda1: LABEL="SYSTEM" UUID="960490E80490CC9D" TYPE="ntfs" 
/dev/sda2: UUID="D4043140043126C0" TYPE="ntfs" 
/dev/sda3: LABEL="Shared" UUID="80F613E1F613D5EE" TYPE="ntfs" 
/dev/sda5: UUID="4031413e-e89f-49a9-b54c-e887286bb15e" TYPE="ext4" 
/dev/sda6: UUID="4c11e82c-5fe9-49d5-92d9-cdaa6865c991" TYPE="ext4" 
/dev/sda7: UUID="d5bbfc6f-482a-464e-9f26-fd213230ae84" TYPE="ext4" 
/dev/mapper/cryptswap1: UUID="41fa147a-3e2c-4e61-b29b-3f240fffbba0" TYPE="swap"

    • вывод sudo fdisk -l:

      Disk /dev/mapper/cryptswap1 doesn't contain a valid partition table

Disk /dev/sda: 320.1 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders, total 625142448 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xdec3fed2

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048      409599      203776    7  HPFS/NTFS/exFAT
/dev/sda2          409600   210135039   104862720    7  HPFS/NTFS/exFAT
/dev/sda3       210135040   415422463   102643712    7  HPFS/NTFS/exFAT
/dev/sda4       415424510   625141759   104858625    5  Extended
/dev/sda5       415424512   415922175      248832   83  Linux
/dev/sda6       415924224   515921919    49998848   83  Linux
/dev/sda7       515923968   621389823    52732928   83  Linux
/dev/sda8       621391872   625141759     1874944   82  Linux swap / Solaris

Disk /dev/mapper/cryptswap1: 1919 MB, 1919942656 bytes
255 heads, 63 sectors/track, 233 cylinders, total 3749888 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xaf5321b5

    • /etc/initramfs-tools/conf.d/resume файл:

      RESUME=UUID=5da2c720-8787-4332-9317-7d96cf1e9b80

    • /etc/crypttab файл:

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

    • вывод sudo swapon -as:

      Filename                Type        Size    Used    Priority
/dev/mapper/cryptswap1                  partition   1874940 0   -1

    • вывод sudo free -m:

                   total       used       free     shared    buffers     cached
Mem:          1476       1296        179          0         35        671
-/+ buffers/cache:        590        886
Swap:         1830          0       1830

Итак, как это можно исправить?

Источник

4 ответа

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

Путь к разделу подкачки вроде /dev/sda3 иногда отличается, например /dev/sdb3, Поскольку файл /etc/crypttab по умолчанию, кажется, идентифицирует раздел подкачки по этому пути, иногда он найдет его (если этот раздел получит тот же путь при загрузке) или нет (если раздел получит другой путь, назначенный при загрузке).

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

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

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

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

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

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

Затем отредактируйте свой /etc/crypttab файл с помощью ссылки на идентификатор вместо "сырого" пути, в моем случае эта строка

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

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

СДЕЛАТЬ:

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

Обновить:

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

Источник

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

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, который начинает снимать своп; даже позже другой сценарий снимет зашифрованные устройства. Дело в том, что исходная последовательность не работает, и нам нужен перезапуск, чтобы она прошла гладко.

Это оно!

Примечание: это грязный хак, и может случиться так, что перезапуск не может исправить то, что происходит иногда. Кто-то из разработчиков, отвечающих за swap и / или cryptsetup, должен углубиться и понять, почему после приостановки swap остается в состоянии, которое делает 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 в скажем / swap, и использовать зашифрованный файл как swap. Что-то вроде этого:

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

  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

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

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

После этого своп смонтирован успешно и без проблем до тех пор, пока вы не приостановите. Отсюда и сценарий, предложенный в кратком ответе.

Источник

Просто используйте незашифрованный своп

... и держать / дома в зашифрованном виде

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

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

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

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

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

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

Итак, вот мое решение восстановить подкачку как обычный незашифрованный подкачку без переустановки всей операционной системы.

  1. Если вы еще этого не сделали, установите blkid: $ sudo apt-get install blkid
  2. редактировать /etc/crypttab и удалить весь cryptswap1 линия: $ sudo nano /etc/crypttab
  3. Запустите GParted из меню системных настроек.
  4. Вы увидите раздел с восклицательным знаком. Это должен быть неисправный раздел подкачки. Тщательно выберите его и переформатируйте в 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. Это решение выдерживает как горячие перезагрузки, так и выключение при холодном перезапуске.
Источник

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

В принципе:

  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

Если вы хотите проверить, что ваш SWAP действительно подключен и работает, откройте много приложений, потребляющих ОЗУ, и проверьте его с помощью терминала:

free -m
Источник
Другие вопросы по тегам