Приветствую.

Глобальная цель: превентивно подготовить внешний запасной nvme M.2 ssd носитель на возможную замену такому же существующему системному (с имеющейся уже Windows 10). С полной копией существующих системных и пользовательских файлов.
Локальная задача: для реализации цели надо первично хотя бы просто проверить и заранее убедиться, что применяемый метод клонирования/мигрирования ОС банально будет давать bootable диск ,а также понять, переносится ли лицензия ОС, не будет ли проблем потом.
Сразу оговорюсь, я уже проделывал попытки настроек в биосе с запретом FastBoot и BootSecurity, но как такового подменю LaunchCSM нет в принципе. Как я выяснил, он аппаратно запрещен производителем для связки с Windows 10, несмотря на то что у меня платформа на AMD, а не Intel. Но в любом случае, в итоге все же внешние SSD через USB стали определяться и вставялться в список альтернативной загрузки для выбора.

(1) подготовив таким образом новый недешевый (вообще говоря) диск, который не спешу покупать пока, надо в целях проверки и долго не разбирая ноут (т.е. не вставляя взамен штатного, т.к. это та еще прелесть в этой модели - надо полностью все кишки разобрать ,чтобы до слота добраться!) скормить диск ноуту в качестве именно внешнего загрузочного способа, т.е. нужно имитируя как бы загрузку с внутреннего накопителя в слоте, загрузиться с внешнего подсоединенного по USB порту того же самого nvme M.2 SSD-накопителя, на который предварительно спланирована миграция сторонними средствами ОС Windows, стоящая сейчас на встроенном внутрь ноута другом, родном для нее nvme M.2 SSD.

Перенес ОС в минимально необходимом наборе (без большого накопленного внутри \Document&settings\ пользователя) на SSD диск. Paragon HD manager (триал) в его режиме копирования ОС создал точную копию всех разделов исходного диска на нем, включая собственно 100-мегабайтный раздел EFI, нужный для распознавания и загрузки из BIOS . Подключил и BIOS распознал его, вставив в меню альтернативной загрузки наряду с существующим исходным внутренним! При этом я не вынимал внутренний nvme из-за описанных сложностей.

Но я рано радовался - попытка загрузить с него быстро наткнулась на проблему. По факту при загрузке после висения логотипа Асус на четверть секунды возникает голубой экран с QR-кодом и текстом "на вашем устройстве возникла проблема и его необходимо перегрузить", далее тут же следует автоматический рестарт и вскоре начинается "подготовка автоматического восстановления", которую я прерываю питанием, ибо не нужно мне такое развитие событий, тем более вижу по индикатору переходника sata-usb, что обращения при этом на внешний диск не следует.
В другой раз после такого же BSOD наступает обычная загрузка, но лишь с оригинального внутреннего. Кажется , действительно есть конфликт и нужно отключать внутренний...

Неужели действительно при подключении клона оригинальный диск нужно отключать как минимум для первой загрузки и загрузчик смотрит идентификаторы разделов -если подключены оба, то могут быть проблемы т.е. оригинальный внутренний может мешать? Ведь я же казалось бы явно указал, что грузиться с нового, внешнего и второй не должен мешать...

Вот только при этом выхолащивается смысл вариативной загрузки из списка BIOS как таковой. Какой смысл в ней, если всегда одномоментно должен быть только один диск системный диск? Или все же в конкретно моем случае эта симптоматика сугубо следствие именно клонирования. Если были бы две разные инсталляции системы (разные экземпляры, instance), то внутренние идентификаторы для загрузки были бы отличающимися?

P.S. не помог даже прямой принудительный временный запрет в BIOS прежнего внутреннего носителя в целях проверки загрузки сугубо с внешнего и БЕЗ необходимости лезть вынимать внутренний.

(2) вопрос о корректном переносе лицензии Windows в таком случае миграции/клонирования тоже актуален.

