39 Posts
0
25476
G5 Not Booting from NVME Drive
I purchased a G5 15 5587 gaming laptop from Dell a couple of weeks ago and decided to upgrade the 128 GB m.2 SSD it came with to a 512 GB Samsung 960 Pro NVME for the space and speed. First I cloned my data from the 128gb SSD to a spare 500gb HDD had lying around through a usb to sata adapter. Then I replaced the 1TB HDD my laptop came with with the cloned 500 GB HDD as well as the 128gb SSD with the new (and completely blank) samsung 960 pro. I went to bios and told it t boot from 500GB HDD and it was successful. Then I cloned the data from the 500GB HDD to the new 512gb Samsung m.s SSD. I know it was successful because all my data was on the samsung ssd, and it was visible in task manager, windows file explorer and disk manager. I then restarted and tried to change the boot order from the HDD to the samsung SSD. This is where I ran into my problem: the Samsung SSD is not a boot option in the BIOS. I called samsung and they walked me through the installation process and were just as puzzled as I was. They told me that because the clone appeared successful and the drive showed up as healthy in disk manager the SSD was itself in good health. They told me that maybe the laptop was not configured to boot from an NVME drive or it was not supported and told me to contact Dell. I did so and after a hardware scan they told me the laptop was functioning properly and not much else. I have run out of ideas at this point. This is not the first time I have changed/cloned a storage device but this one has me stuck.
Problem: NVME drive not appearing in boot options in BIOS
so far: device is healthy, all data has been cloned to it, BIOS is up to date, device appears in disk manager and windows file explorer but not Bios.
If anyone else has had this problem before and cold offer some insight it would be immensely appreciated.
jphughan
9 Legend
9 Legend
•
14K Posts
4
October 18th, 2018 07:00
For anyone interested in underlying cause, there are a few possible issues and simpler fixes here:
- If you clone a Windows installation that existed on a SATA SSD onto an NVMe SSD and your system is in AHCI mode rather than RAID mode, then Windows won't boot from the NVMe SSD. The reason is that Windows when set up on a SATA drive isn't configured to load the NVMe class driver at boot, so when that installation is moved onto an NVMe SSD, it won't be set up to read it. When the system is in RAID mode, the Intel Rapid Storage controller abstracts the hardware from the OS and the OS has the Intel RST RAID driver loaded, so this isn't an issue, but otherwise you're a bit stuck. One popular cloning/imaging application called Macrium Reflect has a "ReDeploy" feature that's explicitly meant to facilitate booting an cloned/restored system on dissimilar hardware by making changes to the "boot critical" driver environment in the Windows installation prior to your first boot in order to work around this. It can deal with this exact "SATA to NVMe migration" issue even on systems that are in AHCI mode. It can also deal with a variety of other dissimilar hardware restore scenarios, including injecting user-supplied drivers for new boot-critical hardware if needed.
- The UEFI boot process is very different from the Legacy BIOS boot process. In the UEFI world, the boot menu you're referring to no longer just lists whatever hard drives it detects and allows you to rearrange them. Instead, for HDD and USB-based boot options, the boot menu consists of paths to specific bootloader files on specific devices, and as a result those boot entries have to be registered in the UEFI firmware in order to appear in the boot menu shown in the BIOS. Windows Setup takes care of this when performing a clean install, and again, some (but not all) cloning/imaging applications will also take care of this. Macrium Reflect has a "Fix Boot Problems" mechanism to deal with this, for example. Note that the system's one-time boot menu, accessed by pressing F12 at boot, does populate dynamically based on the hardware and file systems it detects as long as the bootloader files on the detected devices are in a standardized location (\EFI\Boot\Bootx64.efi), which they are for Windows installations. Did you ever check there when trying to troubleshoot? Sometimes if you boot the system once that way, it will end up in your BIOS.
- This may not apply to your case, but again especially with UEFI systems it's good to at least temporarily remove the source drive the first time you try to boot the new drive. Not only will that give you confidence that you're booting from the drive you think you are, but there are multiple reports here that some systems won't boot from new drives until the old one is gone -- but after the first time, the old drive can be introduced just fine if you want to keep it around.
And lastly, just as a side note, @Buzz635 if you never intended to boot your system that 500GB drive, your process could have been more efficient and functional if you had captured an image to that drive rather than cloning onto it. An image wraps everything up into a single file rather than cloning the entire partition layout. That's cleaner, allows the data to be stored alongside any other data you might have wanted to keep on that drive, and will typically be faster because image operations use compression. Since the bottleneck in these operations is usually the write speed of the destination, having to write less raw data means the job will complete more quickly. And in fact even in your restore scenario where you were restoring to an NVMe SSD, the bottleneck would have been the read speed of your source drive, so again compression would have helped. I'm also not clear why you initially cloned to the 500GB drive through a SATA to USB adapter and then installed it internally to perform the restore. As long as the adapter is USB 3.0, the adapter wouldn't have been the bottleneck in that situation, so assuming you meant to keep the existing 1TB drive going forward rather than downgrading to a 500GB drive, you could have saved some time and effort there too. Just for future reference.
augustl
108 Posts
0
October 17th, 2018 12:00
did you make sure to set the new partition/drive as bootable?
Buzz635
39 Posts
0
October 17th, 2018 12:00
I don’t think so. How do I do that?
augustl
108 Posts
0
October 17th, 2018 13:00
I would follow the complete set of instructions and fix the MBR (master boot record), boot sector, boot manager, and BCD (boot configuration data) just in case
no harm in doing all of it
augustl
108 Posts
0
October 17th, 2018 13:00
https://pureinfotech.com/repair-master-boot-record-mbr-windows-10/
Buzz635
39 Posts
0
October 17th, 2018 16:00
I don’t have to clone, but it would be much more convienant. I will try the process outlined by augustl first chance I get and if that doesn’t work then I will try a fresh install and migrate my data back over manually. Also I tried messing with UEFI and Legacy boot options but it didn’t work.
furcifer
1 Rookie
1 Rookie
•
42 Posts
0
October 17th, 2018 16:00
Do you have to clone for some reason? I did the same thing but used a recovery and new install. It takes about 10 minutes and there's no hassle.
I was going to clone but everything I read says it's a problem with nvme because they don't work the same way. I didn't get the technical part but something about the controller makes it impossible to make an identical clone.
Maybe try changing from UEFI to Legacy Boot in the BIOS.
furcifer
1 Rookie
1 Rookie
•
42 Posts
0
October 17th, 2018 17:00
jphughan
9 Legend
9 Legend
•
14K Posts
0
October 18th, 2018 07:00
Go into your BIOS and check your system's "SATA Operation" setting, which despite the name also affects NVMe SSDs. If it's in RAID mode, that's your issue. You need to use AHCI mode if you want to use Magician, although don't expect that to magically give you a bunch of extra performance. The catch is that you can't just change that setting on a live OS install. The official guidance is that you need to reinstall your OS after a change like that. You might find workarounds that involve things like changing registry settings or booting into Safe Mode or whatever in order to work around that, but if you just performed a clean install anyway, you might find it faster and easier to just do that again rather than research and experiment. Incidentally, this is another situation where the Macrium ReDeploy feature I mentioned in my post immediately above would be able to help. Technically there's no requirement that you run a clone/image restore before using that feature. You could just change the BIOS setting, boot into its Rescue Media environment, run ReDeploy, and you're good to go.
Buzz635
39 Posts
0
October 18th, 2018 07:00
Update:
I finally got my computer to boot from the Samsung 960 pro. I followed the steps outlined by augustl but after performing the repairs in command prompt it still would not recognize it in the Bios. After that I just did a fresh windows 10 install from the boot media in the flash drive and set up my computer normally after that. I don’t know why I didn’t do that in the first place. If anyone else has a similar issue with installing a new NVME drive I would just recommend downloading windows 10 boot media on a flash drive and doing a fresh install, it will save you a lot of time and trouble rather than cloning. After setting up some basic programs I downloaded crystal disk mark to benchmark the drive. The linear read was ~3300 MB/s and linear write was ~1600 MB/s. So I know it is running on NVME drivers, but the write speed was a little disappointing. (Is it rated for 3500 read and 2100 write) I tried to install the Samsung drivers but it did not detect the drive, and in their magician software it says drive not usable. It’s not a huge issue like getting it to boot was, but I would like Samsung drivers and magician software to work for best performance and optimization. Any suggestions as to why it’s not being detected by Samsung driver install and magician software?
furcifer
1 Rookie
1 Rookie
•
42 Posts
0
October 18th, 2018 09:00
Yes. Someone can correct me if I'm wrong but the nvme loads the driver from the drive itself via UEFI and RAID. If you change to AHCI in the BIOS it loads the driver from Windows.
For some reason the iaStorA.inf isn't detected by the manufacturer toolboxes like Magician. You need the stornvme.inf loaded from Windows to be loaded. It's weird because it's backwards, you would think the driver loaded from the nvme controller would be seen by the software but it isn't. Plus Windows seems to correctly label and identify the drive.
jphughan
9 Legend
9 Legend
•
14K Posts
0
October 18th, 2018 09:00
Windows doesn't support booting from USB-attached hard drives anyway, so you wouldn't have been able to boot from that drive while it was attached via USB. The only exceptions are Windows PE and Windows To Go, but the former isn't "real" Windows and the latter requires special preparation and licensing.
But I don't understand why you felt you needed to boot from that 500GB drive in the first place. The "normal" way to accomplish the end result you wanted is to boot your system from bootable media that would have been generated by your cloning/imaging application and typically stored on a USB flash drive. That gives you a way to perform cloning/imaging even if the drive inside your system is completely empty. It sounds like you decided to perform all steps of your migration from within a live Windows environment. That's certainly doable, but if you can't clone straight from your source disk to your "final" destination as it seems you couldn't, then that method is a lot more work because as you found, you then need to have a way to actually boot from the "intermediate" device, which in turns means you have to use cloning rather than imaging and also have to install that "intermediate" drive internally. That's precisely why cloning/imaging applications offer a way to create bootable media (and also because that type of bootable media is what you would use in order recover your system if your hard drive completely died and you needed to restore from an image backup file onto a replacement drive.)
Buzz635
39 Posts
0
October 18th, 2018 09:00
jphughan
9 Legend
9 Legend
•
14K Posts
0
October 18th, 2018 09:00
That's not quite right. When the system is in RAID mode, the Intel Rapid Storage controller on the motherboard is activated, and it is functionally equivalent to switching a desktop system from having the drives directly attached to ports on the motherboard over to installing a PCIe RAID controller card and attaching your drives to that instead. That's why when you're in RAID mode, you need the Intel Rapid Storage driver loaded in order to see your hard drive -- because the system has to know how to talk to the RAID controller before it can see the drives connected to it. Windows installation media for a while has had some version of the Intel RST driver built in, so occasionally it works out of the box, but if you mix a sufficiently new system with unmodified installation media for a sufficiently old Windows version, Windows Setup won't see your drives until you load the driver (or inject it into the install media itself). Being in RAID mode also means the OS no longer has to worry about SATA vs. NVMe, in fact it doesn't even know how those drives are connected. It only speaks to the RST controller over PCIe, and the RST controller has to worry about the rest -- which is why the NVMe driver isn't used when the system is in RAID mode.
By comparison, when you're in AHCI mode, the RST controller is deactivated and the system has direct access to the drives, which means it does matter to the OS whether it's using SATA or NVMe.
jphughan
9 Legend
9 Legend
•
14K Posts
0
October 18th, 2018 13:00
The Intel RST controller when enabled sits on the PCIe bus, so yes it would have to perform the same negotiations with the PCIe controller that any other PCIe device would. But that occurs independently of the PCIe negotiation that would occur with an NVMe SSD. To my knowledge, the SSD has the same PCIe bandwidth available regardless of whether or not the RST controller is enabled.