Это кажется возможным для kexecWindows, но в лучшем случае это экспериментально (и недостаточно проверено ).

ГРАБ

Невозможно kexecзагрузить grub core.imgотдельно (, так как у него нет совместимого двоичного формата ), см. также этот отчет об ошибке на панели запуска . Упомянутая ошибка все еще воспроизводима:

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. Подсказка найдена в Arch Wiki и старой ветке в списке рассылки grub devel .

lnxboot

lnxboot.imgбудет Linux kernel x86 boot executeable bzImage. Кажется, он предназначен для загрузки как ядро ​​:

You can then load grub2.bin from syslinux/isolinux/pxelinux/lilo or any other boot loader that supports linux kernel.

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
[...]

Grub4Dos

Краткий обзор Grub4Dos:

# file grub.exe
grub.exe: Linux kernel x86 boot executable bzImage, version \353kHdrS\003\002, RO-rootFS, Normal VGA

Это должно означать, что он совместим. Это не вариант для меня, так как это устаревшее программное обеспечение.

Однако мне удалось загрузить grub4dos, загрузив 0.4.4с sourceforge , а затем запустив:

kexec -l grub.exe
kexec -e

Ненастроенный, через некоторое время возвращается к оболочке grub. Если вы хотите использовать gru4dos, вам нужно только настроить cmdlineв соответствии с вашими потребностями. Этот поток по-прежнему должен применяться.

Окна

KexecWindows не кажется однострочной -, но это делалось раньше .

Большая часть работы в этом направлении связана с проектом LinuxBoot . Гитхаб

Я нашел эти слайды , а также этот репозиторий github . Кажется, это проект, упомянутый в статье, который заставил его работать.

Кажется, что это возможно, но много работы (и нет «готового к производству -» решения -По крайней мере, я его еще не нашел ). К сожалению, для LinuxBoot не так много документации, поэтому вам, возможно, придется обратиться к разработчикам. Возможно, уже есть более простой способ сделать это.

kexecможет работать, если вы объедините эти два изображения grub:lnxboot.imgи core.img, например...

cat lnxboot.img core.img > your-kexec-able.img

Стоит попробовать.

РЕДАКТИРОВАТЬ:

Теперь, когда я заглянул внутрь изображений, lnxboot.imageбольше похож на «Эльфа», чем на lnxboot.img, так что попробуйте и его.

РЕДАКТИРОВАТЬ:

Очевидно, образы /boot/grub2/i386 -pc/xxx.img не нравятся kexec.Тогда почему бы не попробовать использовать grub-mkimageдля создания различных форматов и посмотреть, что сработает? На справочной странице -O, --format=FORMATподдерживает целую кучу других форматов. Возможно, попробуйте формат x86_64-xen.

Причина, по которой kexec -встраивается в Windows так сложно и сложно, заключается в том, что механизм внутренней разработки kexec имеет несовершенство, заключающееся в том, что он предполагает, что все загрузчики ОС загружают образ ядра ОС одинаковым образом, что явно не соответствует действительности. дело. Например, некоторые образы ядра ОС должны быть загружены, начиная с некоторого специального смещения адреса памяти, некоторые ОС могут потребовать загрузки дополнительных файлов (, содержащих информацию о драйвере )вместе с образом ядра ОС и т. д. Поскольку мы не можем контролировать, как операционная система загружает свой образ ядра или загрузит свой образ ядра в будущем выпуске, текущий способ подключения kexec -к другой ОС/ядру не будет работать очень хорошо в долгосрочной перспективе.

Более универсальный/совместимый способ (, как я предлагаю )kexec -вхождения в другую ОС, состоит в том, чтобы загрузить загрузочный код реального -режима -загрузочного сектора, выйти из защищенного режиме, а затем перейти непосредственно к точке ввода загрузочного кода реального -режима . Это самый универсальный способ, потому что загрузочный код реального -режима загрузки -сектора любой операционной системы всегда можно загрузить, начиная с любого адреса памяти,вот как BIOS (разные производители компьютеров делают разные BIOS )загружаются в операционную систему (если ОС не хочет, чтобы другая BIOS устанавливала или загружала ее, например, Apple, они могут налагать проприетарные ограничения на то, как загрузить загрузочные -загрузочные коды секторов ). Таким образом, мы всегда можем загрузиться в любую операционную систему, независимо от того, как ее загрузочный код загружает образ ядра ОС, просто потому, что мы напрямую запускаем загрузочный код ее собственного загрузочного -сектора. Кроме того, этот режим не приводит к замедлению -загрузки, потому что загрузочный код загрузочного сектора -мал и, следовательно, загружается быстро, а разница в загрузке большого файла образа ядра в реальном режиме по сравнению с защищенным режимом не очень велика..

Однако добиться этого очень сложно, потому что:

1. Для всех современных ОС, когда они переходят в защищенный режим из реального режима, память реального -режима переполняется -записями некоторых таблиц дескрипторов или таблиц страниц. Таким образом, резервной копии нет. Однако загрузочные коды реального режима используют прерывания BIOS для доступа к аппаратному вводу-выводу, поэтому без восстановления исходной карты памяти реального -режима они не смогут загрузить файл образа ядра с жесткого -диска. Эта проблема сложная, но решаемая. Мы можем установить специальный загрузчик Linux, который делает снимок памяти перед входом в защищенный режим, и это нужно сделать только один раз для всех на одной машине.

2. Не все процессоры поддерживают возврат в реальный режим из защищенного режима. Современные процессоры предназначены для загрузки в ОС (, входящей в защищенный режим из реального режима ), а не для -загрузки ОС (, возвращающейся в реальный режим из защищенного режима ), за счет производственных затрат. и причины эффективности. Таким образом, поведение при возврате в реальный режим из защищенного режима недостаточно проверено и, следовательно, в значительной степени не определено. Поскольку это поведение различается в каждой модели,нет контроля, поэтому нет гарантии, что процессоры какой марки/модели будут работать корректно.

3. Только процессоры Intel X86 имеют реальный и защищенный режимы (, так как они прошли очень раннюю стадию устаревшей технологии ). Таким образом, механизм перезагрузки из загрузочного сектора будет разным для разных процессорных архитектур, не обязательно предполагающим возврат в реальный режим из защищенного режима, но может задействовать некоторые другие переключатели в рабочих состояниях процессора.

Тем не менее, в принципе, это должно работать, если обо всем позаботиться правильно. В будущем Linux должен иметь возможность запускать kexec -в любой подключенный загрузочный -раздел (, но не обязательно помеченный как загрузочный -, потому что каждый жесткий -диск может иметь только один раздел, который помечен как загрузочный -, иначе BIOS сообщит об ошибке и откажется загружаться )с любого жесткого -диска напрямую без полной аппаратной перезагрузки, что намного медленнее. Это пролило больше света и надежды на Linux ^ _^