Grub Stage1はどのようにして正確にステージ2にアクセス/ロードしますか？

Question

これは私の初めての質問です。この質問をRed Hatのインストラクターの前に出しましたが、満足のいく答えは見つかりませんでした。

私はRHEL/CENTOS6、GRUBLegacy 0.97を使用しており、Linuxブートプロセスを説明する大量のドキュメントを参照しています。

ほぼすべてのブログ、ドキュメントなどで、関連する手順とプロセス全体がうまく説明されていますが、grubステージ2をロードするときに実際に何が行われるかについて、全会一致で失敗しています。

これが私のプロセスの理解であり、少しテストも行っています。

BIOS（EFIを使用しない）はMBRを読み取り、パーティションテーブルを見つけ、GRUBステージ1（最初の446バイト）をメモリにロードします
私は1024シリンダー以下の/ bootパーティションを持っていて、一連のドキュメントから抽出したアイデアは、GRUB1024シリンダー以下のどこかにある場合、stage1が直接stage2をロードできるということです。私が参照したいくつかのドキュメントは、stage1.5がセクター63の前のMBRのすぐ後にあると述べていますが、他のグループは、最初の1MBのディスクのどこにでもある可能性があることを示唆しています。さらに別のグループは、stage1.5は単なるGRUBv2のもので、GRUBlegacyには適用されません。
GRUBステージ2には、ファイルシステムを読み取るために必要なすべてのドライバー/モジュールがあり、カーネルとRAMディスクをロードし、カーネルにハンドオーバー制御を行います。
カーネルはRHEL/CENTOS 6ではinitを開始し、RHEL/CENTOS 7ではsystemdを開始します。

ディスクの最初のMBからすべてのデータをダンプしました。MBR以外に何もないことを確認できます。どのように446バイトGRUBstage1がファイルシステムからstage2をロードできるかについて混乱しますか？ウィキペディアのいくつかの画像といくつかのドキュメントによると、GRUBがインストールされている場合、stage1には、stage2を指すLBA48が含まれています。

実際に試して、stage2が/ boot/grub /ディレクトリから削除または名前変更されたときにシステムが起動するかどうかをテストしてみました。ファイルシステムにステージ2がない場合でも、システムは起動可能でした。

/ dev/sdaからの最初のMB

