The box is a Dell Inspiron 3650. It is UEFI, but I set vendor codes so I get the same behavior whether booting legacy or uefi. Drive is set to AHCI, and that is the only option. Secure boot is disabled. There really isn’t much to fiddle with in the bios.
The HDDs and network pass the compatibility test.
The title says most of it. I capture an image from this box. Listing images shows it to be 65GB, great. Swap HDD, then try to deploy the 65GB image to the new HDD only to receive the odd error “seems like you’re trying to restore an empty disk… no image file found that would match the partitions to be restored.” At this point if I list images the image is shown to be 0.0GB. Thoughts anyone? Did it really fail to capture even though it completes with a “mission accomplished” and shows a size, or is it actually stepping on a good image in the deploy process?
@geardog said in Cannot find disk on system, NVMe, RAID mode, Intel RST:
Thanks for the quick response.
I am running one NVMe “disk.” This is a SATA mode setting in the “BIOS.”
I switched to AHCI once, and no boot options were accepted. No access to bios was allowed. It was a boot loop until a bios setting “3 failed boots and restore last good settings” broke the loop and gave bios access back. After that, I was really hoping there was another route.
I’m pretty sure all the screenies came from this Dell XPS 8920 box I’m sitting at. What would make you think otherwise?
I’ve installed FOG 1.4.4 on ubuntu 16.04, imaged almost two dozen boxes around the house, and loving it. The UEFI boxes are proving a bit of a pain.
This is an NVMe drive with SATA mode set to RAID for Intel’s RST. Reading I’ve done on this box and NVMe drives says you must keep RAID mode to boot. I’ve seen a dozen posts similar to this dealing with raid, and my head is swimming quite honestly. This isn’t an array. It’s simply RAID mode. Is mdraid or mdadm appropriate?
Basic vanilla capture gave
“Cannot find disk”
I added …
Host Kernel Arguments: mdraid=true & Host Primary Disk: /dev/md126
which gave me “failed to read back partition (runPartprobe)”
System
The error is a windows boot error, or it is perhaps generated by the UEFI. It is shown in the string of 6 photos. It appears any time I boot the machine in legacy mode. It happens even with spinning platters, as win7 is not compatible with UEFI. I don’t know of a way around this switching until I upgrade to win10. Not sure it will ever happen as this is a Zeiss CMM control box.
I haven’t had any luck getting any of the UEFI boxes to come up as legacy, but I know diddly. That might work.
I’m on an XPS8920 with the same issue, more or less.
I thought I’d add that when I do the switch from RAID (for intel RST) to the AHCI to find the HDD, my box flips out. I cant get into bios until I’ve failed to boot 3 times, then I get a splash screen where I get and advanced option for bios repair/re-entry allowing me to fix my mistake. All that seems to be skating pretty close to crashing a box.
So the trouble I’ve had with this box is that it falls in the middle of the bios/UEFI game. I’m dealing with Win7 (doesn’t play UEFI) and an i210 NIC (doesn’t seem to play Legacy). Upping to Win10, and booting fully UEFI would be the fix for this last quibble with this box.
@sebastian-roth Honestly just happy I didn’t hose my boot files. I’ve sorted a number of complications that made this seem a bigger deal than it was.
The only settings that seem to have any impact are UEFI secure boot options. It amounts to a toggle between:
[Legacy on; secure boot off] which allows NVMe drive to be found and boot, but gives a fog failure “no cofiguration methods succeeded.”
[UEFI on; secure boot off] which prevents a windows boot, but gives way to UEFI policies picking up the DHCP/PXE request.
2)
Thoughts on how to get both sides to work would be great. I’m tempted to shift HDD mode to SATA, perhaps allowing it to work with UEFI, but I’m not excited about hosing my HDD in the process. I have a few more NVMe computers to go, and so far it hasn’t been as awesome as the bios boxes.
The error was poor notes on my part. Boot option “BOOT as UEFI” (which allowed the i210 NIC to be configured by fog properly) prevented the hard drive from being seen. Looks like I’ll have to adjust bios any time I boot from FOG.
So I was trying to image our UEFI HP Z240 with an NVMe (SamsungMZVP128HDGM-000H1), and after editing the DHCP policies it seemed to image fine. It did, in fact, save an image on my storage node, but upon coming back in the morning, no hard drive found.
This is unnerving, as I was trying to backup the exceedingly expensive calibration job on some scientific equipment this machine runs. I’m going to try a live distro to try and pull the most expensive data, but I’d really like to get this thing to work.
I found this link
https://forums.fogproject.org/topic/6315/hp-z640-nvme-pci-e-drive?page=1
As this issue didn’t seem to hose the OS, I started a new topic.