Рабочая станция VMware с использованием физического диска EFI

Question

Я пытаюсь настроить виртуальную машину VMware под хостом Windows 10.

В настоящее время у меня есть 1 жесткий диск, разделенный на 2 раздела, в настоящее время я использую Ubuntu с двойной загрузкой.

Я хотел бы смонтировать Ubuntu в качестве гостя на хосте Windows.

Я пытался настроить раздел Ubuntu с помощью параметра "Физический диск" в VMware (я пробовал IDE, SCSI, Sata). Если я скажу VMware использовать весь диск, я получу сообщение "текущий диск используется". Если я выберу только соответствующие разделы Linux, появится сообщение "Не удается найти операционную систему".

Что странно, мой раздел Linux отображается как "система Efi" в столбце "Файловая система", в то время как я думал, что в "Файловой системе" он должен был сказать "Linux". Должен ли я сначала изменить файловую систему этого раздела на Linux вместо Efi? (Как бы я это сделал?)

VMware должна позволять мне запускать раздел Ubuntu в качестве гостя, даже если он находится на том же жестком диске, что и хост, верно?

Изменить: чтобы уточнить, выше информация сообщается VMware-Workstation.

Однако под Ubuntu Gparted мои разделы выглядят так:

Мой текущий жесткий диск SSD в настоящее время настроен таким образом (в соответствии с Linux GParted)

• /dev/nvme0n1p1 ntfs (diag)
• /dev/nvme0n1p2 fat32 (boot, esp)
• /dev/nvme0n1p3 unknown (msftres) [зарезервированный раздел Microsoft, какой бы он ни был]
• /dev/nvme0n1p4 ntfs (msftdata) [Это раздел Windows 10]
• /dev/nvme0n1p5 ext4 (boot, esp) [Это мой раздел Ubuntu]
• /dev/nvme0n1p6 linux-swap
• /dev/nvme0n1p7 ntfs (скрытый, diag)

GParted также сообщает, что точка монтирования / находится на nvme0n1p5 и точка монтирования / boot / efi на nvme0n1p2.

[теперь я запутался, загрузился ли мой компьютер с Ubuntu с nvme0n1p5 (с флагом загрузки) или nvme0n1p2 (с точкой монтирования /boot /efi)?]

В любом случае, я пытался подключить оба раздела к жесткому диску с физическим диском в Windows 10 VMWare-Workstation, но машина по-прежнему не загружает гостевую Ubuntu.

Я могу выполнить двойную загрузку (переключив "порядок жестких дисков" в BIOS - [хотя есть только один жесткий диск!]) но я хотел бы загрузить и запустить раздел Ubuntu из Windows.

Изменить 2:

Я думаю, что я мог бы понять проблему немного больше:

1. при первой загрузке я выбираю Windows 10 EFI в качестве варианта загрузки
2. в windows я настраиваю виртуальную машину для запуска второго раздела на том же жестком диске, который в данный момент работает как хост
3. но для загрузки второго раздела я должен указать программе настройки виртуальной машины запустить тот же менеджер загрузки EFI, что и (1)
4. не удается запустить менеджер загрузки EFI (он используется?) и бросает меня во внутреннюю оболочку EFI
5. из оболочки EFI я могу выбрать файловую систему и перейти в /efi /boot и посмотреть там некоторые файлы .efi, но я не знаю, как загрузиться с этих файлов .efi.

Может кто-нибудь сказать мне, как загрузить файл .efi из внутренней оболочки EFI?

Answer 1

Некоторые из них уже были рассмотрены в комментариях, и я не эксперт по продуктам VMware, но:

Ваша первая проблема - это код типа раздела в /dev/nvme0n1p5 . Согласно вашему parted резюме, этот раздел имеет установленный флаг «boot, esp». (По причинам, которые могут быть отклонением от нормы, "boot" и "esp" являются избыточными именами флагов, которые ссылаются на одно и то же, поэтому они всегда появляются вместе в последних версиях parted .) В parted "флаги" на GPT-дисках могут быть либо атрибутами раздела, либо кодами типа раздела, а флаг «boot, esp» является кодом типа для системного раздела EFI (ESP). Этот флаг НЕ должен быть установлен в корневом разделе (/) Linux - или в любом другом разделе только для Linux. Как объясняется на странице Википедии, на которую я ссылался, ESP - это раздел FAT, содержащий загрузчики и связанные файлы для всех операционных систем. Ваш /dev/nvme0n1p5 должен использовать код типа данных файловой системы Linux, который при parted идентифицируется как отсутствие флагов типа кода раздела в разделе с файловой системой Linux.

Как минимум, вам нужно предоставить VMware доступ как к /dev/nvme0n1p2 и к /dev/nvme0n1p5 , но вы также можете предоставить доступ к /dev/nvme0n1p6 , поскольку это пространство подкачки Linux. Исправление этой проблемы с доступом к разделу не исправит вашу общую проблему, но, вероятно, будет необходимым предварительным условием.

