カーネルの起動に 9 分もかかる間、GRUB は何をやっているのでしょうか?

カーネルの起動に 9 分もかかる間、GRUB は何をやっているのでしょうか?

最近 (少なくとも PC の電源を入れた最後の 2 回)、grub の起動に非常に時間がかかることに気づきました。BIOS メッセージが消えてからカーネル ログが画面に表示されるまでの時間を計測したところ、約 9 分かかりました。

問題は、grub が何を実行しているか、何を待機しているかをどうやって知ることができるかということです。grub が正常かどうかをどのように確認できるでしょうか。

数日前にスプラッシュ スクリーンを削除したので、起動するたびにテキスト ログが表示されます。ほとんどの場合、高速で正常です。その 9 分間、モニターは信号を受信しますが、画面は真っ黒です。NumLock は応答せず、全体がフリーズしているように見えますが、そうではありません。

少なくとも 2009 年からソフトウェア RAID1 を使用しています。

RAID は正常であると報告されています。最初の 1 分間に、ハード ディスクの小さなアクティビティがいくつか発生しています。ハード ドライブの SMART データは正常です。前日のシャットダウンは正常でした。

このコンピューターには、8.04 以降、すべての Ubuntu バージョンがインストールされています。10 月から 12.10 をインストールしています。このコンピューターには新しいものはなく、新しいハード ドライブはなく、BIOS 設定の変更もありません。

私の知る限り、grub ログはなく、カーネル ログは興味深いものではありません。カーネルが 28 秒で起動したと表示されているためです [PhenomX4 kernel: [ 28.825313] vboxpci: IOMMU が見つかりません (登録されていません)]。つまり、9 分はカーネルが起動する前です。

*更新: 3月27日 *

問題は見つかりましたが、原因はまだわかりません。問題は、/boot/grub/grub.cfg が 11.6 MB で、このエントリのようなエントリがわずかな違いを伴って何度も繰り返されていたことです。Grub は、メニューを作成するためにこのような大きなファイルで処理に苦労していました。

menuentry 'Ubuntu 12.10 (12.10) (en /dev/sda1) (en /dev/sda1) (en /dev/sdb1) (en /dev/sda1) (en /dev/sda1) (en /dev/sda1) (en /dev/sda1) (en /dev/sda1) (en /dev/sda1) (en /dev/sda1) (en /dev/sda1) (en /dev/sda1) (en /dev/sda1) (en /dev/sda1) (en /dev/sda1) (en /dev/sda1)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/vmlinuz--73e06880-5f46-4493-aaef-23fa4ad138f6' {
    insmod part_msdos
    insmod ext2
    set root='hd0,msdos1'
    if [ x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 --hint='hd0,msdos1'  73e06880-5f46-4493-aaef-23fa4ad138f6
    else
      search --no-floppy --fs-uuid --set=root 73e06880-5f46-4493-aaef-23fa4ad138f6
    fi
    linux /vmlinuz root=/dev/sda1
    initrd /initrd.img
}

なぜそのファイルがこんなに大きくなったのかまだ分からないのですか?

3月28日更新

メニュー エントリの大部分は /etc/grub.d/30_os-prober によって生成されます。

Line 223: ### BEGIN /etc/grub.d/30_os-prober ###
...
Line 175174: ### END /etc/grub.d/30_os-prober ###

grub.cfg には 175191 行あるため、このスクリプトはファイル内の 11.6 MB の 99% を占めます。

答え1

リポジトリには BootChart という便利なツールが含まれています。また、GRUB デバッグ コンポーネントも提供されています。これらを使用すると、ブートをプロファイルして、多くの時間を費やしている原因を突き止めることができます。

ここに画像の説明を入力してください

答え2

これらすべてのエントリを取得した場合、おそらく Grub でループを作成している何かがあります。別のパーティションに Raring をインストールしたときに、同様のことが起きました (不適切なエスケープにより、 のようなエントリが作成されましたmenuentry "Ubuntu"...)。何も変更していないとおっしゃったように、これは Grub の何らかの更新に原因があるのでしょうか?

このファイルは、 にあるスクリプトによって自動的に生成されます (たとえば、新しいカーネルをインストールするときなど) /etc/grub.d。調べてみるとgrub.cfg、エントリ間にセパレーターがあり、どのスクリプトによって生成されたかがわかります。例:

### BEGIN /etc/grub.d/30_uefi-firmware ###
### END /etc/grub.d/30_uefi-firmware ###

### BEGIN /etc/grub.d/40_custom ###
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
menuentry "Ubuntu Raring (on /dev/sda2)" --class gnu-linux --class gnu --class os {
    (...)
}

menuentry 'Steam' --class ubuntu --class gnu-linux {
        (...)
}
### END /etc/grub.d/40_custom ###

### BEGIN /etc/grub.d/41_custom ###
if [ -f  $prefix/custom.cfg ]; then
  source $prefix/custom.cfg;
fi
### END /etc/grub.d/41_custom ###

したがって、どのスクリプトがそれらのエントリを作成しているかを特定してください (そして、スクリプト名で回答を更新してください)。そこに到達したら、sudo grub-mkconfigたとえば次のようにしてそのスクリプトを使用または実行できます。

sh -v /etc/grub.d/file

何が起こっているのかを特定しようとする。

これはまったく解決策ではありませんが、何かの役に立つことを願っています。

関連情報