[過去ログ]
くだらねえ質問はここに書き込め!Part 246 (1002レス)
くだらねえ質問はここに書き込め!Part 246 http://mao.5ch.net/test/read.cgi/linux/1636203420/
上
下
前次
1-
新
通常表示
512バイト分割
レス栞
抽出解除
必死チェッカー(本家)
(べ)
自ID
レス栞
あぼーん
このスレッドは過去ログ倉庫に格納されています。
次スレ検索
歴削→次スレ
栞削→次スレ
過去ログメニュー
469: login:Penguin [sage] 2021/12/17(金) 17:31:22.31 ID:WDpFyAGb 2つHDD接続してます # btrfs filesystem show Label: 'debian' uuid: cf82c300-5af6-45d6-a682-1e93b9105cae Total devices 1 FS bytes used 25.51GiB devid 1 size 295.90GiB used 39.07GiB path /dev/sda2 Label: 'debian' uuid: 3a396f2a-5ad7-47af-9bbd-343195f050f2 Total devices 1 FS bytes used 21.17GiB devid 1 size 146.84GiB used 25.07GiB path /dev/sdb2 以下のごとくsdb2のみ エラーが出て起動できません。直近に当該ディスクドライブが、ゴロンゴロンまともにスピンしませんでした。げんざいは綺麗にスピンしてます。 # dmesg BTRFS errorのみ [ 6576.245236] BTRFS error (device sdb2): parent transid verify failed on 577110016 wanted 1415 found 1373 [ 6576.252368] BTRFS info (device sdb2): no csum found for inode 217067 start 0 [ 6576.264856] BTRFS warning (device sdb2): csum failed root 310 ino 217067 off 0 csum 0xe2d2eae6 expected csum 0x00000000 mirror 1 [ 6576.281548] BTRFS error (device sdb2): parent transid verify failed on 577093632 wanted 1415 found 1373 [ 6584.082394] BTRFS error (device sdb2): parent transid verify failed on 577110016 wanted 1415 found 1373 [ 6584.082408] BTRFS info (device sdb2): no csum found for inode 217067 start 0 [ 6584.095117] BTRFS warning (device sdb2): csum failed root 310 ino 217067 off 0 csum 0xe2d2eae6 expected csum 0x00000000 mirror 1 http://mao.5ch.net/test/read.cgi/linux/1636203420/469
471: login:Penguin [sage] 2021/12/17(金) 18:00:28.63 ID:WDpFyAGb 見やすくするために [ 6584.082394] BTRFS error (device sdb2): 等の文字列をのぞいきました parent transid verify failed on 577110016 wanted 1415 found 1373 no csum found for inode 217067 start 0 csum failed root 310 ino 217067 off 0 csum 0xe2d2eae6 expected csum 0x00000000 mirror 1 parent transid verify failed on 577093632 wanted 1415 found 1373 parent transid verify failed on 577110016 wanted 1415 found 1373 no csum found for inode 217067 start 0 csum failed root 310 ino 217067 off 0 csum 0xe2d2eae6 expected csum 0x00000000 mirror 1 http://mao.5ch.net/test/read.cgi/linux/1636203420/471
472: login:Penguin [sage] 2021/12/17(金) 18:03:35.77 ID:WDpFyAGb なおすでに # btrfs rescue zero-log /dev/sdb2 を実行。 参考 https://github.com/satoru-takeuchi/btrfs-thin-book/blob/master/trouble_shooting.md これをする前はマウントすらできませんでした。 http://mao.5ch.net/test/read.cgi/linux/1636203420/472
473: login:Penguin [sage] 2021/12/17(金) 18:07:26.49 ID:WDpFyAGb > "chunk tree"という文字列を含むメッセージが出力されている。 どのデバイスにどのデータを配置するかという情報が入っているchunk treeというメタデータが壊れている可能性があります。次のコマンドによって、ファイルシステムをスキャンしてchunk treeを復元できます。 # btrfs rescue chunk-recover /dev/sdb2 "chunk tree"という文字列を含むメッセージが出力されてませんが、実行。 # btrfs rescue chunk-recover /dev/sdb2 ERROR: the device is busy http://mao.5ch.net/test/read.cgi/linux/1636203420/473
474: login:Penguin [sage] 2021/12/17(金) 18:17:43.77 ID:WDpFyAGb 大段 ■mountできなくなった <<(我)もうすでにマウントはできてるのですが... 中の □mountに必要なメタデータの復元 これ以降の操作はmountできなくなったBtrfsファイルシステムを構成するストレージの内容を変更します 中の ----------------------------------------- それ以外のメッセージが出ている、あるいはとくにメッセージが残っていない 大きく分けて次の2つの可能性が考えられます。 スーパーブロック(後述)が壊れている root tree(後述)が壊れている ----------------------------------------- 第一にスーパーブロックが壊れている場合です。スーパーブロックとは、mountしようとしたストレージがBtrfsに属していることを示すと共に、各種管理情報を保持しているメタデータです。このデータにはバックアップされていますので、スーパーブロックが壊れている場合は次のコマンドによって復元できます。 # btrfs rescue super-recover /dev/sdb2 ERROR: the device is busy http://mao.5ch.net/test/read.cgi/linux/1636203420/474
475: login:Penguin [sage] 2021/12/17(金) 18:23:19.92 ID:WDpFyAGb 第二にroot treeが壊れている場合です。root treeとは、どの場所にどんなデータ/メタデータが配置されているかを管理するメタデータです。壊れたroot treeを復元するには次のようにします。 # mount -o usebackuproot /dev/sdb2 /mnt << 行末はマウントポイントを指定ということか? $ lsblk sdb 8:16 0 149.1G 0 disk ├─sdb1 8:17 0 260M 0 part ├─sdb2 8:18 0 146.9G 0 part /media/jin/debian └─sdb3 8:19 0 2G 0 part # mount -o usebackuproot /dev/sdb2 /media/jin/debian # mount -o usebackuproot /dev/sdb2 /media/jin/debian mount: /media/jin/debian: wrong fs type, bad option, bad superblock on /dev/sdb2, missing codepage or helper program, or other error. # んんん〜? http://mao.5ch.net/test/read.cgi/linux/1636203420/475
476: login:Penguin [sage] 2021/12/17(金) 18:31:24.82 ID:WDpFyAGb ファイルシステムの復元(最終手段) # btrfs check --repair /dev/sdb2 このコマンドは矛盾のあるデータは容赦無く削除するなどして無理矢理にでもmountできるようにするためのものであり、かつ、必ずしも成功するとは限りません。このため、他に打つ手がまったく無くなったときの最後の手段として使用してください # btrfs check --repair /dev/sdb2 enabling repair mode WARNING: Do not use --repair unless you are advised to do so by a developer or an experienced user, and then only after having accepted that no fsck can successfully repair all types of filesystem corruption. Eg. some software or hardware bugs can fatally damage a volume. The operation will start in 10 seconds. Use Ctrl-C to stop it. 10 9 8 7 6 5 4 3 2 1 Starting repair. Opening filesystem to check... ERROR: /dev/sdb2 is currently mounted, use --force if you really intend to check the filesystem # << マウントしてない状態でやるのか http://mao.5ch.net/test/read.cgi/linux/1636203420/476
477: login:Penguin [sage] 2021/12/17(金) 18:31:28.34 ID:WDpFyAGb # btrfs check --repair /dev/sdb2 enabling repair mode WARNING: Do not use --repair unless you are advised to do so by a developer or an experienced user, and then only after having accepted that no fsck can successfully repair all types of filesystem corruption. Eg. some software or hardware bugs can fatally damage a volume. The operation will start in 10 seconds. Use Ctrl-C to stop it. 10 9 8 7 6 5 4 3 2 1 Starting repair. Opening filesystem to check... Checking filesystem on /dev/sdb2 UUID: 3a396f2a-5ad7-47af-9bbd-343195f050f2 [1/7] checking root items parent transid verify failed on 579682304 wanted 1415 found 1372 parent transid verify failed on 579682304 wanted 1415 found 1372 parent transid verify failed on 579682304 wanted 1415 found 1372 Ignoring transid failure ERROR: child eb corrupted: parent bytenr=578355200 item=136 parent level=1 child bytenr=579682304 child level=1 ERROR: failed to repair root items: Input/output error # http://mao.5ch.net/test/read.cgi/linux/1636203420/477
478: login:Penguin [sage] 2021/12/17(金) 18:36:00.69 ID:WDpFyAGb 警告 開発者からアドバイスがない限り、--repair は使用しないでください。 ということを理解した上で、そのうえで行ってください。 fsck はあらゆる種類のファイルシステムの破損を正常に修復することができます。例えば いくつかのソフトウェアやハードウェアのバグは、ボリュームに致命的な損傷を与える可能性があります。 [1/7] ルートアイテムのチェック parent transid verify failed on 579682304 wanted 1415 found 1372 parent transid verify failed on 579682304 wanted 1415 found 1372 parent transid verify failed on 579682304 wanted 1415 found 1372 トランシッドの失敗を無視する ERROR: 子ebが破損: 親 bytenr=578355200 item=136 親レベル=1 子 bytenr=579682304 子レベル=1 ERROR: ルートアイテムの修復に失敗しました。入出力エラー # <<以上機械翻訳 # btrfs rescue super-recover /dev/sdb2 ERROR: the device is busy <<先に実行したコマンドでこの意味がわからなかったが、 << マウントしてない状態でやるのか ということでは? もう一度やり直し http://mao.5ch.net/test/read.cgi/linux/1636203420/478
480: login:Penguin [sage] 2021/12/17(金) 21:38:04.36 ID:WDpFyAGb "chunk tree"という文字列を含むメッセージが出力されている。 どのデバイスにどのデータを配置するかという情報が入っているchunk treeというメタデータが壊れている可能性があります。次のコマンドによって、ファイルシステムをスキャンしてchunk treeを復元できます。 # btrfs rescue chunk-recover /dev/sdb2 このコマンドはストレージプールのすべてを走査するため、非常に時間がかかる恐れがあります。 ---------------- # btrfs rescue chunk-recover /dev/sdb2 Scanning: 104862273536 in dev0 すごい長い時間かかてる、、、 http://mao.5ch.net/test/read.cgi/linux/1636203420/480
482: login:Penguin [sage] 2021/12/17(金) 22:00:46.28 ID:WDpFyAGb # btrfs rescue chunk-recover /dev/sdb2 Scanning: DONE in dev0 We are going to rebuild the chunk tree on disk, it might destroy the old metadata on the disk, Are you sure? [y/N]: y Chunk tree recovery aborted # おわた dmesg どうなった? # dmesg | tail [11570.040916] usb 6-3: Product: WN-G300UA [11570.040920] usb 6-3: Manufacturer: I-O DATA DEVICE, INC. [11570.040923] usb 6-3: SerialNumber: 00e04c000001 [11570.857132] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [11570.884652] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [11571.107981] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [11571.163660] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [11572.726292] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [14120.958897] sysctl (11524): drop_caches: 3 [14143.358555] Adding 2097148k swap on /dev/sda3. Priority:-2 extents:1 across:2097148k FS # 消えた、btrfs 関連エラー?? ひとつだけになった? [10621.063512] BTRFS error (device sdb2): Remounting read-write after error is not allowed http://mao.5ch.net/test/read.cgi/linux/1636203420/482
483: login:Penguin [sage] 2021/12/17(金) 22:18:17.99 ID:WDpFyAGb だめだなー。起動できない。initramfs みたいな さっきの日本語参考ページの元ネタってぽい英語ページにしたがってやってゆこうか https://ownyourbits.com/2019/03/03/how-to-recover-a-btrfs-partition/ >Be prepared 準備して Rule zero is of course to have backups. もちろん、ルールゼロはバックアップをとることです。 This will allow us to sleep well at night and handle a bad drive situation with a much cooler head. これにより、私たちは夜よく眠り、はるかに涼しい頭で悪いドライブ状況に対処することができます。 I can’t stress this enough: have at least three copies in two different locations. これを十分に強調することはできません。2つの異なる場所に少なくとも3つのコピーがあります。 Everything will be easier and less stressful when a drive fails, which will happen. ドライブに障害が発生した場合、すべてが簡単になり、ストレスが軽減されます。 << sdb の中にあるスナップショットはバックアップになんないのか? また、このsda中のスナップショットでは、ファイルシステムを復元できないのか1 http://mao.5ch.net/test/read.cgi/linux/1636203420/483
484: login:Penguin [sage] 2021/12/17(金) 22:19:55.07 ID:WDpFyAGb Then, rule number one is to monitor your hard drive’s health. 次に、ルール1は、ハードドライブの状態を監視することです。 This is also critical because normally you will get the warning at least 24 or 48 hours before total failure so you have a good chance of getting your data out of there before it is too late. 通常、完全な障害が発生する少なくとも24時間または48時間前に警告が表示されるため、手遅れになる前にデータを取得できる可能性が高いため、これも重要です。 Hard drives don’t completely fail from one day to the other but we need to pay attention to them. ハードドライブは、ある日から別の日に完全に故障するわけではありません -------------------- とりあえずスマート有効にして、値を見てみるところからはじめる http://mao.5ch.net/test/read.cgi/linux/1636203420/484
485: login:Penguin [sage] 2021/12/17(金) 22:28:05.94 ID:WDpFyAGb 問題ディスク ST3160815AS (3.AAC) であるが、 890 個の不良セクターがありますが、使用可能です (35 °C / 95 °F) <<以前と同じメッセージ リアロケーティッドセクタカウント カレントペンディングセクタカウント アンコレクタブルセクタカウント 等の重要な値も以前といっしょ エアフロー温度だけ 赤字で「過去に失敗した」と出ている http://mao.5ch.net/test/read.cgi/linux/1636203420/485
486: login:Penguin [sage] 2021/12/17(金) 22:47:38.76 ID:WDpFyAGb これらの参考ページはすべて Procedure if the drive can be mounted ドライブをマウントできるかどうかの手順 であって、俺の環境はすでにマウントできてる だからぜんぜん別の修復方法がありそうなものだ > 復元したい日付のディレクトリへ入り、 $ cd /media/ユーザ/debian/timeshift-btrfs/snapshots/2021-12-13_16-08-21 これじゃダメなのか?(じつはもうやった、リードオンリーと出てできない) http://mao.5ch.net/test/read.cgi/linux/1636203420/486
メモ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
スレ情報
赤レス抽出
画像レス抽出
歴の未読スレ
AAサムネイル
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.029s