Linux mbr to uefi

Как я могу изменить / преобразовать Ubuntu MBR-диск в GPT и заставить Ubuntu загружаться с EFI?

Я недавно обновил свой компьютер, моя новая материнская плата (ASUS M5A99X EVO) использует UEFi вместо обычной опции MBR.

У меня есть установка Ubuntu 11.10, которую я сделал, когда у меня было предыдущее оборудование (MSI MS 7267), только Ubuntu загружается нормально, и так же как и Windows 7, однако Windows 7 использует загрузку UEFI (GPT), тогда как Ubuntu использует MBR.

У меня есть мои ОС на отдельных дисках, так что GRUB2 не будет заменен загрузчиком Windows и наоборот, как я сказал, обе ОС нормально загружаются, но для этого мне нужно отключить один диск, в этом случае диск Ubuntu как это препятствует загрузке Windows.

Теперь мой вопрос: как я могу изменить / преобразовать диск Ubuntu, чтобы вместо использования MBR он использовал GPT и разрешал загрузку Windows?

Желательно без переустановки всей системы или потери каких-либо данных.

И если бы мне пришлось стереть диск, как я могу установить Ubuntu в GPT, UEFI, в каком бы режиме он ни находился?

Я использовал gdisk для преобразования из MBR в GPT, но теперь Ubuntu не может загрузиться, похоже, что grub просто не запускается.

Я переустановил ОС, и диск по умолчанию теперь GPT, но grup-pc все еще используется вместо grub-efi .

Как я могу сделать загрузку Ubuntu с EFI?

1. терминология
2. преобразование
3. Конфигурирование (+ Двойная загрузка)

терминология

BIOS = базовая система ввода / вывода

(U) EFI = (унифицированный) расширяемый интерфейс встроенного ПО

MBR = основная загрузочная запись

GPT = таблица разделов GUID

UEFI / EFI / BIOS = интерфейс прошивки

MBR / GPT = Как компьютер знает (на жесткий диск), какие разделы находятся на диске и как с них загружаться.

UEFI / BIOS

Интерфейс прошивки является способом , что встроенное программное обеспечение (программное обеспечение внутри устройств) и операционной системы взаимодействуют между собой . Он инициализирует оборудование, затем запускает операционную систему и гарантирует, что драйверы операционной системы могут работать с оборудованием.

BIOS был обычным интерфейсом прошивки, который был использован. UEFI является более новым интерфейсом, который имеет несколько функций, таких как быстрая работа, наличие графического интерфейса пользователя и возможность запуска сетевой карты и получения IP-адреса. UEFI заменяет EFI. (Те, кто разрабатывал EFI, увидели, что другие делают что-то подобное, и присоединились к ним, привнося с собой идеи EFI. Затем это стало UEFI).

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

MBR / GPT + GRUB

MBR представляет собой часть кода в начале диска , который содержит загрузчик (для BIOS), а также карту разделов и уникальный идентификатор диска.

Чтобы установить GRUB на диск с MBR, GRUB помещает небольшую программу в MBR для загрузки остальной части GRUB из другой части диска. (Это сделано потому, что MBR слишком мала, чтобы содержать весь GRUB). Выбранный пробел — это пробел между MBR и первым разделом, который обычно существует.

GPT — это стандарт определения разделов. Он имеет «защитную» MBR, однако это только для того, чтобы позволить компьютерам на базе BIOS загружать и останавливать инструменты, которые знают только о MBR, от попыток уничтожить GPT. Может иметь

(То, как обрабатывается GPT, зависит от того, загружается ли он с использованием BIOS (или системы UEFI в режиме эмуляции BIOS) или UEFI. Я остановлюсь на UEFI, поскольку это относится к вопросу).

Загрузчики для операционных систем хранятся в разделе под названием EFI System Partiton, который отформатирован (обычно) в FAT32. Это где GRUB установлен.

преобразование

Мы играем с таблицей разделов, поэтому гарантированная безопасность невозможна. Это рискованная операция. Однако метод не должен терять данные.

Другие сталкиваются с этим: не используйте на Apple Mac.

В настоящее время.

Вам нужно будет сделать это на live CD (или на другой инсталляции linux, установленной на другой диск).

