Не загружается linux с внешнего hdd

Слишком мало информации.

Могу предположить, что устанавливали груб. Винда как грузится, через груб или напрямую?

Конечно же напрямую, у него же UEFI. При дуалбуте в UEFI у каждой ОС свой независимый загрузчик, именно поэтому os-prober во всех современных дистрибутивах выключен.

Каждая тема про дуалбут на ЛОРе превращается в чертов цирк из-за некомпетентных советчиков, что пересказывают рецепты для BIOS 10-летней давности.

Загрузка в UEFI и дуалбут в UEFI иначе, чем в BIOS устроены, динозавры, хватит дезинформировать!

Не ставь внешние диски в uefi, оно не для этого. Как бы странно это ни звучало.

Krauzer , сейчас будет краткая теория. Увы, но ты должен понимать, что происходит, чтобы починить это. Фактически, я думаю что это не очень сложно будет, при условии понимания.

Итак, в BIOS загрузка работает очень просто: на диске есть MBR, это небольшая область в начале диска, и туда, прямо в виде 0 и 1, без всякой файловой системы, пишется загрузчик. Дуалбут на одном диске поэтому требует, чтобы GRUB2 умел грузить как Linux, так и Windows — MBR-то один на все ОС.

В UEFI загрузка и дуалбут устроены так:

• В самом UEFI есть записи. Они простые, по сути они значат «с такого-то диска с такого-то раздела грузить такой-то файл».
• На дисках есть EFI разделы. Это небольшие разделы, отформатированные в FAT32, на которых размешаются уже в виде файлов загрузчики разных ОС.
• При этом EFI разделов может быть более одного на одном диске, а на одном разделе может быть более одного файла и потому — более одного загрузчика.
• Классический дуалбут на одном диске в UEFI — это один EFI раздел в FAT32, на котором есть загрузчик как Windows, так и Linux. При этом нужная ОС выбирается при загрузке не в меню GRUB2, как в BIOS, а в меню самого UEFI.
• Важный момент — упомянутые выше записи в UEFI как добавляются автоматически, но только с внутренних дисков, при сканировании их EFI разделов на предмет файлов загрузчиков ОС, так и вручную или средствами ОС при установке. Внешние же диски по умолчанию грузятся только из removable media path: /efi/boot/bootx64.efi для 64 битного UEFI и /efi/boot/bootia32.efi для 32 битного, хотя можно добавить кастомную запись.

Так, теория изложена тут: Не загружается linux с внешнего hdd (комментарий)

А теперь перейдем к диагностике непосредственно твоего случая. У тебя же есть рабочая Windows, что способна грузиться? Открой в ней cmd.exe с правами Администратора, выполни bcdedit /v и пришли сюда вывод — это покажет все текущие записи в UEFI.

Спасибо большое за объяснение. Вот вывод bcdedit /v:

Диспетчер загрузки Windows
--------------------
идентификатор           {9dea862c-5cdd-4e70-acc1-f32b344d4795}
device                  partition=\Device\HarddiskVolume2
path                    \EFI\MICROSOFT\BOOT\BOOTMGFW.EFI
description             Windows Boot Manager
locale                  ru-RU
inherit                 {7ea2e1ac-2e61-4728-aaa3-896d9d0a9f0e}
default                 {c54e4466-2ab6-11ed-a109-dafb002d1de6}
resumeobject            {c54e4465-2ab6-11ed-a109-dafb002d1de6}
displayorder            {c54e4466-2ab6-11ed-a109-dafb002d1de6}
toolsdisplayorder       {b2721d73-1db4-4c62-bf78-c548a880142d}
timeout                 3

Загрузка Windows
-------------------
идентификатор           {c54e4466-2ab6-11ed-a109-dafb002d1de6}
device                  partition=C:
path                    \Windows\system32\winload.efi
description             Windows 10
locale                  ru-RU
inherit                 {6efb52bf-1766-41db-a6b3-0ee5eff72bd7}
isolatedcontext         Yes
allowedinmemorysettings 0x15000075
osdevice                partition=C:
systemroot              \Windows
resumeobject            {c54e4465-2ab6-11ed-a109-dafb002d1de6}
nx                      OptIn
bootmenupolicy          Standard

Т.е. линукса нет вообще. Как я понимаю дело в том, что что-то не так с efi записью на внешнем диске. Но тогда непонятно почему какое-то время оно работало. Я в винде посмотрел, на диске 3 раздела: efi, системный и файл подкачки, который сам создался, хотя в принципе не нужен.

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

swap очень даже нужен, что он лишний и мешает — это очередной миф от безграмотных админов: https://habr.com/ru/company/flant/blog/348324/

что-то не так с efi записью на внешнем диске

Не совсем правильно понимаешь. На дисках, причем любых, находятся только EFI разделы и файлы загрузчиков. Записи хранятся непосредственно в UEFI, то есть на матплате.