(3) Стоит штатный M.2 NVMe 1.3 PCI3.0x4 (Gen3x4) накопитель форм-фактора 2280 (с М-key только) пр-во Intel, модель 660р на 512Гб и низковатыми скоростями. Подумал заодно не просто о замене, а на производительный новый накопитель большего объема и возможно более скоростной. Так вот вопрос - а в принципе платформа этого ноута поддерживает более новый стандарт PCI4.0 и объем выше 512Гб или все бесполезно?
Техподдержка утверждает ,что стоящий по стоку модуль уже упирается в потолок и типа мне бессмысленно тогда апгрейдиться. Ограничения кругом - только 3.0, не выше полтерабайта и исключительно 2280 размер.

видимо, никому не интересно или никто не знает...

fuzzyo
не все готовы осилить стену текста подобную)
для начала попробуй в безопасный режим загрузиться на новом ссд.
а старый отключить нужно при этом

Апнуть тему это рабочий способ проявить интерес к ней:) Спасибо за отклик.

Так я как раз ради подробностей исчерпывающе описывал ситуацию, чтобы было максимально понятно, что происходит и что делал. Если бы я просто описал "не грузится", разве понятнее все стало?

Старый - это встроенный нативный m.2 nvme, который физически вытаскивать ради такого нет никакого желания в виду квеста с доступом к нему. Естественно, поэтому, как и написано было ,я отключил его с самого начала через биос, но результатов это не дало.

прежде чем туда стучаться, надо в принципе начать загружаться с кнопки питания, а именно на этом этапе идет описанная выше симптоматика.

Я вот за это время выяснил следующее. Возможно в этом причина?
Если в компьютере несколько физических жестких дисков, можно отметить активный раздел на каждом из них. Однако компьютер загрузится только с активным разделом на первом жестком диске, обнаруженном BIOS. Казалось бы, можно изменить порядок обнаружения жестких дисков в BIOS, но мне по факту это не помогло. Поэтому возникла версия о том ,что в результате клонирования его мастер не до конца подготовил новый диск к загрузке с него, а именно и в частности не сделал его соответствующий раздел активным. Поэтому загрузчик, не найдя такого атрибута на нем, "перескакивает" на загрузку со старого. Для проверки подозрения сделал следующее. Подсказка была в https://www.easeus.ru/partition-manager ... m-ssd.html
Будучи в запущенной рабочей винде со старого внутреннего диска и с подключенным по usb новым, использовал bcdedit, думая в начале, что можно запускать с ключом /store C:\Boot\BCD. Однако, выяснилось, что возвращается ошибка ненахождения файла конфигурации загрузчика в данном хранилище, характерному для MBR-дисков, поскольку в случае с UEFI-системами конфигурация загрузки находится на скрытом разделе FAT32 уже по иному пути:EFI\Microsoft\Boot\BCD
Запуск без параметров этой утилиты (по-умолчанию с опорой на текущий внутренний старый диск) дает указание в 3-х местах на путь системного диска partition=С: с виндой. Так вот и в клоне видимо так же прописалось указание на тот же диск С: Но , наверное, должно для корректной совместной работы со старым диском быть прописана иная буква диска?
Поэтому и планировалось тогда сделать:
1) Bcdedit /store X:\EFI\Microsoft\Boot\BCD /set {bootmgr} device partition=E:
2) Bcdedit /store X:\EFI\Microsoft\Boot\BCD /set {default} device partition=E:
3) Bcdedit /store X:\EFI\Microsoft\Boot\BCD /set {default} osdevice partition=E:
4) Проверить внесенные изменения вновь: Bcdedit /store X:\EFI\Microsoft\Boot\BCD
Должно поменяться путь на E:\, где X: это временная буква диска, присвоенная предварительно соответствующей партиции нового диска через:
diskpart
list volume
select volume N
assign letter=X

