web-dev-qa-db-ja.com

スワップパーティションが認識されません（UUID = ...のディスクドライブはまだ準備ができていないか、存在しません）

  • インストール中にホームディレクトリを暗号化することを選択したため、暗号化されたスワップパーティションがあったと思います。 /dev/mapper/cryptswap1 ...にある/etc/fstabの行がそれだと思います。

  • 次のブート時にメッセージを受け取ったので、私はスワップを混乱させるために何かをしました（言い換え）：

    / dev/mapper/cryptswap1のディスクドライブはまだ準備ができていないか、存在しません。続行するのを待ちます。 Sを押してスキップするか、Mを押して手動で回復します。

    （補足として、 S または M 待っているだけと何も変わらないように見えた。）

  • 私が試したものは次のとおりです。

    1. このチュートリアル マウントされていないスワップパーティションを修正する方法について。ただし、上記では、デバイスがビジーであるため、mkswapコマンドは失敗します。
    2. そこで、ライブUSBから起動し、GPartedを実行してスワップパーティション（未知のfsタイプとして表示される）を再フォーマットし、壊れたシステムにchrootしてそのチュートリアルを再試行しました。また、パーティションをスワップとしてフォーマットすることで生成された新しいUUIDを反映するように/etc/initramfs-tools/conf.d/resumeと/etc/fstabを調整しました。それでもうまくいきませんでした。 /dev/mapper/cryptswap1が存在しない代わりに、「UUID =[スワップパーティションのUUID]のディスクドライブはまだ準備ができていないか、存在しません...」
    3. だから、最初からスワップパーティションを作成したことがないかのように、新たに始めることにしました。 Live USBから、スワップパーティションを完全に削除し（これも不明なfsタイプとしてGPartedに表示されます）、/etc/fstabのスワップエントリとcryptswapエントリを削除し、/etc/initramfs-tools/conf.d/resumeと/etc/crypttabを削除しました。この時点では、スワップパーティションやマウントするための指示がないため、メインシステムが壊れているとは見なされません。起動時にエラーは発生しませんでした。スワップ用のパーティションの作成から始めて、同じ手順に従ってスワップパーティションを作成および暗号化しましたが、fdiskは変更を確認するには再起動が必要だと思います。

  • 上記の3番目のプロセスは機能すると確信していましたが、問題は解決しません。

  • 関連情報（/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

それで、これはどのように修正できますか？

12.04bootencryptionswap
6
ladaghini

暗号化されたスワップパーティションを使用する場合、同じ問題が発生しました。一般的な Swap FAQ 、 「cryptswap1がまだ準備できていない、または存在しない」メッセージに対するPuny Geekのソリューション または Braiamの答え to この質問 私のために問題を解決しました-時々スワップが利用可能でした、時々利用できませんでした。多くの再起動といくつかの突進の後、私は根本的な理由を見つけたと思います：

/dev/sda3のようなスワップパーティションへのパスは異なる場合があります。 /dev/sdb3。ファイル/etc/crypttabはデフォルトでこのパスを介してスワップパーティションを識別するように見えるため、（ブート時にそのパーティションが偶然同じパスを取得する場合）見つからない場合があります（パーティションに異なるパスが割り当てられている場合）ブート）。

私がその問題を抱えているのは私だけではなかったようです ここで説明しているため 、より良い解決策は、/dev/sd*パスではなくドライブIDを介してスワップパーティションをバインドすることです。これは次を実行することで見つけることができます

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

これは、スワップを含むすべてのパーティションのディスクIDをリストします。これは、私の場合は

ata-Toshiba_MQ01UBD100_73JATD5GT-part3 -> ../../sdb3

ディスクユーティリティなどのプログラムで、この行の-> ../../sdb*部分が実際にスワッピングに使用する予定のパーティションであることを再確認します。これは（前に言ったように）名前を変更することがあるためです。いつものように、これに留意してください：

注意：cryptsetupとディスクデバイスをいじるのは、データとOSにとって危険です。個人的に完全なバックアップを別のディスクに作成し、それをアンプラグして、事故に巻き込まれないようにしました。