Но да, проблема в том, что у тебя есть файл загрузчика на EFI разделе на внешнем диске, но нет записи об этом в UEFI. Скорее всего, изначально эту запись добавил туда установщик твоего Linux, но потом, после отключения диска и перезагрузки UEFI убрал эту запись, так как не нашел нужного диска.

Я вижу 2 варианта исправить:

• Взять и сделать нужную запись руками. Минус — может снова слететь.
• Используя LiveFlash с Linux, через chroot переставить GRUB2-EFI так, чтобы он был в removable media path: /efi/boot/bootx64.efi для 64 битного UEFI и /efi/boot/bootia32.efi для 32 битного (у тебя скорее всего 64 бита), это сложнее, зато уже никогда не слетит, и ОС будет загружаться с этого диска на произвольных компах с UEFI.

Да, и какой именно Linux ты используешь? Это важно, у них немного разные пути загрузчиков.

Некоторые материнские платы убирают вариант загрузки из UEFI, если он недоступен (если диск отключили). Чтобы это решить, нужно установить UEFI-загрузчик в путь по умолчанию, для GRUB это делается опцией --removable

Если в плату встроен UEFI shell, можете запустить grub по пути efi/название_системы/grubx64.efi, затем, из-под операционной системы запустить: sudo grub-install --removable /dev/sdX, где sdX — имя диска с системой.

А, точно. Можно сперва в UEFI-shell выбрать временно нужный загрузчик, а потом переставить в removable media path, как я писал выше, не запариваясь с chroot.

Но, ЕМНИП, grub-install только в Debian-based есть, а он дистрибутив не уточнил, там может быть иная команда.

Спасибо за помощь. Насчет свапа я имел ввиду, что мне не нужен раздел, я бы использовал свап как файл, но это уже мелочи. Я воспользуюсь 2-ым способом. Я ставил kali linux. Прошу не закидывать камнями, а то судя по другим темам пользователей kali тут не очень любят.

А вот можно поподробнее про то, как мне выбрать нужный загрузчик из UEFI?

Я бы применил 3 способ — временная загрузка из записи руками и переустановка GRUB2-EFI из-под ОС.

К слову, в Kali есть и 4 способ: если тебе не влом переставить ОС с нуля, в debian-installer при выборе экспертного режима есть вариант принудительной установки в removable media path.

И если ты используешь Kali для пентестов, то норм. Но вот если считаешь её защищенной ОС — это миф, в Kali много средств нападения, а вот защиты не более, чем в Ubuntu.

Ну а использование её на десктопе просто глупость, проблем не оберешься, это даже разработчики признают: https://www.kali.org/docs/introduction/should-i-use-kali-linux/

Вы путаете с grub-update.

https://mricher.fr/post/boot-from-an-efi-shell/

Да нет, в RHEL-based к примеру grub2-install и никак иначе.

Переставить то не влом, но не очень хочется. Лучше изучу что-то новое через другой способ. Я вкурсе про кали и не просто так ставлю ее на внешний диск. Спасибо за информацию и ссылки. Я обязательно почитаю и отпишусь что сделал. И можно еще пожалуйста поподробнее рассказать про защиту в ubuntu? Я считаю любой дистрибутив линукса безопаснее винды при правильных настройках. Я не прав?

Ну, Kali до недавнего времени была опаснее Windows — только root по умолчанию же и без AppArmor. Сейчас уже на уровне Ubuntu, но не более.

А так в десктопном Linux для защиты обычно используются механизмы стандартных прав Unix, обычно ещё мандатная система сверху вроде AppArmor или SELinux, ну там файрволл во многих из коробки настроен, хотя не во всех, в последнее время так же в моду входит изоляция приложений в контейнерах через Snap или Flatpak, но большинство контейнеров дают полный доступ, так что это не всегда применяется… и всё, пожалуй.

А вот вопрос что безопаснее — обычный Linux или обычный Windows со всеми обновлениями и включенным антивирусом — на самом деле неоднозначный.

Впрочем, есть специализированные Linux для защиты, например Qubes OS — там по сути всё ПО живет в изолированных виртуальных машинах Xen.

Знаешь, возможно, я соврал, и нужная команда bcdedit /enum firmware.

Я думаю это уже не важно. Я сделал флэшку с UEFI shell и загрузился в kali и выполнил команду: sudo grub-install --removable /dev/sdb. Она выполнилась успешно. Так вот, вопрос. Эта команда перезаписала старую запись или добавила новую для removable media path?

Не знаю, если честно. Что она сделала с файлами можешь в /boot/efi посмотреть, записи в UEFI через efibootmgr -v. И запись для removable media path по идее автоматом на следующей загрузке будет.

Итак, эта команда мне не показала запись на внешний диск, но загрузка с него работает. В UEFI Shell я увидел, что старый путь для загрузки никуда не делся. Как можно его корректно удалить?

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

Спасибо всем за помощь. Я просто удалил файлы прежнего загрузчика, оставив только boot. Тему считаю закрытой.