[root@chief zul.kifal]# dd if=/dev/sda bs=1024k count=1 | hexdump -C 00000000 eb 48 90 10 8e d0 bc 00 b0 b8 00 00 8e d8 8e c0 |.H..............| 00000010 fb be 00 7c bf 00 06 b9 00 02 f3 a4 ea 21 06 00 |...|.........!..| 00000020 00 be be 07 38 04 75 0b 83 c6 10 81 fe fe 07 75 |....8.u........u| 00000030 f3 eb 16 b4 02 b0 01 bb 00 7c b2 80 8a 74 03 02 |.........|...t..| 00000040 80 00 00 80 fc 49 08 00 00 08 fa 90 90 f6 c2 80 |.....I..........| 00000050 75 02 b2 80 ea 59 7c 00 00 31 c0 8e d8 8e d0 bc |u....Y|..1......| 00000060 00 20 fb a0 40 7c 3c ff 74 02 88 c2 52 f6 c2 80 |. ..@|<.t...R...| 00000070 74 54 b4 41 bb aa 55 cd 13 5a 52 72 49 81 fb 55 |tT.A..U..ZRrI..U| 00000080 aa 75 43 a0 41 7c 84 c0 75 05 83 e1 01 74 37 66 |.uC.A|..u....t7f| 00000090 8b 4c 10 be 05 7c c6 44 ff 01 66 8b 1e 44 7c c7 |.L...|.D..f..D|.| 000000a0 04 10 00 c7 44 02 01 00 66 89 5c 08 c7 44 06 00 |....D...f.\..D..| 000000b0 70 66 31 c0 89 44 04 66 89 44 0c b4 42 cd 13 72 |pf1..D.f.D..B..r| 000000c0 05 bb 00 70 eb 7d b4 08 cd 13 73 0a f6 c2 80 0f |...p.}....s.....| 000000d0 84 f0 00 e9 8d 00 be 05 7c c6 44 ff 00 66 31 c0 |........|.D..f1.| 000000e0 88 f0 40 66 89 44 04 31 d2 88 ca c1 e2 02 88 e8 |..@f.D.1........| 000000f0 88 f4 40 89 44 08 31 c0 88 d0 c0 e8 02 66 89 04 |..@.D.1......f..| 00000100 66 a1 44 7c 66 31 d2 66 f7 34 88 54 0a 66 31 d2 |f.D|f1.f.4.T.f1.| 00000110 66 f7 74 04 88 54 0b 89 44 0c 3b 44 08 7d 3c 8a |f.t..T..D.;D.}<.| 00000120 54 0d c0 e2 06 8a 4c 0a fe c1 08 d1 8a 6c 0c 5a |T.....L......l.Z| 00000130 8a 74 0b bb 00 70 8e c3 31 db b8 01 02 cd 13 72 |.t...p..1......r| 00000140 2a 8c c3 8e 06 48 7c 60 1e b9 00 01 8e db 31 f6 |*....H|.......1.| 00000150 31 ff fc f3 a5 1f 61 ff 26 42 7c be 7f 7d e8 40 |1.....a.&B|..}.@| 00000160 00 eb 0e be 84 7d e8 38 00 eb 06 be 8e 7d e8 30 |.....}.8.....}.0| 00000170 00 be 93 7d e8 2a 00 eb fe 47 52 55 42 20 00 47 |...}.*...GRUB .G| 00000180 65 6f 6d 00 48 61 72 64 20 44 69 73 6b 00 52 65 |eom.Hard Disk.Re| 00000190 61 64 00 20 45 72 72 6f 72 00 bb 01 00 b4 0e cd |ad. Error.......| 000001a0 10 ac 3c 00 75 f4 c3 00 00 00 00 00 00 00 00 00 |..<.u...........| 000001b0 00 00 00 00 00 00 00 00 19 aa 09 00 00 00 80 20 |............... | 000001c0 21 00 83 dd 1e 3f 00 08 00 00 00 a0 0f 00 00 dd |!....?..........| 000001d0 1f 3f 8e fe ff ff 00 a8 0f 00 00 58 f0 04 00 00 |.?.........X....| 000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.| 00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 1+0 records in 1+0 records out 1048576 bytes (1.0 MB) copied, 0.0184614 s, 56.8 MB/s

マジックワード0044-0047h = 0x000849fc

00000040 80 00 00 80 **fc 49 08 00** 00 08 fa 90 90 f6 c2 80 |.....I..........| [root@chief zul.kifal]# dd if=/dev/sda skip=$((0x849fc)) bs=512 count=1 | hexdump -C 1+0 records in 1+0 records out 512 bytes (512 B) copied, 0.00260914 s, 196 kB/s 00000000 52 56 5e bf f8 81 66 8b 2d 83 7d 04 00 0f 84 c4 |RV^...f.-.}.....| 00000010 00 80 7c ff 00 74 3e 66 8b 1d 66 31 c0 b0 7f 39 |..|..t>f..f1...9| 00000020 45 04 7f 03 8b 45 04 29 45 04 66 01 05 c7 04 10 |E....E.)E.f.....| 00000030 00 89 44 02 66 89 5c 08 c7 44 06 00 70 50 66 31 |..D.f.\..D..pPf1| 00000040 c0 89 44 04 66 89 44 0c b4 42 cd 13 0f 82 93 00 |..D.f.D..B......| 00000050 bb 00 70 eb 56 66 8b 05 66 31 d2 66 f7 34 88 54 |..p.Vf..f1.f.4.T| 00000060 0a 66 31 d2 66 f7 74 04 88 54 0b 89 44 0c 3b 44 |.f1.f.t..T..D.;D| 00000070 08 7d 68 8b 04 2a 44 0a 39 45 04 7f 03 8b 45 04 |.}h..*D.9E....E.| 00000080 29 45 04 66 01 05 8a 54 0d c0 e2 06 8a 4c 0a fe |)E.f...T.....L..| 00000090 c1 08 d1 8a 6c 0c 5a 52 8a 74 0b 50 bb 00 70 8e |....l.ZR.t.P..p.| 000000a0 c3 31 db b4 02 cd 13 72 3a 8c c3 8e 45 06 58 c1 |.1.....r:...E.X.| 000000b0 e0 05 01 45 06 60 1e c1 e0 04 89 c1 31 ff 31 f6 |...E........1.1.| 000000c0 8e db fc f3 a4 1f 61 83 7d 04 00 0f 85 42 ff 83 |......a.}....B..| 000000d0 ef 08 e9 34 ff 5a ea 00 82 00 00 be 05 81 e8 3d |...4.Z.........=| 000000e0 00 eb 06 be 0a 81 e8 35 00 be 0f 81 e8 2f 00 eb |.......5...../..| 000000f0 fe 4c 6f 61 64 69 6e 67 20 73 74 61 67 65 32 00 |.Loading stage2.| 00000100 2e 00 0d 0a 00 47 65 6f 6d 00 52 65 61 64 00 20 |.....Geom.Read. | 00000110 45 72 72 6f 72 00 bb 01 00 b4 0e cd 10 46 8a 04 |Error........F..| 00000120 3c 00 75 f2 c3 00 00 00 00 00 00 00 00 00 00 00 |<.u.............| 00000130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000001f0 00 00 00 00 00 00 00 00 fd 49 08 00 f6 00 20 08 |.........I.... .| 00000200

