Розділ "завантажувальний розділ EFI" та розділ "biosrub"

Навіщо мені це потрібно? Я встановив Ubuntu під не UEFI (головний запис завантаження) і встановив Ubuntu без «біогрузки», і він працює чудово, тоді як в інших випадках мене просять зробити розділ «biosrub». Я поняття не маю, чому іноді мені це потрібно, а іншим я цього не роблю (вони обидва були в одній системі).

І те ж саме відбувається, коли я використовую UEFI (таблицю розділів GUID). Єдина відмінність полягає в тому, що мене просять зробити «завантажувальний розділ EFI», але як і у випадку з «біогруппою», іноді мене просять зробити, а іноді мене не просять зробити.

Для моєї поточної установки мене попросили зробити, але я цього не зробив, і моя система нормально. У системі немає змін, того ж обладнання, BIOS тощо ... Чи може хтось пролити на це світло?

Існує чотири умови (BIOS проти EFI та MBR проти GPT), але дві з них мають однакові потреби (і одна з них надзвичайно рідкісна):

• На традиційному комп'ютері, заснованому на BIOS, з традиційною таблицею розділів MBR, виконуваний код GRUB поширюється навколо, як спагетті, кинуте дитиною. Частина знаходиться у розділі завантажувального коду MBR, частина - у секторах після MBR, які офіційно не розподілені, а частина - у розділі Linux /boot. Це справжній безлад, і він працює лише тому, що розробникам доводилося буквально десятиліттями створювати розумні хаки і відпрацьовувати (майже) всі примхи.
• На традиційному комп'ютері, заснованому на BIOS, з новою таблицею розділів GUID (GPT) код GRUB схожий з тим у попередньому випадку; однак сектори, що безпосередньо слідують за MBR, не є розподіленими; їх використовує сам GPT. GPT не пропонує аналогічного місця для викрадення GRUB, тому розробники GRUB влаштувались на завантажувальний розділ BIOS (який GParted та partedідентифікував за допомогою bios_grubпрапора), щоб утримувати на диску MBR диск код, який переходитиме до секторів після MBR. Це насправді безпечніше і чіткіше, ніж підхід MBR, оскільки він захищає код GRUB від інших програм, які можуть спробувати використовувати цей нерозподілений простір.
• На комп'ютері з новим EFI, а не в BIOS завантажувальні завантажувачі не зберігаються в MBR, в офіційно нерозподілених секторах після MBR або в завантажувальних розділах BIOS; натомість завантажувачі завантажуються як звичайні файли на розділі FAT, відомому як системний розділ EFI (ESP) . ( Конфузно, що інсталятори Debian і Ubuntu посилаються на ESP за назвою "завантажувальний розділ EFI", але це ім'я нестандартне. GParted та partedідентифікують ESP як його "bootпрапор "встановлено, хоча ця термінологія означає щось зовсім інше на дисках MBR.) ESP може існувати як на диску GPT, так і на диску MBR, але перший набагато частіше зустрічається на комп'ютерах на базі EFI. Підхід EFI набагато безпечніший і набагато гнучкіший, ніж підхід BIOS, оскільки він не витягує необроблений код у дивних місцях; завантажувачі завантажуються у файли, як і програми на рівні ОС. Це полегшує їх ідентифікацію та маніпулювання. (OTOH, EFI також зберігає дані на завантажувачах NVRAM, що створює другу точку відмови в процесі завантаження. Новість EFI також означає, що це не так добре перевірено, що спричиняє безліч специфічних для EFI проблем.)

