
Linux を起動し、自動化されたスクリプトを実行してから自動的に Windows を起動する必要があるアプリケーションがあります。Kexec を使用して grub を実行できますか?
もう 1 つの使用例としては、Linux カーネルを起動してプロセッサのマイクロコードを更新し、次にkexec
GRUB または Syslinux を起動して Windows を起動するというものがあります。これは、マイクロコードが完全な再起動に耐えられないためです。
聞いたことがありますgrub4dos
(リンク(利用不可)、アーカイブ版) ですが、廃止されたようなので、GRUB2 で行う方法はありますか?
基本的に、GRUBのロード可能なイメージが必要ですkexec
。この中のイメージをロードしようとしました。説明ですが、動作しないようです。ヒントがあれば教えてください。
注記: 見つかったこの郵便受け2014 年の時点では、これはまだ kexec に実装されていないとされていました。
答え1
Windowsでも可能と思われますkexec
が、せいぜい実験段階のようです (十分にテストされていません)。
グラブ
kexec
grub単体では不可能ですcore.img
(互換性のあるバイナリ形式がないため)。Launchpadのこのバグレポート上記のエラーはまだ再現可能です:
kexec -l /boot/grub2/i386-pc/core.img
によるとkexec --help
、現時点では次のタイプがサポートされています。
elf-x86_64
multiboot-x86
multiboot2-x86
elf-x86
bzImage64
bzImage
beoboot-x86
nbi-x86
別のローダーをロードしたい場合は、これらの形式のいずれかにするか、互換性を追加する必要があります。GRUB がどの形式を使用しているかはわかりませんが、単純なfile
コマンドでは次のものしか生成されません。
/boot/grub2/i386-pc/core.img: data
起動可能なGRUBイメージの作成
現在、次のような可能性があるようです:
grub2-mkimage
- の一部
core.img
(kernel.img
) - つなぎ合わせ
lnxboot.img
てcore.img
。@Ardwena の回答を参照してください。 lnxboot.img
カーネルとして、core.img
としてinitrd
。ヒントはアーチウィキそしてgrub devel メーリングリストの古いスレッド。
lnxブート
lnxboot.img
になりますLinux kernel x86 boot executeable bzImage
。カーネルとしてロードされることを意図しているようです:
その後、syslinux/isolinux/pxelinux/lilo または Linux カーネルをサポートするその他のブートローダーから grub2.bin をロードできます。
Kexec はこれをロードしますが、実行時にクラッシュします:
kexec -l /usr/lib/grub/i386-pc/lnxboot.img --initrd=/boot/grub2/i386-pc/core.img --debug
ロード中にも問題が発生しているようです (デバッグ出力の最初の数行):
Try gzip decompression.
Try LZMA decompression.
lzma_decompress_file: read on /usr/lib/grub/i386-pc/lnxboot.img of 65536 bytes failed
[...]
グラブ4ドス
Grub4Dos を簡単に見てみましょう:
# file grub.exe
grub.exe: Linux kernel x86 boot executable bzImage, version \353kHdrS\003\002, RO-rootFS, Normal VGA
これは互換性があることを意味するはずです。これはレガシー ソフトウェアであるため、私にとっては選択肢ではありませんでした。
しかし、私はgrub4dos
ダウンロードすることで0.4.4
ロードすることができましたソースフォージそして以下を実行します:
kexec -l grub.exe
kexec -e
未設定の場合、しばらくすると grub シェルに戻ります。 を使用する場合は、 をニーズに合わせてgru4dos
調整するだけで済みます。cmdline
このスレッド依然として適用されるはずです。
ウィンドウズ
Kexec
Windowsの「」はワンライナーではないようですが、以前に行われた。
この方向の研究のほとんどは、Linuxブートプロジェクト。ギットハブ
これらを見つけたスライドこれと同様にgithubリポジトリ記事で言及されていた、これを機能させたプロジェクトのようです。
可能と思われますが、多くの作業が必要です (また、「製品化可能な」ソリューションは利用できません - 少なくとも私はまだ見つけていません)。残念ながら、LinuxBoot に関するドキュメントはあまりないようです。そのため、開発者に問い合わせる必要があるかもしれません。これを行うには、すでにもっと簡単な方法があるかもしれません。
答え2
Windows への kexec の実行が非常に困難で複雑な理由は、kexec の内部設計メカニズムに欠陥があり、すべての OS ブートローダーが OS カーネルイメージを同様の方法でロードすることを想定しているからです。これは明らかに事実ではありません。たとえば、一部の OS カーネルイメージは、特別なメモリアドレスオフセットからロードする必要があります。また、一部の OS では、OS カーネルイメージと一緒に追加ファイル (ドライバー情報を含む) をロードする必要があります。オペレーティングシステムがカーネルイメージをロードする方法、または将来のリリースでカーネルイメージをロードする方法を制御することはできないため、別の OS/カーネルに kexec を実行する現在の方法は、長期的にはうまく機能しません。
他のOSにkexecするより普遍的で互換性のある方法(私が提案する)は、リアルモードブートセクタのブートコードをロードし、保護モードを終了し、リアルモードブートコードのエントリポイントに直接ジャンプします。これは最も普遍的な方法です。なぜなら、どのオペレーティング システムのリアル モード ブート セクタ ブート コードも、どのメモリ アドレスからでもロードできるため、BIOS (コンピュータ メーカーによって BIOS は異なります) はこのようにオペレーティング システムを起動します (OS が他の BIOS によるインストールや起動を望まない限り、たとえば Apple は、ブート セクタ ブート コードのロード方法に独自の制限を課すことができます)。この方法では、ブート コードが OS カーネル イメージをロードする方法に関係なく、常にどのオペレーティング システムでも起動できます。これは、そのオペレーティング システムのブート セクタ ブート コードを直接実行しているからです。さらに、ブート セクタ ブート コードは小さく、ロードが高速であるため、このモードでは速度低下は発生しません。また、大きなカーネル イメージ ファイルをリアル モードでロードする場合と保護モードでロードする場合の違いはそれほど大きくありません。
しかし、これを実現するのは非常に困難です。その理由は次のとおりです。
最近の OS では、リアル モードからプロテクト モードに入ると、リアル モード メモリが一部のディスクリプタ テーブルまたはページ テーブル エントリによって上書きされます。したがって、バックアップはありません。ただし、リアル モード ブート コードは BIOS 割り込みを使用してハードウェア IO にアクセスするため、元のリアル モード メモリ マップを復元しないと、ハード ディスクからカーネル イメージ ファイルをロードできません。この問題は扱いにくいですが、解決可能です。プロテクト モードに入る前にメモリ スナップショットを取得する特別な Linux ブート ローダーをインストールすれば、1 台のマシンで 1 回だけ実行すれば済みます。
すべてのプロセッサが保護モードからリアル モードに戻ることを適切にサポートしているわけではありません。最近のプロセッサは、製造コストと効率上の理由から、OS からアンブート (保護モードからリアル モードに戻る) するのではなく、OS にブート (リアル モードから保護モードに入る) するように設計されています。したがって、保護モードからリアル モードに戻る動作は十分にテストされておらず、ほとんど定義されていません。この動作はモデルごとに異なるため、制御できず、どのブランド/モデルのプロセッサで正しく動作するかは保証されません。
リアル モードと保護モードを備えているのは、Intel X86 プロセッサのみです (非常に初期の段階のレガシー テクノロジを経たため)。したがって、ブート セクターからの再起動のメカニズムはプロセッサ アーキテクチャごとに異なり、保護モードからリアル モードに戻る必要はなく、プロセッサの動作状態のその他の切り替えが必要になる場合があります。
それでも、すべてが正しく処理されていれば、原理的には動作するはずです。将来、Linux は、マウントされた起動可能なパーティション (ただし、起動可能としてマークされている必要はありません。各ハードディスクには、起動可能としてマークされたパーティションが 1 つしか存在できないため、または BIOS がエラーを報告して起動を拒否するため) に、はるかに遅いハードウェアの完全な再起動を行わずに、任意のハードディスクから直接 kexec を実行できるようになります。これにより、Linux にさらなる光と希望がもたらされます ^_^
答え3
grub をインストールし、Linux システムをデフォルトのブートとして設定する必要があります。
Linux システムでは、次のような crontab エントリを作成します。
@reboot /do/some/stuff
/do/some/stuff は、必要なタスクを実行するためのスクリプトです。スクリプトの最後に次のコードを追加します。
#!/bin/bash
#
# Do something here
sudo grub2-once "Windows"
sudo reboot
Windows の GRUB メニュー項目が「Windows」であれば、Windows が再起動されるはずです。
次回の再起動時に Linux に戻り、同じことを実行します。
答え4
kexec
次の 2 つの grub イメージを組み合わせると、次のように機能する可能性がありlnxboot.img
ますcore.img
。
cat lnxboot.img core.img > your-kexec-able.img
試してみる価値はあります。
編集:
画像を見てみると、lnxboot.image
よりも「ELF」に似ているのでlnxboot.img
、そちらも試してみてください。
編集:
どうやら、/boot/grub2/i386-pc/xxx.img イメージは の好みに合わないようですkexec
。では、 を使用していくつかの異なる形式を生成し、何が機能するか試してみませんかgrub-mkimage
? man ページによると、 は-O, --format=FORMAT
他のさまざまな形式をサポートしています。 形式を試してみるといいかもしれませんx86_64-xen
。