（/ boot）は2048から始まります。

# fdisk -lu /dev/sda Disk /dev/sda: 42.9 GB, 42949672960 bytes 255 heads, 63 sectors/track, 5221 cylinders, total 83886080 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: 0x0009aa19 Device Boot Start End Blocks Id System /dev/sda1 * 2048 1026047 512000 83 Linux Par... /dev/sda2 1026048 83886079 41430016 8e Linux LVM

誰かがそれを説明できれば本当に感謝します。

Rui F Ribeiro · Answer

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/3/html/Reference_Guide/s1-grub-whatis.html から

US/Red_Hat_Enterprise_Linux/3/html/Reference_Guide/s1-grub-whatis.html

GRUBは、次の段階で自分自身をメモリにロードします。

ステージ1またはプライマリブートローダーは、BIOSによってMBR [1]からメモリに読み込まれます。プライマリブートローダーは、MBR内の512バイト未満のディスク領域に存在し、ステージ1.5またはステージ2ブートローダーのいずれかをロードできます。

ステージ1.5ブートローダーは、必要に応じてステージ1ブートローダーによってメモリに読み込まれます。一部のハードウェアでは、ステージ2ブートローダーに到達するために中間ステップが必要です。これは、/ boot /パーティションがハードドライブの1024シリンダーヘッドより上にある場合、またはLBAモードを使用している場合に当てはまることがあります。 Stage 1.5ブートローダーは、/ boot /パーティション、またはMBRと/ boot /パーティションのごく一部にあります。

ステージ2またはセカンダリブートローダーがメモリに読み込まれます。セカンダリブートローダーは、GRUBメニューとコマンド環境を表示します。このインターフェイスでは、ブートするカーネルまたはオペレーティングシステムを選択したり、カーネルに引数を渡したり、システムパラメータを確認したりできます。

ステージ2は実際のgrubバイナリであることが明らかです。実際、ドキュメントには、grub 2が名前でロードされると記載されています。

私はしようとします：

dd if=/dev/zero of=/boot/stage2

追加データ：

/ boot/grubの検査：

stage1ブートローダーのコピー：

stage1

Stage1_5のファイル：

e2fs_stage1_5 fat_stage1_5 jfs_stage1_5 minix_stage1_5 reiserfs_stage1_5 xfs_stage1_5

ステージ2のファイル：

stage2

Grub画像へのリンク：

user79743 · Answer

IBM PCブートBIOSシーケンスに準拠しているコンピューター：

ディスクからのMBR（絶対セクター0）は、BIOSによってメモリー0000：7C00にロードされます。
そのコードが実行されます。

IBMからW7へ

IBM PCがブートに使用するコードは次のとおりです。
IBM®Personal Computer™DOS 2.00のMBRの最初のバージョン

そのコードには、スターマンのページにも掲載されている多くのバージョンがあります。
これらの多くのバージョンの出発点は、このページである可能性があります：
MS-DOS 3.30からMS-Windows™95（A）まで

最も一般的なMBRコードの1つは次のとおりです。
MBR for：MS-Windows™95B、98、98SE and ME