GhostMotleyX, ваш коментар до відповіді LiveWireBT заявив, що "найкращим" способом встановлення є BIOS / MBR. Це, звичайно, суб'єктивно, але я не згоден з цією оцінкою. Підхід BIOS / MBR є найменш безпечним та самимнезграбність трьох підходів, які я тільки що окреслив. Підхід EFI - це найбезпечніший і гнучкий підхід. Я підозрюю, що ви зациклювались на тому, що для підходів GRUB / GPT та EFI потрібні окремі розділи, але це не є великою справою. Окрім налаштування системи чи технічного обслуговування розділів, ці розділи будуть для вас майже непомітними, і вони надають вам велику гнучкість. На відміну від MBR, GPT не обмежується чотирма первинними розділами, тому вам не потрібно приховувати свої первинні розділи, як гном, що зберігає його золото.

Вам потрібно створити розділ biosrub на диску з розділеним GPT під час налаштування застарілого завантаження або завантажувального розділу EFI (для GPT або MBR з розділеним диском) під час налаштування завантаження UEFI.

• GRUB потребує завантажувального розділу BIOS (2 MiB, без файлової системи, EF02введіть код у gdisk або прапор bios_grub у розділеному GNU) в системах BIOS для вбудовування свого core.imgфайлу через відсутність проміжку вбудовування пост-MBR в диски GPT . [...]

^{https://wiki.archlinux.org/index.php/GPT#Bootloader_Support}

Я дам один додатковий пункт / мотив щодо того, що обидва, EFI та BIOS grub.

USB-накопичувач для завантаження циклу Live SystemRescueCD.iso від Grub2.

Чому? Проста відповідь: вона завантажиться на багатьох комп'ютерах, у деяких є UEFI, у деяких є лише 32-бітний старий BIOS тощо.

Справжній складний мотив: по можливості використовуйте сучасне обладнання (UEFI).

Реальний зразок використання в реальному часі:

• USB-накопичувач (форматований у режимі GPT) з чотирма розділами
• Перший розділ (його можна побачити з Windows 7 і вище) на NTFS з рештою розміру USB-накопичувача
• Другий розділ для файлів Grub2 та SystemRescueCD.iso принаймні 1GiB (краще, якщо 2GiB, щоб ви могли переносити дві версії SystemRescueCD.iso одночасно, лише для тестування нової версії до заміни старої), я зазвичай використовую файлову систему Ext4 для нього
• Третій розділ для EFI (те, що Windows називає ESP), відформатований як Fat32 принаймні 512MiB (я бачив деякі ПК, які, якщо використовують менше, не показують USB-накопичувач як завантажувальний носій)
• Четвертий розділ для BIOS_Grub (формату немає, але при створенні очищається)

Одне важливе: я бачив 8GiB LG USB-стрикт (один у мене є власний), який відмовляється відображатись у фізичному завантаженні UEFI ПК, якщо розділи не вирівняні по циліндрам, але їх можна побачити на інших комп'ютерах UEFI, а також на VirtualBOX з завантаженням UEFI режим активований ... при розділенні його, якщо його вирівняно на MiB, він використовує весь простір, не поруч з нерозподіленим простором 1MiB в кінці, але при вирівнюванні до циліндрів останній неповний MiB не використовується ... якщо я робити перегородку MiB, маючи це на увазі (іншими словами, я роблю ручне вирівнювання циліндрів), воно працює, але, як я говорю, він все ще вирівнюється циліндром (я це роблю вручну, замість того, щоб дозволити інструменту розділення зробити це за вас).

Як отримати таку чудову USB-накопичувальну паличку (вона має два фокуси):

1. Вирівнювання розділів за циліндрами (краща сумісність просто підрівняти до MiB)
2. Зробіть grub-install --target = i386-pc, а потім зробіть інший grub-install --target = x86_64-efi на одному і тому ж розділі grub, тому ви використовуєте лише один grub.cfg для обох режимів завантаження.

Як це черевики:

• а) завантажуючи форму старого BIOS, завантажить MBR, потім Stage2 grub форми BIOS_grub розділу, а потім core.img з розділу Grub2
• б) завантажувальна форма, сумісна з UEFI, завантажить файл .efi з розділу ESP
• grub.cfg читається (якщо існує на розділі grub2)
• потім відображається меню grub2
• тоді я вибираю завантажуватися з циклу SystemRescueCD.iso (з параметром dochace), я встановив два варіанти, встановлені на grub.cfg, один на 32Bits, один на 64Bits (у мене дійсно чотири варіанти, оскільки я встановив два параметри dostartx для завантажуємо безпосередньо на GUI).
• після завантаження я можу вийняти USB-паличку (весь Live Linux знаходиться в ramdrive завдяки такому docache), не потрібно вводити жодної команди, pendrive не встановлений (знову ж таки завдяки параметру docache).