При работе с GPT-дисками нам нужно использовать программу, поддерживающую GPT. «GPT fdisk» — это хороший инструмент, который я буду использовать. Он может быть вызван gptfdisk или в gdisk зависимости от дистрибутива (Ubuntu называет его gdisk ). Parted (и Gparted) также поддерживает GPT, поэтому его можно безопасно использовать с GPT-дисками.

Для конвертации вам необходимо:

1. Изменение размера разделов в соответствии с данными GPT и системного раздела EFI.
2. Конвертировать диск и добавить разделы
3. Установите GRUB в системный раздел EFI.

1) Изменить размер раздела

Используйте parted (командную строку) или gparted (GUI), чтобы изменить размер первого и последнего раздела. Первый раздел должен иметь около 200 МБ до него, а последний раздел должен иметь от 1 МБ до 2 МБ (любой будет), снятый с конца.

2) Конвертировать диск

изменить устройство, которое вы хотите конвертировать /dev/sdx .

Он должен сказать вам, что он преобразует таблицу разделов.

Теперь добавьте новый раздел, сделав его типа «система EFI». Он должен найти свободное место в начале (я предлагаю небольшое число секторов, например, 34) и автоматически использовать все свободное пространство. В примерах используется флэш-накопитель USB объемом 4 ГБ, на котором уже есть 1 раздел, с измененным размером, как указано выше.

Теперь у вас должен быть раздел EFI.

Затем выход gdisk

Теперь используйте Gparted (или командную строку mkfs.vfat ) для форматирования раздела как FAT32.

3) Установить GRUB

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

Я не уверен в этом шаге, поэтому я угадаю, используя инструкции RAOF :

Чтобы перейти на Grub-EFI, вы бы хотели

1. Найдите свой раздел EFI; смонтировать его в / boot / efi. Добавьте это в / etc / fstab¹
2. Установите пакет grub-efi
3. Переключите приоритет загрузки BIOS с UEFI и Legacy только на UEFI (или аналогичный вариант)

Вы должны решить, какую версию grub-efi установить с

Если он говорит EFI32 установить grub-efi-ia32 пакет, если он говорит EFI64 установить grub-efi-amd64 пакет. Вы можете установить пакеты с

Это, вероятно, будет работать, только если вы загрузились в режиме EFI.

Если это не работает, вы можете попробовать эти пошаговые инструкции (в разделе «Установка GRUB2 в (U) EFI-системах») после grub-efi установки.

Конфигурирование (+ Двойная загрузка)

Если инструкции РАОК работают, вы сможете добавить следующую строку в /etc/grub.d/40_custom

Предполагается, что Windows распознается как hd0 GRUB. Может потребоваться изменить hd1 , чтобы работать.

обновить файл конфигурации.

Ссылки и дальнейшее чтение

Я использовал несколько источников.

• Род Смит » GPT fdisk tutorial «. Хорошо для получения дополнительной информации.
• Страницы Википедии для UEFI , BIOS , MBR и GPT .
• UEFI загрузочная вики-страница Ubuntu . Хорошо, если вы застряли.
• UEFI владеет информацией о странице .

Этот ответ неполон; Я не проверял ничего из этого. Вряд ли есть какие-либо ваши данные, но вы были предупреждены!

Я предполагаю, что здесь происходит то, что ваш BIOS загружается преимущественно из устаревшей MBR, так что старая версия UEFI Windows 7 игнорируется.

Одна из приятных сторон UEFI заключается в том, что вам больше не нужно беспокоиться о перезаписи GRUB в Windows; они оба должны прекрасно сосуществовать в разделе EFI. Поэтому одним из вариантов будет переключиться на grub-efi . Примечание: я не уверен, grub-efi понимает ли разделы в стиле MSDOS; Я думаю, что это так. Если этого не произойдет, это не удастся загрузить, и вам потребуется LiveCD для восстановления. На самом деле, LiveCD всегда под рукой!

Чтобы переключиться на grub-efi вы хотели бы

1. Найдите свой раздел EFI; смонтировать его в /boot/efi . Добавьте это к /etc/fstab ¹
2. Установить grub-efi пакет
3. Переключите приоритет загрузки BIOS от UEFI and Legacy до UEFI only (или подобный вариант)

