*SOLVED* Help! Can't boot to SSD after cloning a Win10 drive

[sd_shooter]

We have a recent model PC:
- AMD Ryzen 8-core CPU
- 16G RAM
- 1TB Toshiba HD

We added a Samsung 256G SSD and used the Samsung 'magician' software to clone the contents of the old C: drive to the new drive.

- Changed boot order in BIOS to select the Samsung drive first
- Screen comes up blank! (except for small blinking cursor)
- If we change order to the old drive first, it won't boot either! (Windows says it's corrupt)

I downloaded a Win10 recovery USB stick and am able to run Diskpart. Here's what it shows





Any ideas? I've searched everywhere and can't figure this out!

TIA

Would it help to remove the old disk? It seems like my BIOS is not seeing the new disk as a UEFI-compatible disk (the little 'U' is missing)

[SkyHawk]

Try booting with legacy BIOS if you can, not UEFI

You could also try GPARTED to mark the disk as bootable, because right now it says BOOT DISK: NO

http://gparted.org/download.php

[baih777]

Try unplugging the SSD.

[Dragunov]

Did you turn off secureboot in the BIOS?

Whenever you add a SSD as a boot drive, ALWAYS remove every other drive.

You should have made an image of your C: drive, or cloned the SSD with something like Macrium Reflect, removed all other drives, installed SSD, Test, then add other drives.

If you can't figure it out, as a last resort, IF you still have the original, bootable content on your 1tb drive:

Download Macrium Reflect.
Install it on your old 1tb C: drive.
Make Macrium backup media.
Push an image of your C: drive to an EXTERNAL drive.
Do a FRESH install of your flavor of Windows, on your SSD. Use a Macrium rescue media USB drive, to pull your former image, from the external drive to your SSD.

[sd_shooter]

Try unplugging the SSD.

It worked!! Machine boots from BIOS to login in less than 10 seconds

Let me ask you this; would you go to a shoe store or a pizzeria and ask them how to fix a firearm?

These 'pizza guys' seem to know enough

