Это не так. У меня лично после переезда на SSD UEFI отказывался загрузить венду, пока recovery не поменял там GUID.
Про какой скрытый раздел идет речь сейчас? Вот на этом примере:
Number Start End Size File system Name Flags
1 1049kB 269MB 268MB fat32 EFI System boot, esp
2 269MB 1318MB 1049MB Windows RE hidden, diag
3 1318MB 1633MB 315MB ext3 debpad-boot
4 1633MB 170GB 169GB debpad-system
5 170GB 170GB 134MB Microsoft reserved partition hidden, msftres
6 170GB 256GB 85.7GB ntfs Win8 msftdata
Если про самый первый (где лежат системные загрузчики), то в нем есть смысл:
1. UEFI Boot Manager показывает свою менюшку (из пунктов, которые в NVRAM лежат) или выбирает по таймауту boot entry по умолчаниюю
2. Этот же UEFI Boot Manager из Boot entry достает GUID раздела, находит его, загружает с этого раздела прописаный UEFI App (например \EFI\Microsoft\Boot\bootmgfw.efi) и запускает.
3. Дальше уже дело UEFI App.
Для п.2. очевидно, что UEFI Boot Manager должен понимать файловую систему на этом скрытом разделе.
Да, pid=1 (который самый важный и падение которого автоматически вызывает kernel panic) создаёт процессы и увправляет ими — ну так он всегда этим занимался. Криво, плохо, но занимался. Или вы уже забыли про уровни выполнения и inittab?
В pid=1 никогда не было вычисления зависимостей, socket-активации, dbus интерфейса, монтирования файловых систем, управления cgroup, замены крона и еще кучи хлама.
Я не говорю, что что-либо из этого не нужно. Я говорю, что этому явно место не в pid=1.
Ну почему невозможно? Берёте исходники и fork'аете. Опять-таки: всё ровно так, как делалось в UNIX'ах начиная с самого начала.
Я могу с таким же успехом сказать, что WinAPI — прекрасный кроссплатформенный API для приложений. Есть же libwine.
В UEFI есть свой boot manager, который понимает GPT и умеет загружать с него системы. В этом бут менеджере есть свои boot entries, которые ссылаются на файлы в специальном 'EFI boot' разделе. Соответственно их можно добавлять/удалять/менять. Вендовый (или любой другой UEFI-совместимый) установщик копирует свой boot loader в раздел и создает себе boot entry, ссылаясь на свой boot loader. Выглядит это вот примерно так:
При чем в этой самой boot entry ссылки на файлы содержат как минимум GPT-ный GUID раздела. Если он внезапно перестанет совпадать (например, в моем случае после переноса системы на SSD), то загрузиться не получится.
И да, именно этот Boot Manager можно настроить/поправить только из UEFI режима.
UEFI-ный boot manager (который грузится еще до винта и gpt вообще) и позволяет выбирать ось, или загрузить setup, настраивается ТОЛЬКО если система была загружена в UEFI режиме. Просто потому что нет доступа к NVRAM из Legacy.
test, [ и куча других мелких утилит в большинстве шеллов встроены и не являются отдельными процессами.
Основной недостаток systemd — то что в pid=1 (который самый важный и падение которого автоматически вызывает kernel panic), засунули кучу ненужного там хлама.
Второй огромный его недостаток — попытка засунуть в systemd огромную кучу всего вроде session manager-а, с жутко привязаным к systemd dbus-интерфейсом, который просто невозможно нормаль реализовать другим способом.
У меня Lenovo t440p с похожим процом (4800MQ). На максимальной 9cell батарее выживает около 5-6 часов. Ну то есть я могу попытаться выжать 7-8, но для этого нужно позакрывать весь кривой софт вроде скайпа.
В 10 часов я не очень верю, ну кроме U-ный процов.
Зависит от того, что нужно решить. Если система уже поставлена в UEFI режиме (например, ставилось на ноутбук с DVD, который потом на второй HDD заменили), то загружаться в recovery прийдется опять в режиме UEFI.
Да, возможно на некоторых реализациях UEFI. Строго говоря реализация может уметь читать бинари откуда угодно, хоть с какой-нибудь UFS, но _обязана_ уметь только FAT32.
Свежий пример: Lenovo t440p в UEFI режиме умеет грузиться только с флешек с FAT32.
Уязвимость, например, в том, что взял у соседа флешку на 10 минут файл перекинуть, а вместо этого перепрошил её и вернул. Он воткнет её себе куда-то, а она определится какой-нибудь клавиатурой, которая сама нажмет Win-R, cmd, enter и накопирует куда-то файлов или еще чего интересного сделает.
Ну то есть этого по сути и раньше можно было добиться, но на несколько порядков сложней.А тут просто прошивку обновить, если контроллер 'поддерживается'.
В Q10 крайние правые кнопки 'двойные' (при двойном нажатии выбирают нехватающую букву). Встроенная автоисправлялка про это в курсе, так что почти не напрягает
Про какой скрытый раздел идет речь сейчас? Вот на этом примере:
Если про самый первый (где лежат системные загрузчики), то в нем есть смысл:
1. UEFI Boot Manager показывает свою менюшку (из пунктов, которые в NVRAM лежат) или выбирает по таймауту boot entry по умолчаниюю
2. Этот же UEFI Boot Manager из Boot entry достает GUID раздела, находит его, загружает с этого раздела прописаный UEFI App (например \EFI\Microsoft\Boot\bootmgfw.efi) и запускает.
3. Дальше уже дело UEFI App.
Для п.2. очевидно, что UEFI Boot Manager должен понимать файловую систему на этом скрытом разделе.
wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#Boot_Process_under_UEFI
Ну и намучался, пока на ноуте не было ценного ничего.
В pid=1 никогда не было вычисления зависимостей, socket-активации, dbus интерфейса, монтирования файловых систем, управления cgroup, замены крона и еще кучи хлама.
Я не говорю, что что-либо из этого не нужно. Я говорю, что этому явно место не в pid=1.
Я могу с таким же успехом сказать, что WinAPI — прекрасный кроссплатформенный API для приложений. Есть же libwine.
dion@debpad:~% sudo efibootmgr -v BootCurrent: 0015 Timeout: 0 seconds Boot0001 Boot Menu FvFile(126a762d-5758-4fca-8531-201a7f57f850) Boot0002 Diagnostic Splash Screen FvFile(a7d8d9a6-6ab0-4aeb-ad9d-163e59a7a380) Boot0003 Lenovo Diagnostics FvFile(3f7e615b-0d45-4f80-88dc-26b234958560) Boot0004 Startup Interrupt Menu FvFile(f46ee6f4-4785-43a3-923d-7f786c3c8479) Boot0005 Rescue and Recovery FvFile(665d3f60-ad3e-4cad-8e26-db46eee9f1b5) ... Boot0015* debian HD(1,800,80000,11bd80e9-736b-46c2-b17f-9d0f000ac283)File(\EFI\debian\grubx64.efi) Boot0016* rEFInd HD(1,800,80000,11bd80e9-736b-46c2-b17f-9d0f000ac283)File(\EFI\refind\refind_x64.efi) Boot0018* Windows Boot Manager HD(1,800,80000,11bd80e9-736b-46c2-b17f-9d0f000ac283)File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...a................При чем в этой самой boot entry ссылки на файлы содержат как минимум GPT-ный GUID раздела. Если он внезапно перестанет совпадать (например, в моем случае после переноса системы на SSD), то загрузиться не получится.
И да, именно этот Boot Manager можно настроить/поправить только из UEFI режима.
Так вот, чтобы перепрописать установленную систему в UEFI-ный bootmgr, нужно обязательно загрузиться в UEFI режиме.
Основной недостаток systemd — то что в pid=1 (который самый важный и падение которого автоматически вызывает kernel panic), засунули кучу ненужного там хлама.
Второй огромный его недостаток — попытка засунуть в systemd огромную кучу всего вроде session manager-а, с жутко привязаным к systemd dbus-интерфейсом, который просто невозможно нормаль реализовать другим способом.
Я отвечал, почему может быть важно загрузиться в UEFI режиме.
Как минимум десктопные Win7 и Win8 не умеют загружатся с GPT-ных разделов в Legacy/BIOS режиме.
В 10 часов я не очень верю, ну кроме U-ный процов.
Свежий пример: Lenovo t440p в UEFI режиме умеет грузиться только с флешек с FAT32.
Ну то есть этого по сути и раньше можно было добиться, но на несколько порядков сложней.А тут просто прошивку обновить, если контроллер 'поддерживается'.
Найти похожий ноут с нормальным мобильным CPU все сложней и сложней.