@FuriousGamer065 Wow quite a gap here in response.

You need to know what mode the firmware is in because it controls a number of things. In the case of the boot loader you will need to send ipxe.efi as the boot file to the target computer for uefi mode. The same thing kind of applies to the source image. You can only deploy an uefi captured image to a uefi based computer. You can’t mix bios and uefi systems.

Hello world,

I had the same issu with dell 3070 on 24/03/2020, and i fix it by switching raid mode to ahci in the bios

@Sebastian-Roth I can do that. It is kind of the same issue. In RAID mode the registration option loads but it just never finds a hard drive. It errors out with the same error OP posted here (can’t find drives). I would assume because the Intel RAID controller hides the actual drives.

@tech49 Let’s try to break this down to what is actually causing this. Is the image resizable or non-resizable? What size is the source disk and what size the destination?

If destination is same size or larger I might suggest you try capturing a RAW image and deploy this just for testing.

@sokrina We updated the official kernel to allow for more than 8 CPUs. So you might just use the latest (version 4.9.101) or update your FOG server to 1.5.8 which was just released.

@ticsoftware said in Error when deploy image with SSD Sandisk Ultra:

The SSD have 500gb and it’s in the client and the Base computer .

I’m still focused on ensuring that the image will fit on the target drive. If you would have told me your reference image size (captured) is 250GB and your SSD was 500GB then the problem is some where else. If you tell me the reference image is 500GB and the target SSD is 500GB then we would really need to look at the captured image size vs target disk size. Single disk resizable works, as long as you don’t have a partition at the end that can’t be resized. That last partition may extend of the end of the ssd, where it would fit perfectly on a hdd.

FYI that I had this problem with a bunch Lenovo P51s. Bios did not have a setting for AHCI/SATA but in Boot priority I saw nvme beside the drive which none of my dells or even the P52s have (they show as HDD)
From one of the other posts I tried set the “Host Primary Disk” for that client in the fog web gui to “/dev/nvme0n1”. I was able to deploy images to these P51s.

@agray said in Imaging an SSD:

When we get our next batch of new PCs in, I’ll see if that fixes it and respond here. Thank you!

Do those have 500 GB drives?

You should be able to use the original refind.efi from 1.6.0 as this is one of the older versions. Whether it works I don’t know, but I do know of at least one person who uses this old version (0.9.4 I believe?) with their HP machines. They also needed to use the 10 second delay files due to NICs being power save ready.

@nextechinc I can’t answer that. If you can tweak 5.4 with the newer driver then go for it. 5.5rc may also work. I guess the question would be how many NUCs do you have and what would take the least amount of effort to do (probably 5.5). Understand that you can define a custom kernel for each host definition. SO what ever direction you go in keep the kernel name unique and only assign that kernel to the systems that need it.

It appears (guess) that FOS or iPXE is seeing two different network adapters as nic0. It is possible to boot FOS Linux from a usb stick. The issue is that the deploy image function you use is a product of iPXE and not avaialble via the FOS Linux usb boot method. With that said there is a hack of the FOS Linux usb boot hack that can simulate the “iPXE Deploy Image” menu.

I posted instructions on how to do this with graphical representation late last year but I can’t seem to find it at the moment. In this post it kind of explains how to do it with the FOS Linux grub menu. https://forums.fogproject.org/topic/12842/fos-boot-usb-quick-image-issue/12

Edit: Ah I found it, look at the last post in this thread: https://forums.fogproject.org/topic/13977/suggestion-please/66?lang=en-US&page=1

If I remember correctly the X90s was the first model to support uefi booting (not via the network) The x010s were the first models to support network booting in uefi mode.

So a couple of things first for the x010s, while they will pxe boot in uefi mode, iPXE will hang initializing the devices and sit there forever.

So this workaround will with for both the 790 and 7010s.

You can image the machines in bios mode, but switch them back to uefi mode before the first boot into OOBE. The easiest way to do this is to have fog power off the device after imaging. So you will have a tech standing in front to power it on to go into the F2 bios screen and switch the mode to uefi before oobe runs.

The second option is to boot FOS Linux from a usb stick with the hardware in uefi mode. FOS Linux (the OS that is downloaded via iPXE) boots correctly in bios and uefi mode. Since iPXE and pxe booting is not used there is no conflict.

The third option is don’t use 12 year old+ hardware (which isn’t probably an option)

Hi folks!
Thanks for taking time to look into this.
And yes, you’re right about the FOG client. It’s inside the image and the service is activated from the beginnen. While researching I came across the mentioned link after I experienced those problems.
It was just such a weird behavior I was unsure and did not try out the delayed strting of the service.
I’m going to modify my image in the next weeks. If the issue continues I’m going to open a new thread.
Thanks a lot!
Great help from a great community!

Chris
P.S. How to mark this issue as “solved”?

@tunatoksoz Hmmmm, thanks for joining the discussion here! Seems like you are making progress on this more than we have. 🙂

May I ask you if this is on Lenovo 300e as well? As you are saying yours has a build in NIC plus one on PCI I kind of doubt you have the same machine. Can you be more specific on what make and model you see the issue on?

@doubleve Do you have fast boot disabled in Windows before you started the capture task? Sure the machine is not hibernated or anything?

Did you see any error message in the blue partclone window that has been on screen hust before the screen we see in the picture?

@george1421 @Sebastian-Roth I reverted everything back and switched the Sata mode to AHCI and everything is working great again and both the NIC and storage passed the compatability test!

Big thanks to both of you!

Hopefully the big companies will start releasing open-source drivers so Linux can thrive

Thank you for the response, I appreciate it. I’ll give that a try.

I thought of a bit of an easier way to explain the field mapping between the kernel parameters ( cat /proc/cmdline ) and the grub menu. Here is a graphic that explains how to map the values between the two different booting methods.

Grub_field_mapping.png

Hi Sebastian - interestingly when I switch to the 32bit kernel everything woks fine so as far as were concerned the problem is solved

@Sebastian-Roth Sadly I am out of surface go’s to test at this time. Gotta get the ones we have in production.