そのコードバージョンのほとんどは、次のVBR（ボリュームブートレコード）をロードするためだけに使用されていました。パーティションテーブルでブート可能としてマークされているパーティションのVBRを実行し、それに実行を転送します。
（VBRは絶対ディスクセクター0または W7 MBR ではないことを理解してください）

W7 MBR ページでこのアセンブラーノートを検索します。

;次のコードは、INT 13、関数42h（「拡張読み取り」）を使用して、
;ブート可能なパーティションの最初のセクター（VBR）をメモリの場所0x7c00に配置します。

Windows™7（およびVista）VBR（ボリュームブートレコード）

W7VBR ページからこれを読むのは興味深いです：

;次のコードは、INT 13、関数42h（「拡張ディスク読み取り」）を使用して読み取ります。ブートレコード領域の残りの15セクタを一度に1セクタ。メモリ;場所7E00から。

確認できるように、ブートコードはMBR（ディスクセクター0）で開始し、VBR（ボリュームブートレコード）と多くの（W7では15）次のセクターをロードしました。

GRUB

しかし、ここではGRUBについて話しているので、 the GRUB page に移動します。

そして、このコードを検索してください：

[7C44] -> Note: A very important location for anyone using GRUB! This (4-byte) Quad-Word contains the location of GRUB's stage2 file in sectors! It's called "stage2_sector" in the stage1.S code. If GRUB is installed in the MBR by a distro that always includes a number of sectors from stage2 immediately following the GRUB MBR, you will see the bytes 01 00 00 00 in this location; otherwise, it will point to stage2 in the "/boot/grub" directory.

それはほとんど常に01 00 00 00（または単に：次のセクター）。

つまり、BIOSは絶対セクター0（MBR）をロードし、MBRにインストールされているGRUBコードは次のセクターを読み取り続けます。最大サイズはcore.img（GRUB2）最近のディストリビューション（約60セクター、または約30 kB）。現在のドライブでは、MBRの後に完全なメガバイトが解放されるため、問題はありません。 EFIディスクには、このすべてのコード用に個別のパーティションがあり、問題はさらに小さくなっています（サイズに関して）。

回答

レガシーGRUBステージ2を書き込むか、一部のケースではオプションでステージ1.5をMBRおよび次の62セクターのいくつか/多くに書き込みます。

そして、それは WikipediaのGrubページの画像でも説明されています。

からGNUサイト 10 GRUB画像ファイル：

stage1 This is an essential image used for booting up GRUB. Usually, this is embedded in an MBR or the boot sector of a partition. Because a PC boot sector is 512 bytes, the size of this image is exactly 512 bytes. All stage1 must do is to load Stage 2 or Stage 1.5 from a local disk. Because of the size restriction, stage1 encodes the location of Stage 2 (or Stage 1.5) in a block list format, so it never understand any filesystem structure.

[〜＃〜]注[〜＃〜]：ステージ2が他の物理ディスクに書き込まれている可能性があります。 GRUBページから：

[7C40] -> 80 ("Boot Drive") NOTE: For those of you with multi-OS booting systems, if your Linux installation with GRUB's See: remaining software (stage2, menu file, etc.) is located 7C5A somewhere other than on the Primary Master drive, this value will be 81, 82, etc. depending upon which drive that Linux OS's /boot/grub directory is located. In the stage1.S file, it's called the GRUB_INVALID_DRIVE byte and commented as: "the disk to load stage2 from." (The Word INVALID has something to do with the code logic.)

telcoM · Answer

GRUB Legacyは、いくつかの方法でインストールできます。Stage1.5を使用してもしなくてもかまいません。

インストール時ステージ1.5を使用の場合、MBRのポインターはステージ1.5の先頭を指します。 MBRコードは、ステージ1.5の最初のブロックをロードします。そのブロックのコードには、ロードする追加ブロックのリスト、BIOSパーティション番号、およびステージ2の検索場所を指定するファイル名が含まれています。

しかし、OPの場合、2番目の16進ダンプのテキスト_Loading stage2_で示されているように、GRUB Legacyがインストールされていますステージ1.5なしです。この場合、、MBRはステージ2の最初のブロックを直接ロードします。ステージ1.5の場合と同様に、最初のブロックには、ロードする追加ブロックのリストが埋め込まれます。