За допомогою цієї палички я можу завантажувати старий ПК (якщо вони дозволяють завантажуватися з USB) у 32 біти, а також у 64 біти (якщо у них є розширення на процесорі), але завантажуючись у режимі BIOS.

За допомогою цієї палички я також можу завантажувати новий ПК (якщо вони дозволяють завантажуватися з USB) у 32 бітах та 64 бітах, але завантажуватися в режимі UEFI (ах, так, він може завантажуватися в режимі UEFI, а потім просто завантажувати Linux Live SystemRescueCD в 32 біт режимі, а також у 64-бітному режимі).

Отже, у мене є все завантажувальне носій для відновлення USB-накопичувача, здатний завантажуватися майже на всіх комп'ютерах, сучасних або старих (потрібна лише підтримка завантаження через USB), незалежно від того, чи будуть 32 біти або 64 біти, BIOS або UEFI і т.д. ... і я можу виберіть те, що я хочу запустити 32 біт або 64 біт.

Крім того, я протестував на ПК, який відмовляється встановлювати Windows 64Bits (старий 32Bits процесор), але мати можливість запустити 64-бітний Linux Live (тому що на цьому процесорі існує можливість PAE).

Бічна примітка: Такий перший розділ, як NTFS, призначений для зберігання даних, які можна спільно використовувати з Windows 7 і новішими версіями (XP не побачить його, оскільки не підтримує GPT-розділення) ... він повинен бути першим, не потрібно початково частина диска, може бути де завгодно, але каша зберігається як перший запис у таблиці розділів, це спричинено режимом Windows, що підлягає ненависті, для монтажу розділів на знімні, у ньому специфічно запрограмований код, щоб уникнути доступу до першого розділу. не можуть монтувати інші одночасно.

Додатково для розділів Windows та USB: Якщо ви поміняєте записи розділів на таблицю розділів, іншими словами, ви розмістите розділ, до якого ви хочете отримати доступ, як перший у таблиці, Windows дозволить вам отримати доступ до нього (якщо його формат зрозумілий, fat32 та NTFS безпосередньо, ext2 зі спеціальними драйверами тощо), але дозволять отримати доступ лише до того, який знаходиться під час першого входу в таблицю розділів ... є інструмент (званий BootICEx86.exe), який може виконати таку роботу в Windows навіть не потрібно від'єднувати штекер USB.

Супер додатково: також є кілька мандрів (мені дуже пощастило володіти одним, Sony 16GiB), ніж їх можна змінити спеціальними інструментами (моє з інструментом lexar), тому вони з'являються у Windows як USB HDD замість USB-накопичувача , після цієї зміни всі вікна дозволять вам видаляти, створювати та керувати розділами на ньому, також може бути змонтовано декілька одночасно, кожен з яких має свій власний лист.

Користувачі Linux з цим не хвилюються, оскільки Linux розглядає це як блоковий пристрій, що розділяється, і не застосовує спеціальний код для блокування монтажних розділів тощо, як це має Windows.

О, так, останні останні абзаци написані на всякий випадок, якщо хтось на M $ прочитає їх, тож їх обличчя опуститься на підлогу, я намагаюся (не отримаю цього ніколи, я знаю, що це втрачений об’єктив) їм зняти таке некрасивий код з Windows, і нехай користувачі матимуть розділи на usb палицею.