次に、「生」パスの代わりにIDリンクを使用して/etc/crypttabファイルを編集します。私の場合、この行は

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

明らかに/dev/sd*パスがわからないため、この方法は新規インストールのデフォルトにすべきだと思います...スクリプトやソフトウェアがもっとたくさんあると感じているので、少し心配しています。これらのパス（ID、ラベル、またはUUIDではなく）に依存して、再起動後も同じままになります。

TODO：

このページで述べられているように、これはUUID（私のスワップパーティションにはない）に依存しているように見えるため、休止状態からの再開がこのセットアップでまだ機能するかどうかは確認していません： https：// altinukshini .wordpress.com/2012/10/15/devmappercryptswap1-is-not-ready-yet-or-not-present /

更新：

これまでのところ、休止状態は正常に機能しているようです。これが他の人にとってもこれらの問題を解決することを願っています！

2
FriendFX

簡潔な答え：

UUIDの問題：

/etc/crypttabにこれがあるはずです：

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

/etc/fstabの最後のこの行

/dev/mapper/cryptswap1 none swap sw 0 0

Crypttabファイルでuuidを使用しないでください。

問題の一時停止：

次に、トリックを使用して、再起動またはシャットダウンする直前にスワップの動作を正規化します。

この中に/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がswapfileのヘッダーについて文句を言うのがわかります。また、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=28889

ただし、ecryptfs/crypttabはブートのたびにスワップパーティションを「再フォーマット」するため、これは機能しません。 ecryptfs-setup-swapを実行して再起動すると、スワップパーティションのuuidが表示されなくなります。これは、他の回答に記載されているように、起動時にuuidによって参照されている場合、crypttabによってパーティションが検出されないことを意味します。

さらに、可能性のある修正は、uuidの使用をあきらめて、/ 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リンクが生成されると正常に動作します。

その時点で私が見た可能性のある修正の1つは、スワップパーティション内のすべてのスペースを使用する「ファイル」にスワップを移動することでした。これは汚れており、マウントポイントなどが必要です。アイデアは、パーティション全体のサイズのファイルを作成し、通常のext4として/ swapにマウントし、暗号化されたファイルをスワップとして使用するというものです。このようなもの：

  1. Ext4としてのGParted形式。これによりパーティションがフォーマットされ、新しい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

その後、一時停止しない限り、スワップは正常にマウントされ、摩耗することはありません。これが、短い答えで提案されたスクリプトの出所です。

1
nixahn

私は同じ問題を抱えていたので、 この投稿 でうまくいく解決策を見つけました。

基本的に：

  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

    次の2行を追加します。

     sleep 5
 swapon /dev/mapper/cryptswap1

その後、SWAPが実際にマウントされており、多くのRAMを消費するアプリケーションを開いて動作していることを確認したい場合は、端末の入力により確認します。

free -m
1
VanPiro

暗号化されていないスワップを使用するだけです

...および/ homeを暗号化した状態に保つ

ここで提案されている他のソリューションをいくつか試しました。ホットリブート後も機能し続けていましたが、シャットダウンとコールドリスタート後は最終的にすべて失敗しました。

これは、実際に二重のバグに対処していることを示しています。

  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について通知されます。この情報を保存する機会が提供されます。そうでない場合は、blkid：$ Sudo blkidを使用して、コマンドラインからいつでも新しいUUIDを取得できることを知ってください。

  5. これで、/etc/fstabを以前の栄光に戻す時が来ました：$ Sudo nano /etc/fstab

    • /dev/mapper/cryptswap1への参照を含む行全体を削除します。
    • #の前にあるハッシュUUID=...を削除して、古いswap行のコメントを解除します。
    • 次に、古いUUIDを以前に取得した新しいUUIDに置き換えます。
    • ヒットしてファイルを書き出す Ctrl+O そしてnanoを終了します Ctrl+X。
  6. すべて完了したら、$ Sudo swapon -aで新しい暗号化されていないスワップの使用を開始できます。
  7. このソリューションは、ホットリブートとコールドリスタートによるシャットダウンの両方に耐えます。
1
Serge Stroobandt