Шифрованный efi системный что это
Перейти к содержимому

Шифрованный efi системный что это

  • автор:

Что такое системный раздел EFI? Вы можете удалить это?

По большей части удаление раздела в разделе «Управление дисками» является довольно простой задачей. Вы просто выбираете нужный том в разделе «Управление дисками» и нажимаете «Удалить том» — однако для системного раздела EFI в Windows 10 / 8.1 / 8/7 / XP / Vista эта функция обычно недоступна, если она вообще видна , И для этого есть веская причина.

Что такое системный раздел EFI?

Системный раздел EFI — это небольшой раздел в формате FAT 32 на устройстве хранения данных, который используется на компьютерах, придерживающихся Unified Extensible Firmware Interface. Он автоматически генерируется при установке вашей ОС, будь то Windows или Mac OS. При загрузке ПК прошивка UEFI загружает необходимые файлы, хранящиеся в ESP, для запуска установленной операционной системы, а также различные утилиты, необходимые для запуска вашей машины. Системный раздел EFI содержит загрузчики, драйверы устройств, системные утилиты и некоторые ключевые файлы данных, которые абсолютно необходимы для загрузки Windows.

По сути, это означает, что удаление системного раздела EFI сделает установленную ОС не загружаемой. По этой причине системный раздел EFI обычно защищен каким-либо образом — во многих случаях он недоступен или не виден, если вы его специально не ищете, или заблокирован операционными системами Windows для предотвращения случайного удаления.

Итак, как мы установили, системный раздел EFI необходим для функционирования вашей ОС. В обычных условиях у пользователя не должно быть причин удалять его или каким-либо образом взаимодействовать с ним. Это очень маленький раздел, содержащий не более 100-200 МБ данных, поэтому его удаление не освободит значительный объем дискового пространства. Если вам не хватает места на диске, есть другие шаги, которые вы можете предпринять, чтобы освободить некоторые из них, которые не повредят вашу ОС после ремонта .

Кроме того, этот раздел автоматически удаляется при удалении вашей ОС, так что вам все равно не о чем беспокоиться.

Вы должны удалить системный раздел EFI?

Итак, еще раз повторим: системный раздел EFI является неотъемлемой частью вашей ОС. Технически вы можете удалить его, но на практике на самом деле нет никаких обстоятельств, при которых это было бы необходимо, или даже удаленно рекомендуется.

Как удалить EFI раздел жесткого диска

Как удалить EFI раздел жесткого диска

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

Удаление EFI раздела

