Я намагався придумати більш простий спосіб встановлення подвійного завантаження Windows та Linux на свій ноутбук, не обов’язково в такому порядку. Зазвичай ми повинні спочатку встановити Windows, а потім встановити Linux і дозволити GRUB працювати з Windows.
Тож те, що я намагаюся досягти, - це знайти спосіб обійти цей прискіпливий процес встановлення (windows) і просто використовувати зображення, щоб безпосередньо скопіювати його на диск. Це також дозволить мені зберегти менеджера завантаження (GRUB). (не те, що я не можу його відновити згодом, але це політика Microsoft для монополізації, в цьому випадку заперечуючи існування інших менеджерів завантаження в системі).
Я спершу отримав юридичну копію Windows 8.1, потім перейшов до встановлення її на віртуальній машині за допомогою VirtualBox. Потім я створив розділ NTFS на жорсткому диску з розділеним GPT і скопіював вміст розділу Windows із зображення .vdi в новостворений розділ.
Звичайно, це ще не працює. Я не знаю, як замінити bootmgr. Це дає
File: \Boot\BCD
Status: 0xc000000e
Info: The Boot Configuration Data for your PC is missing or contains errors.
тому що він не може знайти цей файл з іншого розділу, який використовується для завантаження, відновлення системи тощо.
Тепер я прочитав, що bootmgr зрештою виконує winload.exe для завантаження Windows. У мене немає поняття, що робити далі.
Я вважаю, що це має працювати теоретично, оскільки у мене є всі файли, необхідні для роботи з Windows. Я також вважаю, що я не повинен бути єдиним, хто думав про це, і, отже, я можу пропустити щось дуже базове. Може, це вже зроблено?
Я мало розумію, як працює завантаження. Що мені вдалося зрозуміти, це те, що при подвійному завантаженні Windows та Linux, ви ланцюжок завантажувача windows до Linux. Тому я намагаюся досягти того, щоб якось позбутися завантажувача Windows.
EDIT
Я дивився на бінарні файли bootmgrта \Boot\BCD. bootmgrчитає файл BCD і перераховує ваші параметри, серед яких ви можете вибрати для завантаження.
Отже така інформація, як виконання, winload.exeзнаходиться у файлі BCD. Тепер я думаю, що bootmgrсам виконується syslinux за допомогою chain.c32модуля. Що я намагаюся зробити, це якимось чином виконати завантажувач Windows, тобто winload.exeбезпосередньо з syslinux (якщо це можливо), або змінити bootmgrтак, щоб він виконував winload.exeсебе (шлях якого буде безпосередньо у bootmgrвиконуваному файлі), не шукаючи BCD або нічого іншого.
На цьому кроці мене не хвилює гібернація (яка вимагає іншої процедури).
Відредагуйте своє запитання, щоб повідомити нам тип вбудованого програмного забезпечення та (якщо EFI), чи ввімкнено модуль підтримки сумісності у налаштуваннях мікропрограмного забезпечення
Моя прошивка - це EFI (з увімкненою CSM), і я зазвичай завантажуюся в Arch Linux за допомогою GRUB. Я виявив, що bootmgrвиконується System32\winload.exeна застарілих системах та System32\winload.efiна EFI.
Я маю 0.0ідею, що робити звідси. Останні 10 днів я намагаюся внести зміни до BCD, і думаю, що збираюся досягти успіху. Але це не має значення, адже те, що я дійсно хочу зробити, це взагалі обійти Windows Boot Manager.
Якщо у вас є ідея, чи є спосіб виконати це winload.efiз оболонки EFI (лише здогадка), або якась інша модифікація GRUB, щоб вона завантажувала Windows у режимі EFI без ланцюгового завантажувача.
Будь-які поради вітаються.
Додаток
Наступні повідомлення на форумі можуть дати корисну інформацію:
http://reboot.pro/topic/19371-chainload-direct-to-winloadexe/
1.
Зараз grub4dos може завантажувати завантажувач ланцюга (наприклад, NTLDR або BOOTMGR), оскільки він може виконувати заміну коду, що міститься у "звичайному" завантажувальному секторі (тобто щось на зразок 300 байт машинного коду).
Цей код просто встановлює кілька параметрів, а потім викликає завантажувач.
Навіть це (було) зовсім непросто зрозуміти та повторити з різним кодом.
Система завантажувача NT типу BOOTMGR має більш-менш в єдиній .exe операційній системі "реального режиму" (не зовсім на відміну від DOS) та засоби / інструменти для розбору як простого тексту, так і вуликів Реєстру, це не те, що можна повторно пишеться з нуля легко.
Гарні хлопці @ReactOS працюють над написанням FREELDR (яка має на меті замінити набагато простіший NTLDR) з РОКІВ (і повірте, серед програмістів ReactOS є кілька справді хороших і хороших хлопців).
Це здається (але це не документовано ясно) , що їм вдалося завантажити експериментально сервер 2003 зі NTLDR.
2.
Запроваджуючи підтримку (U) EFI, BootMgr допомагає абстрагувати різницю між BIOS та (U) EFI. Наприклад, ось дві послідовності:
BIOS (PCAT) -> BootMgr { BootMgr stub -> embedded BootMgr.exe } -> WinLoad.exe -> Windows 64-bit (U)EFI -> BootMgFw.efi -> BootMgr.efi -> WinLoad.efi -> WindowsWinLoad очікує присутності певного середовища (включаючи API). Про це піклується BootMgr, тому [майже] та сама програма WinLoad працюватиме в будь-якому середовищі.
Фактично, (U) EFI визначає метод зберігання та отримання параметрів завантаження, тому BCD BootMgr охоплює ту саму мету, незалежно від BIOS / (U) EFI.
Але крім BIOS та (U) EFI відмінностей, BootMgr дозволяє зробити "вибір завантаження", тоді як WinLoad завантажує конкретну операційну систему, яку вона вміє завантажувати.
Залежно від того, яка частина середовища WinLoad очікує бути присутнім, можливо, можна буде безпосередньо запустити WinLoad. Майдан Брауна Майкла Брауна безпосередньо викликає PE BootMgr PE [1], щоб він міг викликати WinLoad безпосередньо, за винятком того, що WinLoad, ймовірно, хоче більше середовища. Ви можете спробувати!
[1] Не слід плутати BootMgr, до якого GRUB4DOS і Syslinux 'chain.c32 можуть викликати. Цей BootMgr містить заглушку, яка вміє викликати вбудований PE BootMgr.
setupутиліті прошивки .