Cloned SSD boot issue

[kenl]

Hi

Trying to install a 1 TB Samsung 870 EVO ssd into a 4yo HD laptop running win 10, using their Magician software to clone the original drive.

Issue is that it won't boot on Restart. It starts normally when shutting down-cold starting. There were no problem like this with the original HD

Windows and drivers are up-to-date, disk integrity is good, bios rev is the latest. I've reset the bios to it's original settings, played with the post times, and even re-cloned the original drive with no luck.

I've installed 7 Samsung ssds and have never seen this. Even Samsung's tech help seemed baffled.

Anyone ever seen something like this, and any ideas on how to solve it?

Thank you

[ibanezfoo]

Did you already run sfc /scannow

If not run cmd as admin and type that in

[kenl]

Yes, no issues found and it didn't fix it.

[L4D]

If you have a bootable win10 iso (CD or USB). Try booting to it and do a repair.
This is a very rare issue but it has happened to me. I've cloned dozens of laptops from spinning disk to SSD and SSD to SSD. Occasionally this and other boot issues would happen. Booting to a win10 iso and doing a repair usually fixed it. I can't remember a time when it didn't.

Here's a few steps i've followed before as well if the default repair didnt work.

On the Choose an option screen, click Troubleshoot.
Select Advanced options and open Command Prompt.

In the Command Prompt window, type the following commands pressing Enter after each of them:
bootrec.exe /fixmbr
bootrec.exe /fixboot
bootrec.exe /rebuildbcd

[kenl]

Thank you for the info. Will try the recommendations today

[Dan_Eastvale]

Fixed??

Still have the original C: drive?

If all else fails the free version Macrium Reflect 8 then Minitool to extend the partition

[kenl]

Well, no joy, even with a clean windows install and using the commands recommended by L4d. All I've done is to verify that the problem isn't with the computer or windows.

I have a ticket in with Samsung. They may still have a solution, but not very hopeful. Don't know it I want to try a 3rd party clone program, but are there any suggestions? Is Macrium Reflect 8 and Minitool worth the time to run?

With 30+ hours into this, I'm very temped to go with another company's drive

[L4D]

Well, no joy, even with a clean windows install and using the commands recommended by L4d. All I've done is to verify that the problem isn't with the computer or windows.

I have a ticket in with Samsung. They may still have a solution, but not very hopeful. Don't know it I want to try a 3rd party clone program, but are there any suggestions? Is Macrium Reflect 8 and Minitool worth the time to run?

With 30+ hours into this, I'm very temped to go with another company's drive

Bummer. I've had good luck with Clonezilla its free.
Is it a Lenovo by chance? Does it go to PXE boot when it restarts?

[command_liner]

Is it an SSD or an NVMe device that is used to boot? These are completely different technologies that some people describe the same way. But one is a bit of hardware that attempts to emulate a spinning disk, and the other is a bit of hardware that looks like memory on the PCIe bus, but can be a boot target. Think of one as a S&W 629 revolver, and the other as a FN-FAL. Similar in some respects, but NOT THE SAME, even if both are "guns".

In particular, the Samsung expression of IDs on the PCIe for use as an NVMe boot target is unlike some others. If the device size is >1GB, you sometimes need to express it as multiple 1GB devices which are synthesized into a RAID-like configuration. I dealt with this quite a bit on HP Z8 systems and some HP laptops. Configure the PCIe "the other way" and try to boot. There are only 2 configurations.

Was the device previously used for something else? If so, there may be a GUID configured and your boot UEFI configuration could be trying to "help you" by finding and attempting to boot some old and invalid hardware configuration. I ran into this ALL THE TIME on some HP systems with a PCIe device that held 4 2 GB M.2 NVMe devices. The UEFI would search for a valid GUID on the first M.2 it could find, then boot whatever was there, even if it was a part removed from another system. Worse, the UEFI boot list would auto-insert this "bootable target" and make it the first boot device. Yikes!