Но пока этого не делал, т.к. не уверен, что редактируя так bcdedit-ом, я не внесу случайно правки именно в файл конфигурации текущей рабочей системы и потеряю при следующей перезагрузке способность стартовать винду старую. А также неясно, если я внесу такие правки в конфигурацию и окажется прописанным путь до диcка E:, и даже станет возможной загрузка с нового диска, то на момент поднятия винды с этого нового диска не возникнет ли проблем уже у ОС в части того, что в ее реестре в результате клонирования остались все ссылки на программы и системное ПО на С:, тогда как она уже на E:?

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

Кроме того, смущает вот что. Анализируя и сопоставляю идентичность атрибутов партиций на старом и новом/клонированном дисках в части последней колонки "Сведения" выводного листинга , я вижу различия между ними: у NTFS-тома С: старого диска он Загрузочный, а у аналогичного NTFS-тома нового клонированного там пусто. Также 100Мб efi-раздел FAT32 старого диска имеет атрибут Системный, а аналогичный у склонированного - Скрытый. Это тоже не норма?
Попытка сделать активным, т.е. загрузочным раздел нового диска через команду active самого diskpart натыкается на невозможность, .т.к. этот синатксис допустим, оказывается, только для MBR-дисков, а типа для UEFI такое указание типа совершенно не нужно.

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

ну опять же. дело не в желании, а в том, что его нужно отключить для проверки.
не желательно, а именно нужно.
то есть столько дней с ОС было не лень экспериментировать, а потратить часок на разборку ноута было лень?)
получается как-то странно)
ну и также перед клонированием активировать f8 при запуске на рабочей системе
cmd От админа
bcdedit /set {current} bootmenupolicy legacy
после клона на новый накопитель отключаем старый, при запуске ОС на новом накопителе жмём f8, там безопасный режим выбираем.
ждём успешной загрузки, после чего пытаемся загрузиться в обычном режиме
лично я клонирую на новый накопитель прогой acronis true image 2021 (можно в составе всяких live cd/windows pe найти, только не младше 2021 версии)
ну и именно через акронис не клон делаю, а резервное копирование, а затем восстановление, ибо функция клона чет не всегда успешно работает на выходе

ну т.е. физическое отключение (вынимание) строго необходимо в подобных моим случаях? Я же полагал, что аналогичная функция биос реализует фактически то же самое, но видимо нет.
Если бы вы или кто другой более оперативно отвечали с момента первого моего поста, я бы может столько и не экспериментировал, а сразу последовал совету А так можно было полагать, что никому не интересно и я в теме один.
Подытоживая. В принципе не важно, каким именно способом (ПО) сделано копирование/клонирование. Главное ,что никаких именно последующих манипуляций с целевым диском вроде тех ,что я пытался делать, не нужно, так?
З.Ы. если вы делаете копирование/восстановление акронисом, который, например, может быть установлен как полноценное ПО в текущей Windows ,то очевидно, что процесс восстановления ОС уже на новый вставленный взамен старого диск должен происходить из-под откуда-то загруженного другого экземпляра акрониса, т.к. никакой рабочей системы ОС на данном этапе еще нет. Очевидно, это загружаемый с какого-то иного внешнего носителя boot-версия флэшки с акронисом?

именно так

по хорошему да

Да, спасибо. Тогда буду надеяться, что сделанный мной диск и без всяких манипуляций последующих все-таки будет загружаем, когда придет время им заменять текущий.
А, кстати, как той же bcdedit /set ..... задать таймаут появления этого меню, вызываемого по F8 ,после чего оно идет по дефолтному пути само?
Лайфхак действительно полезный ,т.к. в W10 такой штатный функционал вырезан

fuzzyo
По дефолту система загружается как обычно.
Ну как в 7ке это было, f8 доп загрузка только вручную выбирается

А время (таймаут) в течение которого процесс загрузки, будучи инициированным по F8, стоит на выбранной строке с дефолтной ОС и ждет реакции на вмешательство человека, можно уже штатно редактировать/задавать с помощью msconfig?