ステージ1.5とステージ2の分離は、最初のパーティションをトラック＃1、ヘッド＃0の先頭から開始する古いDOS互換の規則を使用したディスクでも、MBRと最初のパーティションの先頭の間にステージ1.5を埋め込むことができるように存在しました、最新のオペレーティングシステムのようにブロック＃2048（つまり、ディスクの先頭から正確に1 MiB）からではありません。ステージ2はMBRとパーティションの先頭の間の領域に収まらない可能性がありますが、ステージ1.5は1つのファイルシステムタイプのみを読み取ることができる必要があるため、より小さくなります。

インストール時ステージ1.5を使用、GRUBのステージ2は、絶対ブロック番号ではなくファイル名でロードされるため、通常のファイルのように扱うことができます。しかし、インストール時ステージ1.5なし、ステージ2は、インストーラーによって配置されたブロックの場所からディスクに移動できません。ファイルシステムタイプ固有のアクションを実行して、ファイルが誤って移動してください。たとえば、VFATファイルシステムでは、ステージ2ファイルに「システム」属性と「読み取り専用」属性のマークを付ける必要があります。

もちろん、インストーラーはMBRと最初のパーティションの最初の間にステージ2を埋め込むことができます。これが使用可能なスペースに収まる場合、ファイルシステム内の操作からの保護は問題になりません。

OPの2番目の16進ダンプの末尾は次のとおりです。

_000001f0 00 00 00 00 00 00 00 00 fd 49 08 00 f6 00 20 08 _

ロードする追加のブロックの仕様が、8バイトのブロックリスト構造の数として含まれています。この場合、そのうちの1つだけがあります。「ブロック番号0x000849fdから始まる0x00f6ブロックを16ビットセグメントアドレス0x0820にロードする」。ブロック番号は32ビットのみであり、完全なLBA48ブロック番号ではないことに注意してください。これにより、GRUB Legacyによる大容量ディスクの全容量へのアクセスが制限されます。

BIOS（EFIを使用しない）はMBRを読み取り、パーティションテーブルを見つけ、GRUB stage1（最初の446バイト）をメモリにロードします

これは完全に正しいです。

私は1024シリンダー以下の/ bootパーティションを持っていて、たくさんのドキュメントから抽出したアイデアは、GRUB=ステージ1がステージ2を1024シリンダー以下のどこかにある場合、直接ロードできるということです。

技術的には、「32ビットLBAブロック番号でアドレス可能な任意の場所」ですが、それ以外は正しいです。 BIOSがLBAアクセスをサポートしておらず、GRUBが古いC/H/SスタイルのBIOSコールにフォールバックする必要があった場合... " Y2K以降のハードウェアの場合、これは問題にはなりません。

私が参照したいくつかのドキュメントでは、stage1.5はMBRの直後のセクター63の前にあると述べていますが、

If stage1.5が使用されている場合、これは通常、最終的に終了する場所です。ただし、そこに存在する必要はありません。「セクター63の前」は、先に述べたように、最初のパーティションの開始位置の古いDOS規約に由来します。

他の人はそれが最初の1MBのディスクのどこにあってもよいと提案している間

実際には、32ビットのブロック番号でアドレス可能な場所であればどこでもかまいませんが、ステージ1.5の場合、最初の1 MBは通常の場所です。まったく使用されています。「最初の1 MB」は、パーティションの先頭をディスクの先頭から正確に1 MiBに設定するというSSD/SAN対応の最新の慣習に由来します。より大きなブロックサイズ、RAIDストライプサイズ、および/またはストレージハードウェアのその他の配置設定でうまく機能します。

さらに別のグループは、stage1.5は単なるGRUB v2のものであり、GRUBレガシーには適用されません。

このドキュメントはそれを正確に逆にしています：stage1.5は具体的にGRUBレガシーなものonlyです。

GRUBステージ2には、ファイルシステムを読み取るために必要なすべてのドライバー/モジュールがあり、カーネルとRAMディスクをロードし、カーネルにハンドオーバー制御を行います。

正しい。

カーネルは、RHEL/CENTOS 6では初期化を開始し、RHEL/CENTOS 7ではsystemdを開始します。

少し簡略化しましたが、基本的には正しいです。

RHEL/CentOS 6では、最初のユーザー空間プロセスが最初に最初のramdiskファイル内で_/init_を実行します。これは実際にはスクリプトであり、最後のアクションは_exec switch_root <mountpoint_of_real_root_filesystem> /sbin/init <arguments>_または同様のものを実行することです。