Попытки удалить данный раздел с Вашего системного диска приведут к выходу из строя операционной системы!

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

  • Запустится отдельное окно командной строки с программой diskpart.
  • В нем вводим команду для показа всех известных системе жестких дисков:

    list disk

    Выбираем нужный диск:

    select disk [НОМЕР ДИСКА]
    list part

    Ориентируясь по полученному списку разделов, выбираем нужный раздел EFI:

    select part [НОМЕР РАЗДЕЛА]
    del part override

    EFI system partition (Русский)

    Состояние перевода: На этой странице представлен перевод статьи EFI system partition. Дата последней синхронизации: 12 октября 2023. Вы можете помочь синхронизировать перевод, если в английской версии произошли изменения.

    • Unified Extensible Firmware Interface (Русский)
    • Загрузчик

    Системный раздел EFI (EFI system partition, также называемый ESP или EFISYS) — это независимый от ОС раздел, который служит местом хранения загрузчиков UEFI и приложений, которые будут запускаться прошивкой UEFI. Он необходим для загрузки системы в режиме UEFI.

    Проверка существования раздела

    Если вы устанавливаете Arch Linux на компьютер с поддержкой UEFI и предустановленной ОС, например, Windows 10, то вполне вероятно, что у вас уже есть системный раздел EFI.

    Чтобы посмотреть схему разделов диска и системный раздел, запустите fdisk от имени root, указав диск, с которого вы хотите загрузиться:

    # fdisk -l /dev/sdx 

    Эта команда выведет:

    • Таблицу разделов диска: GPT будет обозначен как Тип метки диска: gpt , а MBR — как Тип метки диска: dos .
    • Список разделов на диске: поищите в списке системный раздел EFI, он обычно имеет размер не менее 100 МиБ и тип EFI System или EFI (FAT-12/16/32) . Чтобы убедиться, что это ESP, смонтируйте его и проверьте, содержит ли он каталог с именем EFI ; если да, то это точно ESP.

    Совет: Чтобы узнать, является ли файловая система FAT12, FAT16 или FAT32, смотрите FAT (Русский)#Определение типа FAT.

    Важно: Если в системе уже есть другие установленные операционные системы, не форматируйте существующий системный раздел EFI, так как форматирование сотрёт загрузчики других систем. Используйте существующий раздел как есть и просто монтируйте его.

    Если вы нашли существующий системный раздел EFI, просто переходите к разделу #Монтирование раздела. Если раздел не нашёлся, его нужно создать: #Создание раздела.

    Создание раздела

    В следующих двух разделах показано, как создать системный раздел EFI (ESP).

    Важно: Системный раздел EFI должен быть физическим разделом в основной таблице разделов диска, не под LVM или программным RAID и т. д.

    Раздел должен иметь достаточно большой размер для хранения загрузчиков и других файлов, необходимых для загрузки.

    Для предотвращения проблем совместимости с другими операционными системами[1] и дисками Advanced Format[2] рекомендуется делать его не менее 300 МиБ.

    • Для ранних и/или несовершенных реализаций UEFI может потребоваться размер не менее 512 МиБ.[3]
    • Для форматирования в FAT32 размер раздела должен быть не менее 36 МиБ при размере сектора 512 байт и не менее 260 МиБ при размере сектора 4096 байт.[4]
    • Если вы планируете устанавливать несколько ядер и при этом монтировать системный раздел EFI как /boot или использовать unified kernel image, используйте раздел размером около 1 ГиБ, чтобы быть уверенным в том, что всё поместится.
    • Если ни одна из этих проблем не актуальна, размер раздела может составлять всего 2 МиБ, хотя тогда в него не поместится ничего кроме загрузчика.

    Разметка дисков GPT

    Системный раздел EFI в таблице разделов GUID идентифицируется с помощью GUID типа раздела C12A7328-F81F-11D2-BA4B-00A0C93EC93B .

    Выберите один из следующих способов создания ESP для диска GPT с разделами:

    • fdisk: Создайте раздел и измените тип раздела на EFI System .
    • gdisk: Создайте раздел с типом раздела EF00 .
    • GNU Parted: Создайте раздел fat32 и в Parted установите/активируйте флаг esp .

    После создания раздел нужно отформатировать; переходите к разделу #Форматирование раздела.

    Разметка дисков MBR

    • Некоторые прошивки могут не поддерживать загрузку UEFI/MBR из-за того, что она не поддерживается установкой Windows.
    • bootctl не поддерживает установку systemd-boot на MBR-диск; смотрите systemd issue 1125.

    Подробнее об ограничениях MBR и преимуществах GPT смотрите в разделе Разметка дисков#Выбор между GPT и MBR.

    Системный раздел EFI в главной загрузочной записи идентифицируется с помощью partition ID EF .

    Выберите один из следующих способов создания ESP для диска MBR с разделами:

    • fdisk: Создайте первичный раздел и измените тип раздела на ( EFI (FAT-12/16/32) .
    • GNU Parted: Создайте первичный раздел fat32 и в Parted установите/активируйте флаг esp .

    После создания раздел нужно отформатировать; переходите к разделу #Форматирование раздела.

    Форматирование раздела

    Спецификация UEFI предусматривает поддержку файловых систем FAT12, FAT16 и FAT32 (UEFI specification version 2.10, section 13.3.1.1), но производители могут по желанию добавить поддержку дополнительных файловых систем; например, прошивки компьютеров Apple Mac поддерживают файловую систему HFS+.

    Для предотвращения возможных проблем с другими операционными системами и поскольку в спецификации UEFI говорится, что UEFI «включает использование FAT32 для системного раздела и FAT12 или FAT16 для съёмных носителей»[5], рекомендуется использовать FAT32. Используйте утилиту mkfs.fat(8) из пакета dosfstools :

    # mkfs.fat -F 32 /dev/sdxY 

    Если вы получили сообщение WARNING: Not enough clusters for a 32 bit FAT! и у вас нет возможности увеличить размер раздела, уменьшите размер кластера с помощью команды mkfs.fat -s2 -F32 . или -s1 ; иначе раздел может оказаться нечитаемым для UEFI. Поддерживаемые размеры кластера можно посмотреть в mkfs.fat(8) .

    Для разделов размером менее 32 МиБ использовать FAT32 не получится. В этом случае отформатируйте его в FAT16 или даже FAT12. Например, ESP размером 2 МиБ будет поддерживать только FAT12:

    # mkfs.fat -F 12 /dev/sdxY 

    Монтирование раздела

    Ядра, файлы initramfs и, в большинстве случаев, микрокод процессора должны быть доступны загрузчику или самому UEFI для успешной загрузки системы. Таким образом, если вы хотите сохранить простоту установки, выбор загрузчика ограничивает варианты выбора точки монтирования для системного раздела EFI.

    Примечание: Если ESP монтируется не в /boot , то при обновлении ядра не полагайтесь на механизм автоматического монтирования systemd (в том числе systemd-gpt-auto-generator). Всегда монтируйте его вручную перед любым обновлением системы или ядра, иначе вы не сможете смонтировать его после обновления из-за недоступности нужных модулей ядра, что заблокирует вас в текущем запущенном ядре и приведёт к невозможности обновить копию ядра на ESP.

    /etc/modules-load.d/vfat.conf
    vfat nls_cp437 nls_ascii

    Типичные точки монтирования

    Есть три основных варианта монтирования системного раздела EFI.

    • Монтирование ESP в /boot :
      • Это облегчает обслуживание и администрирование системы, поскольку /boot является путём по умолчанию, в который пакеты микрокода размещают файлы initramfs микрокода процессора, и в который mkinitcpio помещает ядра и образы initramfs.
      • Это обеспечивает доступ к вышеупомянутым файлам для большинства загрузчиков, поскольку не все из них могут обращаться к файлам на других томах.
      • Это предотвращает установку прав доступа и/или расширенных атрибутов отдельным файлам, поскольку FAT устанавливает глобальные права доступа во время монтирования.
      • Это увеличивает необходимый размер раздела, поскольку к файлам, обычно находящимся в /boot , добавляются файлы, связанные с EFI.
      • В случае двойной загрузки это приводит к тому, что специфичные для ОС загрузочные файлы могут подвергаться потенциально опасным манипуляциям со стороны других ОС.
      • Это делает шифрование /boot невозможным, так как файлы, связанные с EFI, должны быть доступны прошивке.
      • Это отделяет файлы, специфичные для ОС, от файлов, связанных с EFI.
      • Это позволяет избежать увеличения размера ESP за счёт отказа от размещения в нём файлов, устанавливаемых в /boot : на ESP будут храниться только исполняемые файлы EFI (загрузчик (и, опционально, драйверы) и/или unified kernel image), что экономит место на разделе.
      • Позволяет использовать специфические для Linux права доступа на уровне файловой системы для файлов, находящихся в /boot , без специфичных для FAT ограничений.
      • Это позволяет монтировать ESP отдельно по необходимости, например, только во время обновления загрузчика.
      • При шифровании системы с соответствующей настройкой это позволяет оставить незашифрованными лишь несколько минимально необходимых файлов, а /boot будет защищён: это может быть полезно для unified kernel image или загрузчиков, имеющих драйверы файловой системы, способные прочитать ядро и прочие файлы из другого места.
      • Монтирование в /efi является заменой[6] для ранее распространённой и ныне не рекомендуемой точки монтирования /boot/efi .
      • Каталог /efi изначально отсутствует; его нужно предварительно создать.

      Альтернативные точки монтирования

      Если вы не используете #Типичные точки монтирования, вам будет нужно самостоятельно скопировать файлы, необходимые для загрузки, в ESP (далее обозначается как esp ).

      # mkdir -p esp/EFI/arch # cp -a /boot/vmlinuz-linux esp/EFI/arch/ # cp -a /boot/initramfs-linux.img esp/EFI/arch/ # cp -a /boot/initramfs-linux-fallback.img esp/EFI/arch/

      Примечание: Вам также может понадобиться скопировать микрокод.

      Кроме того, вам нужно будет поддерживать файлы на ESP в актуальном состоянии при последующих обновлениях ядра. Несоблюдение этого требования может привести к незагружаемой системе. В следующих разделах обсуждаются несколько механизмов для автоматизации этого процесса.

      Использование bind монтирования

      Вместо того, чтобы монтировать целиком ESP в /boot , вы можете подключить отдельный каталог ESP к /boot с помощью bind-монтирования (смотрите mount(8) ). Это позволяет pacman обновлять ядро напрямую, а вам — организовать файлы в ESP по своему вкусу.

      Примечание: Для этого требуется, чтобы ядро и загрузчик были совместимы с FAT32. Это не является проблемой для обычной установки Arch, но может быть проблематичным для других дистрибутивов (а именно тех, которые требуют символических ссылок в /boot/ ). Смотрите сообщение на форуме [7].

      Как описано в начале раздела, скопируйте все загрузочные файлы в каталог вашего ESP, но смонтируйте ESP вне /boot . Затем выполните bind-монтирование каталога:

      # mount --bind esp/EFI/arch/ /boot

      Если всё хорошо, отредактируйте свой Fstab, чтобы сделать изменение постоянным:

      /etc/fstab
      esp/EFI/arch /boot none defaults,bind 0 0
      Использование systemd

      Systemd поддерживает задачи, запускаемые по событию. В данном конкретном случае возможность обнаружения изменения пути используется для синхронизации файлов ядра EFISTUB и initramfs, когда они обновляются в /boot/ . Файл, который проверяется на изменения, это initramfs-linux-fallback.img , так как это последний файл, который собирает mkinitcpio, что позволяет убедиться, что все нужные файлы были собраны перед началом копирования. Файлы path и service, которые должны быть созданы, следующие:

      /etc/systemd/system/efistub-update.path
      [Unit] Description=Copy EFISTUB Kernel to EFI system partition [Path] PathChanged=/boot/initramfs-linux-fallback.img [Install] WantedBy=multi-user.target WantedBy=system-update.target
      /etc/systemd/system/efistub-update.service
      [Unit] Description=Copy EFISTUB Kernel to EFI system partition [Service] Type=oneshot ExecStart=/usr/bin/cp -af /boot/vmlinuz-linux esp/EFI/arch/ ExecStart=/usr/bin/cp -af /boot/initramfs-linux.img esp/EFI/arch/ ExecStart=/usr/bin/cp -af /boot/initramfs-linux-fallback.img esp/EFI/arch/

      Затем запустите и включите efistub-update.path .

      Совет: При использовании Secure Boot с собственными ключами можно настроить службу на подпись образов с помощью sbsigntools :

      ExecStart=/usr/bin/sbsign --key /путь/к/db.key --cert /путь/к/db.crt --output esp/EFI/arch/vmlinuz-linux /boot/vmlinuz-linux
      Использование событий файловой системы

      События файловой системы можно использовать для запуска скрипта, синхронизирующего ядро EFISTUB после обновления ядра. Ниже приведён пример с использованием incron.

      /usr/local/bin/efistub-update
      #!/bin/sh cp -af /boot/vmlinuz-linux esp/EFI/arch/ cp -af /boot/initramfs-linux.img esp/EFI/arch/ cp -af /boot/initramfs-linux-fallback.img esp/EFI/arch/

      Примечание: Первый параметр /boot/initramfs-linux-fallback.img — файл, за которым ведётся наблюдение. Второй параметр IN_CLOSE_WRITE — отслеживаемое действие. Третий параметр /usr/local/bin/efistub-update — скрипт для выполнения.

      /etc/incron.d/efistub-update.conf
      /boot/initramfs-linux-fallback.img IN_CLOSE_WRITE /usr/local/bin/efistub-update
      Использование хука mkinitcpio

      Mkinitcpio может генерировать хук, для работы которого не нужен демон системного уровня. Он порождает фоновый процесс, который ожидает генерации vmlinuz , initramfs-linux.img и initramfs-linux-fallback.img перед копированием файлов.

      Добавьте efistub-update в список хуков в /etc/mkinitcpio.conf .

      /etc/initcpio/install/efistub-update

      #!/usr/bin/env bash build() < /usr/local/bin/efistub-copy $$ & >help()

      /usr/local/bin/efistub-copy
      #!/bin/sh if [ "$1" -gt 0 ] then while [ -e /proc/"$1" ] do sleep .5 done fi rsync -a /boot/ esp/ echo "Synced /boot with ESP"
      Использование предустановки mkinitcpio

      Поскольку предустановки в /etc/mkinitcpio.d/ поддерживают shell-скрипты, ядро и initramfs могут быть скопированы простым редактированием предустановок.

      Замена хука mkinitcpio

      Измените файл /etc/mkinitcpio.d/linux.preset :

      /etc/mkinitcpio.d/linux.preset
      # mkinitcpio preset file for the 'linux' package # Directory to install the kernel, the initramfs. ESP_DIR #ALL_config="/etc/mkinitcpio.conf" ALL_kver="$/vmlinuz-linux" [[ -e /boot/intel-ucode.img ]] && cp -af /boot/intel-ucode.img "$/" [[ -e /boot/amd-ucode.img ]] && cp -af /boot/amd-ucode.img "$/" PRESETS=('default' 'fallback') #default_config="/etc/mkinitcpio.conf" default_image="$/initramfs-linux.img" default_options="" #fallback_config="/etc/mkinitcpio.conf" fallback_image="$/initramfs-linux-fallback.img" fallback_options="-S autodetect"

      Для тестирования выполните:

      # rm /boot/initramfs-linux-fallback.img /boot/initramfs-linux.img # mv /boot/vmlinuz-linux esp/EFI/arch/ # mkinitcpio -p linux
      Другой пример
      /etc/mkinitcpio.d/linux.preset
      ESP_DIR #ALL_config="/etc/mkinitcpio.conf" ALL_kver="$ESP_DIR/vmlinuz-linux$suffix" PRESETS=('default') default_config="/etc/mkinitcpio.conf" default_image="$ESP_DIR/initramfs-linux$suffix.img"
      /etc/mkinitcpio.d/linux-zen.preset
      suffix='-zen' source /etc/mkinitcpio.d/linux.preset
      Использование хука pacman

      Последний вариант полагается на хуки pacman, которые запускаются в конце транзакции.

      Первый файл — это хук, который отслеживает соответствующие файлы и запускается, если они были изменены в прошедшей транзакции.

      /etc/pacman.d/hooks/999-kernel-efi-copy.hook
      [Trigger] Type = Path Operation = Install Operation = Upgrade Target = usr/lib/modules/*/vmlinuz Target = usr/lib/initcpio/* Target = boot/*-ucode.img [Action] Description = Copying linux and initramfs to EFI directory. When = PostTransaction Exec = /usr/local/bin/kernel-efi-copy.sh

      Второй файл — собственно копирующий скрипт. Создайте его и сделайте исполняемым:

      /usr/local/bin/kernel-efi-copy.sh
      #!/bin/sh # # Copy kernel and initramfs images to EFI directory # ESP_DIR for file in /boot/vmlinuz* do cp -af "$file" "$ESP_DIR/$(basename "$file").efi" [ $? -ne 0 ] && exit 1 done for file in /boot/initramfs* do cp -af "$file" "$ESP_DIR/" [ $? -ne 0 ] && exit 1 done [ -e /boot/intel-ucode.img ] && cp -af /boot/intel-ucode.img "$ESP_DIR/" [ -e /boot/amd-ucode.img ] && cp -af /boot/amd-ucode.img "$ESP_DIR/" exit 0

      Решение проблем

      ESP в программном RAID1

      Можно сделать ESP частью массива RAID1, но при этом возникает риск повреждения данных, и при создании ESP необходимо принять дополнительные меры. Смотрите [8], [9] и UEFI booting and RAID1 для подробностей.

      Ключевым моментом является использование параметра —metadata 1.0 , чтобы сохранить метаданные RAID в конце раздела, иначе прошивка не сможет получить к ним доступ:

      # mdadm --create --verbose --level=1 --metadata=1.0 --raid-devices=2 /dev/md/ESP /dev/sdaX /dev/sdbY 

      Прошивка не видит каталог EFI

      Если вы задаёте файловой системе FAT имя тома (то есть метку файловой системы), убедитесь, что оно не совпадает с именем EFI . Это может вызвать ошибку в некоторых прошивках (из-за совпадения имени тома с именем каталога EFI), которая заставит прошивку вести себя так, как будто каталог EFI не существует.

      Смотрите также

      • Системный раздел EFI и поведение загрузки по умолчанию
      • Multi Boot Linux With One Boot Partition | John Ramsden [устаревшая ссылка 2023-10-29 ⓘ]

      Как и можно ли удалить шифрованный раздел EFI и раздел восстановления с «пустого» диска?

      Привет. Имеется 2 диска, на обоих стояли Win, но было принято решение оставить Win только на одном: первом а на втором удалить -> Спросонья залез в diskmgmt и просто удалил основной раздел на 2м диске, однако там остались разделы восстановления и шифрованный системный Efi. Возможность удаления первого из diskmgmt отсутствует, при попытке удаления раздела Efi пишет, что данный раздел создан не Win, и может использоваться другой системой.
      Если лезть в powershell и пытаться удалить раздел Efi там — пишет, что удаление активного системного диска невозможно.
      Вот и вопрос — как всетаки очистить полностью второй хард, и в то же время не поломать первый?) И вообще правильно ли я действую?)

      • Вопрос задан более трёх лет назад
      • 17509 просмотров

      1 комментарий

      Простой 1 комментарий

      EFI — это не шифрованный раздел, там обычная FAT32 или FAT16, просто тип раздела для него выставляется в EFI. Этот раздел используется UEFI BIOS для поиска загрузчика ОС.
      В винде для EFI раздела можно назначить букву диска через diskpart и посмотреть его содержимое проводником.
      Для того что бы UEFI BIOS мог найти загрузчик, он должен лежать в строго определенных местах (каталогах), где BIOS будет его искать.
      Не запрещено создавать другие файлы и каталоги на этом разделе и как-то их использовать. Но обычно этого делать не стоит.

      Решения вопроса 1

      Jump

      АртемЪ @Jump Куратор тега Windows
      Системный администратор со стажем.

      diskpart
      list disk — находим номер нужного диска
      sel disk номер — выбираем диск с нужным номером
      clean
      Закрываем командную строку и идем в диспетчер дисков, там инициализируем абсолютно пустой диск.

      Только внимательнее будьте, не перепутайте диски.

      Ответ написан более трёх лет назад
      Нравится 8 16 комментариев
      Max115 @Max115 Автор вопроса

      я так и делаю через powershell, однако при попытке удалить или очистить диск — мне выходит сообщение о том, что удаление активного системного раздела невозможно. но при этом я загружаюсь с первого харда, а разделы пытаюсь удалить со второго, вот и непонятно, почему системный раздел второго харда считается активным.

      Jump

      АртемЪ @Jump Куратор тега Windows

      мне выходит сообщение о том, что удаление активного системного раздела невозможно.

      Ну разумеется, самозащита у системы есть.

      но при этом я загружаюсь с первого харда, а разделы пытаюсь удалить со второго,

      Нет, судя по всему вы загружаетесь со второго HDD, а на первом у вас операционная система.

      вот и непонятно, почему системный раздел второго харда считается активным.

      Потому что на нем размещен загрузчик.
      Max115 @Max115 Автор вопроса

      АртемЪ, возможно это уже совсем примитив, но как в таком случае загрузиться с первого харда? При загрузке системы я выбираю именно первый хард, вернее выбирал — после удаления основного раздела второго харда его загрузка в качестве опции не выходит. Я просто загружаю Win. В diskmgmt есть Диск 0 — с единственным разделом в котором перечислены: Загрузка ,Файл подкачки, Аварийный дамп, Основной раздел. И Диск 1 — в котором перечислены: Восстановление, Шифрованный Efi системный, Незанятое пространство (бывший основной раздел, который я и удалил).

      Max115, Для проверки того используется ли второй диск для загрузки просто вытащите его из компа (достаточно отсоединить SATA кабель или кабель питания) и загрузиться. Если загрузка ОС пройдет нормально, то можно смело стирать диск полностью.

      Jump

      АртемЪ @Jump Куратор тега Windows

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

      Сделать активным первый диск.
      После этого у вас перестанет загружаться ОС.
      Исправить загрузку и работать дальше.

      Max115 @Max115 Автор вопроса

      АртемЪ, хорошо, действительно — физическое отключение второго диска привело к тому, что система не загружается. Не подскажите ли в таком случае как исправить загрузку? Надо смотреть информацию о восстановлении загрузочного раздела с загрузочной флешки, или совсем не то?

      Max115 @Max115 Автор вопроса
      АртемЪ, bootrec.exe /fixboot?

      Jump

      АртемЪ @Jump Куратор тега Windows

      Max115, Да, для начала можете просто загрузиться с установочного диска в режиме восстановления- система сама предложит устранить проблемы.

      Если автоматом не получиться — Shift+F10 и уже пробовать с командной строки вручную.

      Jump

      АртемЪ @Jump Куратор тега Windows
      У вас на нужном диске, на который загрузку переносите есть EFI раздел?
      Max115 @Max115 Автор вопроса

      АртемЪ, эх, после неудачных попыток восстановления выполнил последовательность bootrec.exe из трех задач «bootrec.exe / rebuildbcd», «bootrec.exe / fixmbr», «bootrec.exe / fixboot» (только bootrec.exe / fixboot давал отказ в доступе) — после этого даже загрузочная флешка стала выдавать ошибку))
      Пишет что потерян файл.

      file: /EFI/Microsoft/Boot/BCD
      Error: 0xc000000f

      Jump

      АртемЪ @Jump Куратор тега Windows
      Max115, Вы раздел перенесли на нужный диск?
      Max115 @Max115 Автор вопроса

      АртемЪ, я следующим образом сделал: механически отключил второй диск, загрузился с LiveUSB, провел попытку восстановления через bootrec.exe — после этого перезагрузил компьютер и получил то, что получил)
      удивляет еще и реакция LiveUSB, которая теперь сразу выдает ошибку, то есть я и переустановить систему с нее не могу)

      Jump

      АртемЪ @Jump Куратор тега Windows

      Не совсем понятно — что значит LiveUSB выдает ошибку? На каком этапе, какую ошибку? Она то там ни при чем.

      Система если ставите второй диск грузиться?

      Max115 @Max115 Автор вопроса

      АртемЪ, на счет раздела EFI на первом диске — вроде нет такого. Система показывала единый том в котором были перечислены: Загрузка, Файл подкачки, Аварийный дамп, Основной раздел. Больше ничего.

      Max115 @Max115 Автор вопроса

      АртемЪ, при подключении второго диска система грузится.
      LiveUSB при загрузке с биоса выдает ошибку похожую на синий экран смерти (картинку не получается прикрепить):
      Recovery
      Your PC needs to be repaired
      The boot configuration data for Your PC missing or contains error

      file: /EFI/Microsoft/Boot/BCD
      Error: 0xc000000f

      Max115 @Max115 Автор вопроса

      АртемЪ, спасибо, проблему решил. Помогли на соседней ветке, но за потраченное время еще раз благодарю.

  • Добавить комментарий

    Ваш адрес email не будет опубликован. Обязательные поля помечены *