В остальном я настоятельно рекомендую вам прочитать немного о том, как загружается компьютер на основе EFI. В частности, прочитайте, по крайней мере, один, а предпочтительно все три, из следующего:

• Запись Адама Уильямсона в блоге о том, как работает EFI. На этой странице описывается теория загрузки в режиме EFI.
• Вопрос и ответы о различиях между загрузкой BIOS и EFI на Superuser.com - это обеспечивает основы предыдущего, но является более кратким.
• Моя страница о загрузчиках EFI для Linux - на этой странице описывается выбор загрузчика EFI для систем Linux. Прочитайте вводную страницу и подстраницы о принципах и установке загрузчика EFI; Вы можете пропустить большинство страниц на определенных загрузчиках, если вы не заинтересованы в установке чего-то нестандартного.

Внутренняя оболочка EFI, которую вы описываете, похожа на приглашение DOS, окно командной строки в Windows или оболочку Bash в Linux. Вы можете использовать такие команды, как cd для изменения каталогов, ls или dir для просмотра файлов и т. Д .; большинство из этих команд заимствованы из DOS/Windows или Unix. Программы EFI, включая загрузчики EFI, имеют расширения .efi , и вы запускаете их, набирая их имена, как в:

bootloader.efi

Ubuntu устанавливает свой загрузчик EFI как EFI\ubuntu\grubx64.efi , хотя обычно он запускается через предварительный загрузчик shimx64.efi . Shim подписан ключом безопасной загрузки Microsoft и расширяет подсистему безопасной загрузки компьютера, чтобы GRUB и ядро Linux могли загружаться. Вам нужно будет запустить через shimx64.efi если ваша виртуализированная среда настроена с включенной безопасной загрузкой. Если нет, вы можете запустить либо shimx64.efi либо grubx64.efi .

Одна сложность заключается в том, что GRUB может захлебнуться диском, который не соответствует виду исходного диска, то есть, если реальный раздел 5 окажется разделом 2, GRUB может вылететь и отказаться работать. Если это произойдет, я рекомендую перейти на другой загрузчик хотя бы для одной среды (реальной или виртуальной). Если в каждой среде используется собственный загрузчик, их конфигурации могут существенно отличаться, и эти две среды не будут наступать друг на друга. Кроме того, некоторые загрузчики не заботятся об измененных номерах разделов. Это верно , например , для моего менеджера загрузки rEFInd . Я хотел бы подчеркнуть, однако, что я не знаю, будет ли GRUB отслаиваться. Его конфигурационный файл обычно содержит ссылки на номера разделов (что предполагает, что он может отслаиваться), но он также включает команды "поиска", которые могут переопределять те (которые предполагают, что это может быть в порядке). Кроме того, я не знаю, как VMware управляет отображением разделов; они могут хранить одинаковые номера разделов, и в этом случае проблем не должно быть.

Другой вопрос заключается в том, позволит ли ОС хоста сопоставлять ESP, так как он может использоваться или запрещен для этого. В этом случае вам может потребоваться создать виртуальный диск или другой раздел, который будет использоваться в качестве ESP для виртуальной среды. Затем вы можете скопировать загрузчик из реального ESP в виртуальный или установить там другой загрузчик.

Наконец, как описано в рекомендациях, которые я рекомендовал, компьютеры на основе EFI полагаются на резидентные данные NVRAM для определения местоположения загрузчика. Большинство программ виртуализации создает "поддельные" данные NVRAM, поэтому виртуальная машина не будет загружаться нормально, если вы не создадите свежие записи NVRAM, указывающие на загрузчик. Вы можете использовать оболочку EFI для запуска вашей ОС один раз, но тогда вам нужно будет зарегистрировать загрузчик на ВМ. В Ubuntu вы бы использовали efibootmgr для этого:

sudo efibootmgr -c -d /dev/sda -p 1 -l \\EFI\\ubuntu\\grubx64.efi -L ubuntu

Этот пример записывает \EFI\ubuntu\grubx64.efi в /dev/sda1 Ubuntu в качестве загрузчика. Вы должны изменить детали, необходимые для вашей настройки. Обратите внимание, что идентификаторы дисков и разделов - это идентификаторы на виртуальной машине, а не в среде хоста.

Одно предостережение в том, что некоторые виртуальные машины "забывают" свои записи NVRAM, когда вы выключаете их. Это верно для VirtualBox, например. Я понятия не имею, если VMware делает лучше. Если нет, вам может потребоваться скопировать загрузчик в резервное имя файла (EFI\BOOT\bootx64.efi) на ESP. Этот подход более подробно описан на моей странице о загрузчиках EFI, а также в блоге Адама Уильямсона.