Next question: How do I wipe out the old drive? If I plug it back in I won't be able to boot once again.
- Is it safe to 'hot plug' the SATA cable of the old drive?
- Is there a USB bootable program I can use to do the wipe? (haven't tried gparted yet.)
- Would the windows recovery USB I already have be ok for this? I can force the machine to boot from the USB even if I have both drives plugged in.

[sd_shooter]

Ok fixed the 'old' drive!
- Unplugged the SSD, plugged old drive in
- Booted from Win10 recovery USB
- Used 'diskpart' to wipe the drive clean and format to NTFS
- Plug all drives back in
- Reboot

Voila! All is well and PC is running on adrenaline!

[the86d]

This is pretty common with the EUFI, the new BIOS equiv.
(Or a newer controller than the majority of the on-board SATA.)

Like Windows, it tries to be smarter than we are, which usually doesn't work, at least in my experience (and all those around me).

[Robotron2k84]

To anyone that's used to administering NVRAM-based *nix iron, this should be recognizable quickly.

DOS BIOS was hard coded to use a primary boot block in the first 512 bytes of the primary disk. The MBR. This loaded a real mode program that gave the partition and offset of the second stage boot loader. Usually, PCs had a single or two IDE/SATA controllers and there was no way to control boot path, only to select a target disk on the primary controller. Bootable SCSI controllers had to inject their own BIOS program to interrupt the boot process to make one of its disks primary.

Now, on NVRAM-based systems, you can have any number of DASD controllers, SCSI, Infiniband, SATA, FCAL, etc. They all had the same interface to their boot logic: NVRAM stored the path to the controller, the target and bootable partition in the NVRAM. Multiboot was accomplished by setting a different boot path in NVRAM and rebooting. What NVRAM couldn't (usually) do, however was to read a file system such that the primary boot loader still had to reside in the first megabyte of the partition.

Fast forward to UEFI, and you not only have pathing, but also the ability to load file systems and read partitions, such that the primary boot loader isn't necessary anymore. The UEFI framework can find and directly boot a kernel.

To make this magic happen, you have to understand that some configuration lives on the GUID partitions in the disk, and UEFI has to interpret that to boot. If there is still a multi-stage loader chain, that configuration will be on an initial GUID partition that is not listed in the partition map.

Finally, by leaving two versions of the "C" drive enabled on the host, you updated the boot path, but the new target still had the old secondary loader in its configuration on disk. This lead to a split-brain configuration that was unbootable.

The quickest fix would have been to put the SSD at the same old target as the spinning rust, but could have been made to work by editing the partition on the old boot drive to label the new SSD as primary.

This is the confusion of UEFI, that the config is split between the firmware and the DASD.

[therealnickb]

Let me ask you this; would you go to a shoe store or a pizzeria and ask them how to fix a firearm?

^ LOL. Dragunov (and others here) know their chit.

[high_revs]

i'm planning to upgrade a couple of machines to ssd and was always worried about the cloning. (my own machine, i always did a fresh install).

wouldn't deleting the partition work in OP's case? I wonder if it wasn't booting to SSD because it's recognizing the old drive as a primary partition? or a low-level format via the bios?

[the86d]

i'm planning to upgrade a couple of machines to ssd and was always worried about the cloning. (my own machine, i always did a fresh install).

wouldn't deleting the partition work in OP's case? I wonder if it wasn't booting to SSD because it's recognizing the old drive as a primary partition? or a low-level format via the bios?

I think that is what was done.
AFAIK, you don't low-level drives after IDE drives came out.

I haven't used diskpart much, until recently, I always just used Linux or Windows to deal with partitions, and set the bootable drive in the BIOS, but I have limited experience with EUFI firmware, as my main rig is >10 years old... and other machines I work with only have one drive.

It would be beneficial to know what the proper procedure to resolve this w/out blowing out the OG partitions would be... could you mark a different partition on the drive active, would that resolve, or does GPT not work like this?

Most of us don't need to use GPT, YET, as MBR apparently works with any drive 2TB and under, and most of us are not buying 2TB+ drives, or SSDs...?

[Dragunov]

i'm planning to upgrade a couple of machines to ssd and was always worried about the cloning. (my own machine, i always did a fresh install).

wouldn't deleting the partition work in OP's case? I wonder if it wasn't booting to SSD because it's recognizing the old drive as a primary partition? or a low-level format via the bios?

If you shut off secureboot, remove every other drive (after making a Macrium Reflect image), and use a Macrium rescue disk to pull your image on your new SSD, you should be GTG.

[Dragunov]

Ok fixed the 'old' drive!
- Unplugged the SSD, plugged old drive in
- Booted from Win10 recovery USB
- Used 'diskpart' to wipe the drive clean and format to NTFS
- Plug all drives back in
- Reboot

Voila! All is well and PC is running on adrenaline!

Right on!

[Robotron2k84]

UEFI is somewhat self-correcting. As long as there are no other EFI System Partitions (the hidden GUID partition that contains the EFI loadable code), then if the only drive present has slightly different information, it will be updated in its non-code configuration on the drive at the next boot.

This is why removing all of the other drives fixes the issue as it forces the pre-boot environment to reconfigure.

Because UEFI only looks at signatures of executables, enabling or disabling secureboot has no effect, on system drives, if the data is cloned. Recovery utilities generally need secureboot disabled because their boot loaders are not signed or are signed with keys that don't have corresponding certificates in the UEFI keystore, and one reason new OSs ship with the ability to create recovery partitions.

Also, because UEFI supports booting for encrypted containers, the best suggestions for not causing split-brained configs is:

• One OS per host

• If you must have more than one OS, put only one OS per drive. It's important to only have one ESP across all drives as the pre-boot environment interrogates all ESPs to find all possible boot configurations. This can be a single point of failure if your ESP gets corrupted. You can maintain multiple ESPs, but have to edit partitions and NVRAM and it only ever becomes a hot/cold standby when working as intended.

• If you must have more than one OS per drive, get proficient at editing the UEFI environment and NVRAM from the OS

• Pray you don't screw it up and lose your encrypted volumes

Multiboot loaders can still work, but only in non-encrypted scenarios and they add extra complexity and can break other configurations.

If this is all over your head or you'd rather not deal with the complexity, back-up your data, re-enable BIOS compatibility in UEFI, repartition and re-install your OS with MBR formatting and restore your data. You will lose the ability to boot securely or encrypted and >2TB boot volumes, but can still use the old encryption tools to encrypt non-system drives, stubs or loopback mounts.

[billofrights]

Let me ask you this; would you go to a shoe store or a pizzeria and ask them how to fix a firearm?

That's a pretty crappy assumption. You're suggesting that people on a gun forum know absolutely nothing but ALL GUNS ALL THE TIME. Are you an armorer for a living? Most of the guys here aren't. I'm a network admin for a university. I know more than a few of the other regular posters in the tech & internet sub work in IT for a living.

It may shock you to learn that many people have more than one interest, and may actually be pretty knowledgeable about more than one thing. "Specialization is for insects." --Robert A. Heinlein