GrubはSSDからゆっくりロードされます。

GrubはSSDからゆっくりロードされます。

昨日からコンピュータに新しいSSDを追加しましたが、grubメニューから起動するのは非常に高速です。問題は、このメニューに到達するまでに長い時間(ほとんどの場合約30秒)待つ必要があることです。 SSDにgrubをインストールしました。 BIOSの後、「Grub loading」がすぐに表示される場合もあり、カーソルだけが点滅する場合もありますが、メニューに移動する時間は同じようです。 debug = diskを追加しようとしましたが(grub.cfgにもdebug = allまで)、説明できない待機時間の後にのみログが表示されます。

3つのディスクがあります。 - ブート可能とマークされ、Windowsブートローダを持つsda - SSDであるsdb - スワップとデータパーティションを含むsdc。昨日までFedora 18をインストールしていませんでした。

別れの説明:

Model: ATA ST3250410AS (scsi)
Disk /dev/sda: 250GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End    Size   Type     File system  Flags
 1      32.3kB  250GB  250GB  primary  ntfs         boot


Model: ATA M4-CT128M4SSD2 (scsi)
Disk /dev/sdb: 128GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  1075MB  1074MB  primary  ext4         boot
 2      1075MB  11.8GB  10.7GB  primary  ext4
 3      11.8GB  33.7GB  21.9GB  primary  ext4


Model: ATA ST3160827AS (scsi)
Disk /dev/sdc: 160GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system     Flags
 1      1049kB  2149MB  2147MB  primary  linux-swap(v1)
 2      52.4GB  160GB   107GB   primary  fat32           lba

また、Windows(sda1)で終了時に説明できない停止時間が発生しますが、この現象は1年前に初めて発生しました。

編集する 250GBドライブを取り外すと、遅延がなくなりました。待ち時間の間、HDD LEDは点滅しません。

どうしたの?

答え1

SSDを最初のSATAポートに接続し、BIOSで最初の起動デバイスとして選択してみてください。それ以外の場合は、通常ドライブを操作し、設定がGRUB物理ドライブ番号(BIOSなどで指定されているなど)hd0と一致することを確認する必要があります。HD0

答え2

私のラップトップの1つで同じ問題が発生したため、この問題の根本的な原因と解決策を知っていると確信していますが、まだ適切な長期的な解決策を見つけることができませんでした。

grub.cfgがある/boot/grub2フォルダを確認してください。私の言葉が正しい場合、grub.cfgのファイルサイズは非常に大きいです。ちなみに、一般的なgrub.cfgは約10k(非常に重いマルチブートでは最大50kかもしれません)ですが、ファイルサイズがメガバイト以上であることは確かに破損の兆候です。

根本的な原因は次のとおりです。インストールまたはメジャーアップグレード後の最後のステップは、grub.cfgファイルを再生成するgrub2-mkconfigを実行することです。これはすべてのディスクなどを検査する深刻なプロセスであるため、時間がかかります。このファイルを作成した後、すべての変更が有効になるように、システムはほぼ常に直接再起動されます。 SSDディスクの場合、再起動によりディスクがハードリセットされ、grub.cfgに書き込まれたデータがNANDセルにまだ安全にコミットされていない場合が発生します。ほとんどの場合、データは存在しますが、ファイルのクローズ(ファイル長の設定など)がまだ発生していないため、通常のgrub.cfgファイルの後に巨大な空きスペース(または古いディスクデータ)が生成されます。

このタスクの効果は次のとおりです。 grub2はgrub.cfgファイルを読み取りますが、通常のデータ(使用可能なブートシステムのリスト)の後にダミーデータ(通常0x00バイトまたは0x00バイト)を解析するのに少し時間(最大30秒)かかります。同様)、時にはエラーが発生することもあります。ただし、最終的にはファイルの終わりを見つけて、見つかった正しいオペレーティングシステムのリストを提供します。

修正:すべてのディスクが利用可能であることを確認し、手動のgrub2-mkconfigを実行してgrub.cfgファイルに出力します。または、16進エディタを使用してデータの実際の端を見つけて、コピーツールを使用して正しいバイト数を新しいファイルにコピーし、問題のあるgrub.cfgを良いgrub.cfgに置き換えます。

ただし、すべてのシステムアップグレードで同じ問題が発生する可能性があるため、より恒久的な修正が必要です。これは、システムのシャットダウン時にすべてのSSDディスクがすべてのデータを継続的にコミットしたことを確認する必要があることを意味します。

関連情報