Unwinding this is somewhat complex. One needs to edit the UEFI boot list to set the "next" and "default" boot targets, and delete the invalid target. Then the OS needs to be booted and the raw devices need to be nuked to delete all bootable information. For Linux -- particularly Ubuntu -- you might need to edit the fstab, which also may have been "auto-polluted" with an invalid NVMe boot target.

On server-class machines with multiple PCIe buses, multiple boot targets and multiple NVMe devices, there is still a single UEFI boot tree. But it becomes exceptionally complex to edit the UEFI boot sequence when invalid boot devices have been "auto-polluted" into the boot sequence.

[kenl]

No, it's an HP. What's weird is that it starts up with no problem from a cold start, but doesn't see the boot sector during restart.

No, it doesn't. It displays a boot drive not found message with the error code 03f0

Thank you for the recommendation

[kenl]

Is it an SSD or an NVMe device that is used to boot? ....

Thank you for the detailed explanation. Nothing special about this computer, just a simple windows 10 HP laptop. It belongs to a non-computer savvy friend that wanted an upgraded drive. I volunteered to put it in for him.

No, this is a ssd designed to replace a mechanical HD. It was new, in a sealed box, when I got it. This should of been a simple clone job, like the other 1/2 dozen that I've done with similar Samsung drives.

[command_liner]

No, it's an HP. What's weird is that it starts up with no problem from a cold start, but doesn't see the boot sector during restart.

No, it doesn't. It displays a boot drive not found message with the error code 03f0

Thank you for the recommendation

Good clue there. The UEFI configuration has independent ideas of "valid boot devices", "default boot device", and "next restart boot device". If the cold boot has "next restart boot device" -> "default boot device" -> "some valid boot device", then cold boot is fine. But the OS can independently specify "next boot device" during the restart sequence. If the OS is configured to point to the GUID of a device that *used to be there*, then restart will fail.

I saw this hundreds of times.

You need to boot the OS and configure the running OS UEFI table to set "next boot device" and "default boot device" to the right device, the new cloned device. It will be very helpful to get completely clear what the UEFI things the GUIDs are, particularly for the new device.. A disk clone tool will not always set the UEFI boot target because doing so would not be *cloning* the disk. A pure clone have an OS image that points to the GUID of the device from where it was cloned. You want a clone with a new boot target, which is itself, expressed as its on GUID.

[kenl]

OK, sounds reasonable. How can I inspect and edit the UEFI table, and is it safe to do so?

[command_liner]

OK, sounds reasonable. How can I inspect and edit the UEFI table, and is it safe to do so?

Under linux I used "efibootmgr" quite a bit. I see there is a Windows PowerShell tool that is similar, but I have never used it. Note that efibootmgr is COMPLETELY UNFORGIVING. If you fat finger and delete the wrong device, it is gone. Instantly.

There are more and more layers the more you look. The PCIe and USB trees can be changed at run time by the "auto plug and play" features of Windows and Linux. This can interact with the UEFI acyclic directed graph of devices and particularly bootable devices. Then there is the ordered list of boot buses and boot devices on those buses. Cold start is not the same as warm start is not the same as reboot is not the same as a plug+play event. Cold start always forces the PCIe and USB buses to iterate devices and regenerate the device tree... the same device tree that should be stored in non-volatile memory. Typically the policy is to auto-merge new devices, which is how you can boot from a new disk or disk copy.

Again, the OS can ignore this auto merge of boot targets from the UEFI (a good security policy) and hold onto its own concept of boot targets. Of course this is a 2-way street: the running OS can be used to invalidate its own restart. Either once with "next boot device" or forever by GUID overwrite or device retarget.

In linux you can check that the boot parameters in /etc/boot/* are the same as the UUIDs that might be stored in the fstab or the mdtab. Check the details with efibootmgr and see that they mesh. I could work through this in Windows, but not in my current Covid-befuddled state.

[kenl]

Ok, Thank You for a place to dig. I'm out of time to work on this until the weekend, but will check it out on Saturday