Это должно оставить вас с UEFI-загрузочной установкой Ubuntu. Если этого не произойдет, загрузите ваш надежный LiveCD (или установочный компакт-диск Ubuntu Alternate — вам нужен вариант «Исправить неисправную систему»), загрузитесь в вашу систему и установите grub-pc снова.

¹: Подробнее об этом шаге: вам нужно найти то, что ядро ​​Linux называет системным разделом EFI. Это будет что — то вроде /dev/sda2 , /dev/sdb3 или such². Затем вам нужно будет создать /boot/efi каталог и добавить строку в /etc/fstab . Если ваш раздел EFI /dev/sdb3 , то вы бы добавили следующую строку:

После запуска sudo mount /boot/efi вы должны найти то , что /boot/efi содержит EFI каталог с подкаталогом для Windows 7.

²: Поскольку у вас есть несколько жестких дисков, было бы неплохо выяснить UUID раздела, поскольку он будет стабильным при добавлении / удалении жестких дисков, тогда как /dev/sda2 имя не гарантируется, что оно не изменится. Это может быть сделано после того, как вы закончили все остальное.

Вы можете найти UUID, заглянув в /dev/disk/by-uuid . Например, я получаю:

В моем случае, я знаю, /dev/sda1 это мой системный раздел EFI, поэтому у меня есть

Источник

Move your Linux from legacy BIOS to UEFI in place with minimal downtime

Photo by cottonbro from Pexels

I don’t know about you but I don’t like to reinstall my operating system. I find it a complete waste of my time for something that should just update in place. Some people, often using other platforms, prefer a good once-a-year wipe and reinstall to regain the original speed of their systems. I just don’t subscribe to this point of view. There are many ways to maintain a system and I usually prefer some investigative debugging rather than wiping and hoping for the best.

For this reason, systems like my work laptop might have started their life a long time ago (Fedora 22 on an i7-based 4th generation laptop) and have by now seen three hardware refreshes, several solid state drive (SSD) upgrades, and many Fedora updates (I currently use Fedora 32).

When I switch systems, I like to take my operating system with me and expect it to boot on the new machine. But it turns out that’s a disaster waiting to happen because of hardware differences between the new and old systems. The problem is that it’s not as simple as pulling your hard drive from an old system and popping it into a new one and expecting everything to work as desired. This article describes how to move a Linux install from one piece of hardware, in this case, an older laptop, to a newer one.

The big caveat or the ten years of advanced warning UEFI gave us

More Linux resources

When Unified Extensible Firmware Interface (UEFI) was introduced in the early 2000s, it was designed to replace PC (Basic Input/Output System) BIOS and provide x86 users with something more technologically advanced. People with SPARC or PowerPC Mac systems with OpenBoot PROM (OBP)/OpenFirmware had already experienced the future many years before. UEFI wanted to evict the BIOS so its predecessors would no longer shame the PC.

For UEFI technology to be widely adopted, manufacturers opted to make it optional/selectable from the machine’s firmware: Do you want to boot in Legacy BIOS or UEFI mode? Over the course of the next ten years, UEFI slowly pushed Legacy BIOS out and became the default mode for machines shipped by manufacturers.

To be fair, UEFI provides multiple advantages, including these:

• It makes multi-booting more reliable and flexible.
• It gives us (Linux users) the ability to run fwupdmgr to flash the firmware in our machines from within Linux. This includes almost any firmware, even add-on cards.

On my personal systems, I simply ignored the UEFI problem and kept enabling Legacy BIOS on any fresh new machine I would obtain so I could boot my Linux OS without giving it a second thought.

Then, 2020 came, and a brand new laptop showed up with UEFI only. No legacy booting of any kind (except on external USB sticks). Months later, a new portable Xeon-based workstation made its way into our home, and again that beast would only do UEFI.

I was stuck with a master boot record (MBR) formatted SSD (Legacy BIOS) and a machine that would only boot in UEFI mode. Being a tinkerer and a Linux user, I set out to research the issue, and the solution turned out to be not too difficult and would only require about five minutes once you’ve determined what to do.