RHEL/CentOS 7では、_/init_は実際にはinitramfs内の_/usr/lib/systemd/systemd_へのリンクであり、systemdの特別なバージョンを開始して、_rd._プレフィックス。古いバージョンの_/init_スクリプトと同様に、ルートファイルシステムにアクセスするために必要なものをすべてセットアップし、次に実際のルートファイルシステムにexec() sのsystemdの「フル」バージョンを設定します。

Raoul · Answer

私がしたことは、HirenのブートCDをhiren.infoから自動化されたGRUBローダーでUSBフラッシュドライブにロードするように構成およびインストールすることです。フラッシュドライブ。次に、未割り当て領域にext4パーティションを作成しました。次に、RIPLinuXのxtermでgrub2configコマンドを実行するだけで、インストールは比較的自動化されました。ウィザードでは、grub2がインストールされているパーティションとディレクトリを選択できます。フラッシュドライブのプライマリパーティションのmbrにローダーを設定し、grub2ファイルのインストールディレクトリとしてext4/boot/grubを設定します。

フラッシュドライブのプライマリパーティションのルートディレクトリにある以前のgrldrをgrub2 grldrが置き換えます。以前のmenu.lstファイルは、自動化されたウィザードで選択した起動オプションを含む新しいmenu.lstファイルに置き換える前にバックアップされる可能性があります。 4または5ステップのプロセスが完了したら（構成設定に応じて）、ブートデバイスとしてusbディスクを選択してシステムをリブートし、grub2 menu.lstがブートオプションでロードされたら、文字「c」を入力して、 grub2コマンドインターフェイス。これで、ポータブルgrub2環境に完全にロードして起動できます。

ここに投稿された追加のスクリーンショット： https://www.minds.com/groups/profile/924192575922864128

Isaac · Answer

Grubがシステムを起動する方法はたくさんあります。による：

複数のパーティション（lvmについて読む）テーブルがあるかどうか（パーティションスペースが複数のパーティションに分割される場合があります）。この投稿では、そのタイプのパーティションテーブル（および一致するサブパーティション）が1つしかないディスクのみを検討します。
ディスクが使用しているパーティションテーブルのタイプ（atari、aix、amiga、bsd、dvh、gpt、mac、msdos（PCの通常のデフォルト）、pc98、Sun、ループおよび少なくともGPT）。 msdosパーティションテーブルMBRの例を示しました（この投稿をそのパーティションタイプにさらに制限します）。
各パーティションのファイルシステムタイプ。まあ、主にGRUBがより多くのコードをロードする必要があるパーティションのファイルシステム（通常は_/boot_））。
いくつかの構造体のサイズ（（1）次に読み込まれるセクターは、（多くの）制限（ 528 MByteから137 GByte ）の1つを超えており、使用できる値と使用できない値を定義します。。（2）「フリー」スペースのスペースと相対サイズ（msdosパーティションのMBRの後の62セクター、またはVBR（Windows用語では）のセクターなど）
ディスクのセクターサイズ（古いシステムでは通常512バイト、通常は最近2kバイト）。

議論をMBRブートセクター（msdosパーティション）および_/dev/sda1_上のext {2,3,4}ファイルシステムに制限します（個別の_/boot_パーティションがないか、または持っている場合は、与えていません）そのようなパーティションのLVM構造の詳細）。

この限られたシナリオでも、grubをインストールする方法は（少なくとも）いくつかあります。

しかし、これは単なる可能性です。あなたの場合、Magic Wordはパーティション_/dev/sda1_（絶対セクター（dec）543.228 echo $((0x000849fc))）の中央を指しています。あなたはその位置で最初のセクターを与えました。欠落しているのは、そのセクターを使用しているファイルを検出することです。

_# tune2fs -l /dev/sdc1 | grep Block\ size # find FS block size. Block size: 4096 # echo $(( (0x000849fc - 2048) * 512 / 4096 )) 676647 # debugfs debugfs 1.41.3 (12-Oct-2008) debugfs: open /dev/sda1 testb 676647 debugfs: testb 676647 Block 676647 marked in use debugfs: icheck 676647 Block Inode number 676647 5869525 debugfs: ncheck 5869525 Inode Pathname 5869525 /path/to/FileLoadedByGrub _