カーネルのロギングが開始される前に grub でのブートパフォーマンスの問題のデバッグ

カーネルのロギングが開始される前に grub でのブートパフォーマンスの問題のデバッグ

コンピュータの起動に時間がかかります。これは、グルーブ後にカーネルのロギングが開始される前の遅延によって引き起こされたと信じる理由があります(起動には30秒かかりますが、メッセージのタイムdmesgスタンプは0.00000-の間です9.34223。詳細については参照)。この投稿)。

何が起こっているのかをデバッグする方法はありますか?特に:

  • grub自体をより冗長にするか、ログを維持する方法はありますか?
  • grubとカーネルロギングの間に時間がかかる他のプロセスはありますか?これをどのようにデバッグしますか?

この問題は私の設定に限定された問題ではないようです。しかし、私たちはUbuntu 16.10とgrub(2)を実行しています。

編集する:

@TooTeaの提案に従って環境変数を設定しましたが、問題にならないdebug=all多くのメッセージが生成されました。script/script.c:50 malloc 0x7a9a2ca0その後、8秒の遅延と一致するメッセージセットがあります。

kern/dl.c:56 Detecting ext2... 
lib/relocator.c:1397 chunks = 0x7a7e0ae0
lib/relocator.c:434 trying to allocate in ...-... aligned ... size ...
lib/relocator.c:1198 allocated: ...+...
lib/relocator.c:1409 allocated .../...
lib/relocator.c:1410  chunks = 0x7a7e0ae0

答え1

これは間違いなく私の質問に対する完全な答えではありませんが、同様の問題を調査しながらここに来た他の人に役立ちます。

GRUBのマニュアルでは、debug環境変数またはdebug=all施設名とともにカンマ/スペースのリストを使用することをお勧めします。次に、次のように言います。

詳しくはソースをご覧ください。

オンラインで潜在的なリストが見つかりません。したがって、後で参照できるように、現在のgithubリポジトリcoreos / grubからこれらの名前のリストを取得しました。この名前が今後出てきて、他の人に役立つことを願っています。もちろん、ソースに関する追加の調査がなければ、制限的に使用されますが、それでも良い出発点になる可能性があります。

name                frequency in source
acpi                |||||
affs                |
ahci                ||
appleload           |
arcdisk             ||
archelp             ||
ata                 ||
atkeyb              ||
biosdisk            ||
bsd                 ||||
btrfs               ||
cache               ||
cbfs                |
chain               |||
crypt               ||
cryptodisk          ||
datetime            |
devalias            ||
disk                |||||
diskfilter          ||
dl                  ||||||||
dns                 ||
drivemap            ||
efi                 ||
efidisk             ||
efiemu              ||||||||||||||
ehci                ||
elf                 ||
exfat               |
expand              ||
fat                 |
fb                  ||
fdt                 |
fixvideo            ||
font                ||
fs                  ||
geli                ||
gpt                 ||||
hostdisk            |||||
init                |||||
jpeg                |
keystatus           ||
lexer               |
linux               |||||||||||||
loader              |||||||
luks                ||
memdisk             ||
mm                  ||
mmap                |||||
modules             ||
multiboot_loader    |||||
nativedisk          ||
net                 ||||||||||
ohci                ||
partition           ||||||
pata                ||
play                ||
reiserfs_tree       ||
relocator           |||
scripting           ||
scsi                ||
serial              ||
smbios              ||
syslinux            ||
tftp                ||
tga                 ||
ubootdisk           ||
uhci                ||
usb                 ||||||
usb_keyboard        ||
usbms               ||
video               |||||||
xen                 |||||||||
xen_loader          ||
xfs                 ||
xnu                 ||||||
zfs                 |||||

たとえば、次のように書くことができます。

set debug=linux,video,fs

/boot/grub/grub.cfgGRUBのデバッグ冗長性を減らし、これらの機能についてのみデバッグメッセージを表示するには、に進みます。

答え2

想像できるように、GRUBとLinuxの間の移行には非常に複雑な低レベルのステップが含まれているため、高度なトレースやロギングの余地はありません。幸いなことに、このコードには拡張一時停止のためのスペースがないため問題ありません。 GRUBですべての準備ステップを設定すると、非常に詳細なトレースが得られます。debug環境変数

ただし、制御がLinuxカーネルに移行された後に発生する遅延が発生する可能性が高くなります。通常、コンソールが初期化されるまでログメッセージは表示されません。また、指摘したように、タイミングサブシステムが初期化されるまで、すべてのタイムスタンプがゼロであるため、後でタイミングを計算することはできません。

幸いなことに、ブートオプションを使用すると、カーネルにearlyprintk実際にログメッセージをどこかに印刷させることができ、リアルタイムで追跡して遅延が発生する場所を確認できます。earlyprintkさまざまなターゲットを指定できますが、一般的な(物理的)システムと最も関連性の高いターゲットはserialvga(以前のコンソール)またはですefi。カーネルが適切な設定オプションで構築されていることを確認してください(CONFIG_EARLY_PRINTK*)。

関連情報