12.04のインストールは失敗し続け、解決策は、以前に/ homeで使用していたbtrfsパーティションをインストーラーに無視させることでした。
インストールが完了したので、70GBのファイルにアクセスできるように、btrfsパーティションをマウントするように試みました。マウントされず、次の3行でbtrfsckエラーが発生します。
parent transid verify failed on 31302336512 wanted 62455 found 62456
parent transid verify failed on 31302336512 wanted 62455 found 62456
parent transid verify failed on 31302336512 wanted 62455 found 62456
誰かがこのパーティションを機能させる方法を教えてもらえますか？私はオンラインで、おそらくbtrfs-restoreを使用してデータを回復できることを読みましたが、そのプログラムはどこにも見つかりません。
回答:
最も簡単な方法
btrfs-zero-log /dev/sda5
トランザクション（書き込みまたは削除）がジャーナルログに残っており、ディスクがそれに一致しないため、その問題が発生します。
使い方：
そのため、データが最初にジャーナルに書き込まれ、次にディスクに書き込まれたとき（または同時に、ジャーナルは今後の書き込みに関するメタデータを保存するだけです。
とにかく、この書き込み/削除の途中でシステムの電源を切るか、システムを接続する（btrfsマウントポイントを保持しているUSBを取り外す）と、戻るとマウントが機能しなくなります（dmesgとbtrfsckはエラーの詳細を表示します）...
dmesgを見ると、これらの同じtransidメッセージが表示されます。
次のようなものが表示されます。
parent transid verify failed on 109973766144 wanted 1823 found 1821
これは、btrfsがtransif 1826（ジャーナル上にあった）を望んでいたことを意味しますが、ディスク上には1821がありました。したがって、ディスクはジャーナルと同期していない2トランザクションでした。私は個人的にここでbrtfs-zero-logを危険にさらすのは、たった2つのトランザクションがあるからです。ただし、これが唯一のデータである場合は100％安全です（重要なデータがある場合は、コピーを1つだけにして、他の安全な場所に常にコピー/バックアップを作成します-btrfsの作成者を非難しますバックアップを持っていないという責任の欠如を正当化する-btrfsはバックアップソリューションではなく、ファイルシステムです-コピーや他の場所を持っている以外に真のバックアップソリューションはありません-パリティドライブやミラードライブさえも、真のバックアップはありませんアクティブコピーがテキサスのオフィスにある間、アルプスの地下のどこかに座っている）
parent transid verify failed on 31302336512 wanted 62455 found 62456
ここでは、ジャーナルは62455を必要としていますが、ディスクは62456で1つ先にあるため、あなたの場合、ジャーナルをクリアするだけです。ジャーナルは今回は更新しませんでした。繰り返しますが、あなたのデータがあなたの唯一のデータであり、非常に重要な場合（あなたに恥をかかせる場合）、安全なものであることを伝えました。
btrfsck / dev / sda5（ちなみに読み取り専用チェックを行うため、完全に安全で、心配する必要がある唯一のbtrfsckオプション）を実行すると、これらのメッセージも表示されます。
ただし、そのデータが重要な場合は、最初に行うことに注意してください（他の男性が言ったように）
mount -t btrfs -o rootflags=recovery,nospace_cache /dev/sda3 /mnt/sda3
mount -t btrfs -o rootflags=recovery,nospace_cache,clear_cache /dev/sda3 /mnt/sda3
mount -t btrfs -o recovery,nospace_cache,nospace_cache /dev/sda3 /mnt/sda3
次に、すべてのファイルを安全な場所にcpまたはrsyncし、安全なときにbtrfs-zero-logを実行します。操作が成功した場合は、システムのバックアップに多くの時間を無駄にしました（ただし、成功しなかった場合は、 arse）
その後、マウントが失敗した場合、btrfs restoreを実行します（システムのダンプ、再開可能な操作を理解しているため、Yまたはyを時々要求するため、出力を確認してください）
btrfs restore /dev/sda5 /USB
その後、安全なとき（btrfs復元が完了したとき）、btrfs-zero-logを実行します。操作が成功した場合は、システムのバックアップにかなりの時間を無駄にしました（しかし、成功しなかった場合は、arseを保存しました）
最初に画面を実行できます
screen /bin/bash
btrfs restore /dev/sda5 /USB
スクリーンサイドノート
デタッチするには（コマンドは引き続き実行されます）：CONTROL-a次に引用符なしで「：detach」と入力し、Enterキーを押します
別のデタッチ方法：次に、パテまたはターミナルを閉じてデタッチします（コマンド/復元は引き続き実行されます）。
確認するには、スクリーンバックしてください：
screen -x
screen -xは、切り離されていてもセッションにアタッチします。-hとは異なり、すでにアタッチされていてもアタッチされます）
複数の画面がある場合、画面-xは、セッションにアタッチするためにより具体的にする必要があることを示します。
screen -ls
すべてのセッションをリストするためのls、覚えやすい。
PIDを表示するには、次の操作もできます。
ps aux | grep screen
PIDを確認したら、次のような画面を実行します。
screen -x PID
特定のセッションにアタッチされます。同じ画面に複数のセッション/パテをアタッチできます（同じテキストを出力し、1つにコマンドを入力でき、他のパテにミラーリングされます）
ルートfsマウントオプションを使用してブート時にマウントします。
rootflags=recovery,nospace_cache
または
rootflags=recovery,nospace_cache,clear_cache
btrfsマウントオプションの完全なリストは、https： //btrfs.wiki.kernel.org/index.php/Mount_optionsにあります。noatime、nodatacowなど、他のものも役立つかもしれません（カーネルバグを修正してくれました）私のファイルをコピーする機会）。
grub.cfg / menu.lstに追加するか、起動時に入力します。
nospace_cacheスタッフは物事をものすごく遅くします。ただ起動し、（長く）待機し、シャットダウンして、通常どおり起動します。
数日前に同じことがありましたが、上記で修正しました。しかし、その後、いくつかのスペースの問題もありました...報告されたスペースは100％ではありませんが、それでもスペース不足と言うことができます。
==
たとえば、fstabに同じオプションを追加することもできます。
UUID=0237alksfadg-lhdfkj3624-4fdfjb-9dsfe2d-dfddaf /home btrfs defaults,recovery,nospace_cache,clear_cache,subvol=@home 0
2
でパーティション上にマウントされた/ homeディレクトリを回復しようとしていた場合UUID=0237alksfadg-lhdfkj3624-4fdfjb-9dsfe2d-dfddaf。
ピーターの答えは、Ubuntuではないが、私にとって問題を解決した。/homeもちろん、破損したパーティションbtrfs'dがありました。オンになっているため、システムは起動しませんfstab。メンテナンスモードに入り、そのパーティションの行をハッシュし、正常に起動しました（使用できる予備のext4パーティションがありました/home）。
次のコマンドでパーティションを手動でマウントしました：
mount -t btrfs -o recovery,nospace_cache,nospace_cache /dev/sda3 /mnt/sda3実際にデータを保存できました。マウントするのにそれほど時間はかかりませんでしたが。ピーターに感謝します。
同じ問題がありました。再起動後、btrfsパーティションをマウントできなくなりました。ただし、ここで説明した解決策では解決できませんでした。
修正したのは、カーネルを3.10から3.12にアップグレードしたことです。再起動後、btrfsパーティションを再度マウントできます。
nospace_cache？