Учитывая ваши текущие настройки
sudo vim "$(v)"
будет использовать подстановку команд для запуска вашего псевдонима v
и вставки его вывода в командную строку, которая должна быть запущена перед его выполнением, поэтому в конце он запустит sudo vim /usr/bin/dict
. Кавычки гарантируют, что он выводится как один аргумент, а $(...)
обрабатывает запуск команды и захват ее вывода.
Это будет работать только в вашей интерактивной оболочке, так как псевдонимы больше нигде не используются. Если вы хотите получить к нему доступ из скрипта, вы можете создать небольшой скрипт где-нибудь в своей переменной PATH
с той же командой внутри него.
Вы пометили этот bash , но затем показали выдержку из .zshrc
, поэтому обратите внимание, что у zsh есть " глобальные псевдонимы ", которые раскрываются где угодно:
alias -g v='"$(xclip -selection c -o)"'
, а затем просто запустите sudo vim v
, и это произойдет бесплатно. Глобальные псевдонимы почти всегда доставляют больше хлопот, чем пользы, поэтому я не рекомендую этого, но в зависимости от ваших моделей использования некоторые глобальные псевдонимы могут оказаться удобными (Я бы порекомендовал более длинный и более необычное имя, если вы сделаете :, поставив несколько нечетных знаков препинания, это может помочь избежать его ошибочного запуска, поэтому alias -g v#...
или @v
или ^v
или что-то в этом роде ).
Хорошо, сначала немного справочной информации:
ОС, загружаемая в собственном режиме UEFI -, будет иметь возможность доступа к конфигурации загрузки, пока ОС работает как набор загрузочных переменных UEFI NVRAM; это часть спецификации UEFI. В Linux наиболее удобным для пользователя способом -является команда efibootmgr
; в Windows команда bcdedit
может получить доступ к загрузочным переменным UEFI при запуске от имени администратора. Чтобы просмотреть загрузочные переменные, запустите efibootmgr -v
от имени пользователя root в Linux или bcdedit /enum FIRMWARE
от имени администратора в Windows.
Некоторые версии встроенного ПО UEFI не предлагают полный доступ к загрузочным переменным UEFI в меню конфигурации «BIOS», но требуют упрощенного BIOS -, например выбора загрузочного диска. Это может вас укусить, когда вы пытаетесь создать расширенные сценарии с множественной загрузкой -. Вам нужно знать о существовании загрузочных переменных UEFI и быть готовым отредактировать их, если различные установщики ошибутся в них.
Если у вас есть NVMe SSD, ваша системная прошивка должна специально поддерживать загрузку с него, поскольку NVMe SSD совсем не похож на диск SATA. Некоторые прошивки UEFI поддерживают загрузку только с устройства NVMe в режиме UEFI. Обычно это не препятствует доступу ОС к устройству NVMe, если для него доступен драйвер NVMe.
Большинство установщиков ОС, поддерживающих UEFI -, определят режим загрузки установщика ОС в (BIOS или UEFI )и установят соответствующий тип загрузчика без лишних вопросов. Kali, по-видимому, может предложить «форсирование UEFI», то есть установку загрузчика UEFI, даже если установщик загружается в стиле BIOS -.
При загрузке в стиле BIOS -,MBR диска может быть занят только одним загрузчиком/менеджером одновременно; обычно вы выбираете тот, который лучше всего подходит для загрузки нескольких ОС (, например. GRUB ). Если другие ОС перезаписывают MBR, вам необходимо иметь возможность загрузить «назначенную ОС диспетчера MBR» с помощью внешнего загрузочного носителя и перезаписать MBR.
При загрузке в стиле UEFI -загрузчики содержатся в разделе ESP (, в основном в разделе FAT32 )в стандартизированной структуре каталогов. Загрузчики нескольких ОС могут прекрасно сосуществовать в одном разделе ESP. Но есть одно «волшебное» имя файла загрузчика, которое прошивка UEFI будет искать, если нет переменных загрузки UEFI, чтобы направить его к определенному файлу загрузчика :на оборудовании x86 _64, это \EFI\BOOT\BOOTX64.efi
. Windows обычно размещает вторую копию своего файла \EFI\Microsoft\Boot\bootmgfw.efi
в этом месте, чтобы обеспечить загрузку Windows, даже если загрузочные переменные UEFI NVRAM потеряны (, например. из-за обновления/перепрошивки BIOS ). Kali «Force UEFI?» может означать или не означать вместо этого запись копии UEFI GRUB в \EFI\BOOT\BOOTX64.efi
раздела ESP.
Разные ОС имеют разные уровни поддержки UEFI, и выбор метода загрузки может быть привязан к выбору типа разбиения:
В отличие от Windows XP, для Windows 10 требуется несколько разделов. При загрузке в стиле UEFI -требуется раздел ESP (, который может использоваться совместно с другими ОС ), основной системный раздел Windows (, обычно диск C :), и небольшой раздел восстановления.. В новых установках обычно также есть раздел «Зарезервировано Microsoft», хотя технически это не является абсолютно необходимым :установки, обновленные с более ранних версий Windows, могут не иметь его.
Большинство загрузчиков/менеджеров загрузки могут загружать ОС только с использованием того же стиля загрузки, что и загрузчик. Если у вас есть двойная загрузка -с одной устаревшей ОС и одной родной ОС UEFI -, единственным способом переключения между ОС может быть использование меню BIOS для переключения между режимами загрузки или предпочтения «UEFI/устаревшие в первую очередь».. Диспетчер загрузки rEFInd — это собственный загрузчик UEFI -, который, по-видимому, в некоторых случаях может запускать загрузчик в стиле BIOS -, но его работа со всеми системами не гарантируется; возможно, вам придется попробовать это и посмотреть, работает ли это для вас.
Это полезно, если меню BIOS вашей системы предлагает хороший выбор вариантов загрузки:
Некоторые ноутбуки или настольные компьютеры марки -могут предлагать упрощенное меню BIOS с очень ограниченными возможностями настройки. В этих случаях вам, возможно, придется выяснить, предпочитает ли система UEFI или BIOS, а в худших случаях вам, возможно, придется создать установочный носитель ОС с «неправильным» типом загрузчика, намеренно отключенным (для USB-накопителей, удалить \EFI\boot\bootx64.efi
, чтобы сделать его только BIOS -, или заменить загрузочный код MBR допустимым загрузочным MBR, отличным от -, чтобы сделать его только UEFI -).
Похоже, что ваш основной диск имеет разделы GPT -и ОС на нем, вероятно, используют UEFI. Чтобы подтвердить это, запустите fdisk -l
и отредактируйте вывод в исходный вопрос.
Если это так, то ваши загрузочные переменные UEFI в настоящее время могут быть неправильно настроены и/или загрузчик UEFI Windows (, расположенный как /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi
, если смотреть из Mint ), может быть поврежден. Пожалуйста, запустите sudo efibootmgr -v
в Linux, чтобы проверить текущее состояние ваших загрузочных переменных UEFI и отредактируйте вывод в свой исходный вопрос, или, если он довольно длинный, например. поместите его на сайт pastebin и свяжите со своим вопросом.
Вероятно, наиболее удобным способом визуализации состояния вашего раздела ESP будет запуск sudo tree --charset ASCII /boot/efi
из Linux. Пожалуйста, добавьте это и к исходному вопросу. Чтобы сделать его короче,вы можете опустить подкаталоги -каталога /boot/efi/EFI/Microsoft/Boot
, так как существует несколько языковых каталогов -.
Вооружившись этой информацией, я (или кто-то другой на StackExchange ), вероятно, смогу помочь вам, не прибегая к догадкам вслепую.
Судя по рисункам, ваш диск sda
разбит на разделы MBR в стиле -, но вывод efibootmgr -v
содержит строку Windows Boot Manager
, указывающую на то, что в какой-то момент в прошлом система загружала Windows в стиле UEFI. Переменные UEFI идентифицируют раздел ESP, на который они ссылаются, с помощью уникального GUID раздела GPT(PARTUUID
в Linux ), а GUID в строке диспетчера загрузки Windows не совпадает с GUID в строке kali
.
С другой стороны, строка ubuntu
относится к разделу MBR, и эта строка содержит значение 0xd1e9685
, которое точно соответствует идентификатору диска sda
.
Исходя из этого, похоже, произошло нечто подобное:
Либо диск sda
был в какой-то момент преобразован из GPT в MBR, либо оба диска уже присутствовали при установке Windows, а sda
уже был разбит на разделы MBR -. Но установщик Windows был загружен в стиле GPT -, поэтому он искал место для добавления раздела ESP на диск с разделами GPT -для правильной загрузки в стиле UEFI -. Поэтому он отформатировал дополнительный SSD в стиле GPT -и вместо этого поместил в него раздел ESP и загрузчик Windows, поскольку в то время он, вероятно, был полностью неинициализирован.
(Эта тенденция помещать ESP на другой диск с остальной частью Windows, если есть возможность, является известной проблемой с установщиком Windows 10. Стандартная рекомендация — временно отключить или отключить любые другие диски перед запуском установщика Windows 10, если в вашей системе более 1 диска.)
При установке Mint установщик снова загружался в стиле UEFI -,но, в отличие от установщика Windows, он не будет касаться дисков, если это явно не указано, поэтому он создал свой собственный раздел ESP на диске с разделами MBR -(sda5
, тип раздела 0xef ).
Первая Kali, по-видимому, также создала свой собственный раздел ESP на вторичном SSD, но при разделении GPT каждый раздел имеет уникальный идентификатор GUID, и UEFI использует его для определения того, какой раздел ESP использует каждая ОС для загрузки, так что это не вызвало никаких проблем. смешать -упс.
Когда вы отключили основной SSD и вставили на его место дополнительный для установки XP, вы могли увидеть на нем один раздел с типом 0xee. Это была фиктивная таблица разделов MBR, которая является частью стандарта разделов GPT, чтобы указать любой операционной системе GPT -, не знающей, что диск используется. Но вы предположили, что диск не используется, и проигнорировали его -, поэтому в результате загрузчик Windows был перезаписан без вашего ведома.
Ваша вторая установка Kali также должна быть загружена в стиле UEFI -, и она создала раздел ESP в MBR -, как это сделал Mint. Кали «Force UEFI», вероятно, означает две вещи:
\EFI\BOOT\BOOTx64.efi
раздела ESP. В результате у вас теперь было две ОС с разными методами загрузки на одном диске. UEFI GRUB Kali не может загрузить Windows XP, поскольку для этого потребуется снова включить совместимость с BIOS при переходе от GRUB к загрузчику XP, а GRUB не знает, как это сделать. Похоже, что ваша система предпочитает загрузку в устаревшем стиле -, а не в UEFI, так как после исправления MBR XP прошивка сразу вернулась к загрузке в стиле BIOS -... что делает невозможным переключение на UEFI GRUB Kali, так как 16 -битовый режим совместимости с BIOS не имеет надежды на осмысленное использование 64-битного кода UEFI GRUB -.
Когда вы перемещали диски обратно в исходное расположение и снова очищали дополнительный диск, загрузчик Windows теперь очищался дважды. Восстановление загрузки Windows 10 запуталось, так как большинство Windows (были настроены на загрузку в стиле UEFI -)на диске с разделами MBR -и не имели раздела ESP на диске с разделами GPT -в любом месте. зрение. Установщик Mint, возможно, тоже как-то запутался, но это, наверное, не самое главное.
Лучшим выходом из этой ситуации и переходом к нормальной конфигурации, вероятно, является использование Mint для доступа к диску Windows sda2
и копирование оттуда всего важного на съемный носитель или в другое безопасное место :
sudo mkdir /windows_c
sudo mount -t ntfs-3g /dev/sda2 /windows_c
cd /windows_c
cp <whatever> </some/where/safe>
Затем отключите дополнительный SSD, очистите основной и начните с установки стиля Windows 10 UEFI -. Если возможно, вы можете изменить настройки BIOS, чтобы отключить совместимость с устаревшим стилем BIOS -для этого, чтобы все работало в стиле UEFI -. Затем установите Mint рядом с ним.
Затем вы можете удалить основной SSD, установить на его место дополнительный, снова включить совместимость стиля BIOS -и установить XP. Теперь верните оба диска на исходные места и, возможно, установите Kali в режиме UEFI на второй диск (, не выбирая «Force UEFI» ). Затем загрузитесь в Mint, убедитесь, что пакет os-prober
установлен, и запустите sudo update-grub
, чтобы вывести Kali в загрузочное меню Mint.
Теперь, используете ли вы GRUB Kali или Mint, оба должны предоставить вам три варианта :Kali, Mint и Windows 10. Чтобы войти в XP, вам, к сожалению, нужно зайти в настройки BIOS и явно выбрать загрузку устаревшей -стиль со вторичного диска.
Преобразуйте свой диск обратно в GPT с помощьюgdisk
:
sudo gdisk /dev/sda
Вывод должен выглядеть примерно так:
$ sudo gdisk /dev/sda
[sudo] password for xxx:
GPT fdisk (gdisk) version 1.0.3
Partition table scan:
MBR: MBR only
BSD: not present
APM: not present
GPT: not present
***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory. THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by
typing 'q' if you don't want to convert your MBR partitions
to GPT format!
***************************************************************
Warning! Secondary partition table overlaps the last partition by
33 blocks!
You will need to delete this partition or resize it in another utility.
Command (? for help):
Если вы не получили предупреждение, как указано выше, нажмите w , чтобы записать изменения на диск, подтвердите нажатием y . Затем снова запустите sudo gdisk /dev/sda
, нажмите p , чтобы убедиться, что ваш раздел EFI указан с кодом EF00
. Если это не так, вам нужно изменить тип (на опцию t , выбрать номер раздела, ввести ef00
, w для записи изменений, подтвердить y ), в противном случае выйдите с помощью q . Затем перезагрузитесь. Если повезет, ваша Windows снова станет загружаемой.
Если вы получили предупреждение, выйдите с помощью q . Вам необходимо заранее изменить размер раздела Mint на количество упомянутых блоков, чтобы освободить место для дополнительной таблицы разделов в конце диска. Вы можете использовать gparted
для этого. Или удалите /dev/sda6
, если вы собираетесь сделать еще одну новую установку. Затем повторите.
Вы можете изменить режим загрузки в Bios сUEFI/Legacy Boot
-> Both
на UEFI only
. чтобы больше никогда не загружаться в устаревшем режиме.
Вы также можете удалить существующие загрузочные записи UEFI «kali» и «ubuntu» с помощью efibootmgr
, например.
sudo efibootmgr -b19 -B
, чтобы удалить запись Boot0019* kali
.
ОБНОВЛЕНИЕ :Теперь я могу загрузиться в Windows.
Вот что я сделал:
Я перешел к способу 3. Он нашел Windows в папке D :\Windows, как указано. Так что я знал, что это все еще там и в силе.
После перезагрузки, НА ЭТОТ раз, я вошел в Grub -, но в меню Grub по-прежнему не было Windows.
Снова перезагрузился,зашел в «меню однократной загрузки» и, черт возьми, попробовал диспетчер загрузки Windows (, который до этого каждый раз терпел неудачу ). На этот раз он загрузился в Windows.
Я до сих пор не совсем уверен, что это была за волшебная комбинация, но я подозреваю, что преобразование GPT было шагом 1, исправление ошибок BCD было шагом 2, и теперь диспетчер загрузки Windows видит это.