A word of warning and some caveats

In finding the «right procedure» for my physical systems, I corrupted the test virtual machine I was using a few times. I also corrupted one of my laptop systems once, but I had a full image of my SSD thanks to CloneZilla. Here’s some advice:

• Make a full image-level backup of your system before you proceed. You’ll be touching your disks, and the tools used to make it easy to delete something without confirmation. You could use CloneZilla, AOMEI Partition Assistant, dd , or even Norton Ghost to do that. There are dozens of tools that do the job just fine.
• This procedure works even if you have a dual-boot machine. It works with Logical Volume Manager (LVM), plain partitions, and also with Linux Unified Key Setup (LUKS) or any combination thereof. You simply need to be careful and adapt the instructions to your configuration.
• Doing this procedure requires that you put your beloved SSD into a machine that can do both boot modes: Legacy BIOS and UEFI. If you attempt the procedure on a BIOS-only device, you’ll have to wait until you move your HDD or SSD to a UEFI machine to know it worked.
• You don’t have to physically move your SSD to another machine. You could simply clone the old MBR-formatted SSD onto a new SSD in another machine and work from there. You’ll change the structure of the partitions on your disk. Whether it is a temporary device or a new SSD in a new laptop is entirely up to you.
• In the unfortunate case that you don’t have any disk space you can free up easily on your SSD, there are still ways to operate. The last few hundred MBs of your LVM PV (Physical Volume) could be removed from its PEs and the LVM PV be resized to make room for the EFI partition. I won’t describe this here, but you’ll find some references at the end of the article. Another option is to take the opportunity to buy a slightly larger SSD and restore your Linux system onto it so you have some free space.
• Work through the process slowly and don’t hesitate to ask questions online if you need help. There are dozens of Linux user groups out there who will help you if you are stuck.
• This article was written on a freshly reinstalled laptop system with Fedora 33 but applies to many different configurations.
• Do not try this if you use B-tree file system (BTRFS) with Fedora 33. I could not make it work after converting my disk to GUID Partition Table (GPT) when I used BTRFS.

Am I using Legacy BIOS?

There are two good indicators of a machine booted in Legacy BIOS.

1) Your boot disk has DOS/MBR partitioning:

2) Your Linux kernel does not have EFI variables:

On a UEFI-mode machine, the above yields output similar to this:

Inspecting the boot disk and deciding on a strategy

From the above, I discovered that my boot disk is /dev/sda . Take a closer look with parted :

From the above, you see that only two partitions are present. The first partition is a small 1GiB partition, formatted as ext4 and it holds the kernels. The second partition is a different beast and is using LVM. As much as I’ve been happy with LVM on my Linux systems, I’ll not touch it for the moment.

More about automation

Consequently, I will use the space occupied by the first partition to make room for GPT and UEFI.

Please note that if you’re using LUKS or LVM, the conversion to UEFI procedure might also be safer if you use the boot partition and its space.

If you picked up BTRFS (the default in Fedora 33), this might not work for you, and my initial attempt failed to boot right after converting the disk to GPT.

If your boot partition is smaller than 1G and all space is occupied by partitions, it may not be safe to make /boot smaller than 512-600Mib. You might not have enough space to proceed, and perhaps now might be a good time to get a slightly larger SSD onto which you could clone your system.

My name is /dev/sda1

The boot partition on this machine is 1Gib in size and has enough free space for us to proceed:

First, resize the filesystem to 512M:

Umount it first (You can, since Linux only mounts /boot as a convenience):

The ext4 filesystem got resized, but the partition is still 1Gib in size. You will resize it next. You will shrink the partition to a size slightly over that of the /boot file system to be safe from rounding errors. Shrink it to 700Mib, which will leave about 300Mib free. Since the filesystem inside that partition is now 512Mib, it is safe to shrink the partition from 1024Mib to 700Mib.

Next, extend the filesystem back to the full partition size (700Mib):

The resize operation concludes with growing the ext4 filesystem from 512Mib back to the size of the underlying partition, which is 700Mib.

I could also have used Gparted to monitor the progress of the previous steps. Here’s a screenshot of the initial situation:

Источник