@Don-Winters said in Dell Latitude 5510 PXE Boot:

Everything should be set to the standard setting in Fog

I think we are not talking about the same thing here. Let me just restate a few things.

PXE booting relies on certain settings in DHCP. If those settings are configured your target computers can find the fog server. If your dhcp server is managed by an outside entity then they may have made the settings for you. If the dhcp server is based on windows 2008 then, 2008 is not capable of dynamic pxe booting in that the boot file (dhcp option 67) is either undionly.kpxe for bios computers or uefi.pxe for uefi computers. If what you are telling me is the case, you can only boot one type of computer (bios or uefi) in your environment. This is totally OK and a workable solution. There ARE a few things we could do differently to make your life a bit easier but we need to focus on your specific issue.

Its good that the fog server and the pxe booting computer is on the same subnet, that will help debugging what is going wrong a bit easier. I have a tutorial that will capture a pcap (packet capture) of the pxe booting process with this computer. We will use the FOG server to capture this information. Here is the tutorial: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

Grab the pcap of the pxe booting process and then upload the pcap to a file share (google drive, dropbox, etc) site and IM me the link. The filters in the tutorial will only allow the capture the minimum information needed to diagnose the issue. It will not capture all data on your network (considering you are state department regulated). If its not possible to upload this file then if you have wireshark available I can tell you what to look for, it would be much faster if I did it, but we can work either way.

@george1421 You have a great point. I discussed it with the boss, and we went the path of no client on the laptops. It is a relatively small number right now that need a somewhat quick turnaround. I figure we can bang out renaming and joining manually for these. Perhaps I will investigate other methods if there is a future order or it is the direction we end up going. Thanks!

@Single said in Kernel Panic:

A nickle (may be helpful)

I don’t think that one fits here since we are not doing nfs at this time. What we really need to see is the actual error that happened just before the stack dump that we see on the screen. Possibly if you can get a slow mode video of the kernel booting process we can see what the actual error message is. I’m not sure what we can do about it because its in the linux kernel but it might give us an idea where to look.

Mod Note: I forked your topic off from the hardware working with FOG because your situation needs a bit more explaining.

The newest hardware does not work with the FOS Linux kernels shipped with FOG 1.5.8. The issue is the linux kernel developers are no longer back porting the newest drivers to the Linux 4.19.x series of linux kernels. They are only writing new drivers for 5.x series of linux kernels. (if you want to equate this to the windows world, hardware manufacturers are no longer creating drivers for Windows 7, but now they only release drivers for Windows 10). The linux developers are doing the same, leaving the older ones behind and only writing for the new OS.

Because of this the FOG developers have released 5.6.18 version of the FOG Linux kernel. Understand this kernel has NOT been widely tested with FOG at this time. The deverlopers released this as an option for those FOG admins that have very new hardware that is not supported by linux 4.19.x. Since FOG 1.5.9 is on the edge of final release, 1.5.9 will continue to ship with linux 4.19.x with the option of the FOG admin to upgrade to 5.6.18. Once more people test this new kernel and it proves to be stable then the 5.x line of linux will become default for FOG.

I know its a lot of words to explain, yes I see 5.6.18 addressed your problem, well done.

@frit As I mentioned previously this is not a FOG Imaging issue. You are using FOG in a way it wasn’t designed. That is OK because FOG is an opensource project you can use it in any way you can imagine. The FOG developers do have limited resources to provide support beyond the scope of FOG imaging.

With that said, I feel you are going about netbooting in the wrong direction. Right away I see two issues with your setup.

using memdisk will restrict you to only being able to boot in bios mode. memdisk doeesn’t support uefi booting. If you use memdisk you need to have enough ram to hold the iso image and boot from it.

I have a tutorial on how to use FOG as a netboot server (again not as the FOG developers has designed) here: https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images

While I haven’t worked with manjaro its based on Arch linux (which also I haven’t tried to netboot) but you should be able to follow the ubuntu workflow to get it to netboot. There is a tutorial on getting windows pe to netboot and that does work.

Niether 0.10.9 nor 0.11.5 of the refind binaries made a difference (same exact error). Fog works, and the booting network UEFI and into Windows is 100% fine on the Lenovo m93p.

Turns out about 30% of our public machines are without a CSM module. Because of that, and because BIOS boot works, I have decided to fall back to BIOS boot deployment for my org’s public computers. The way my fog installation is now will still allow me to grow with the Lenovo’s without having to fight with it.

Thanks for looking into this with me, I have appreciated the help.

~ P.V.

@nerdstburns said in Minimum Server Specs:

unicast images on up to 100-200 computers

Is there any good reason you don’t want to use multicast? That would take a huge load off the disk subsystem and network of your FOG server!

@george1421

This is on an i3 NUC and its F10 to get into the boot manager.
f10-bootmanager.png

Then in the bios you need to make sure the uefi network booting is an option
uefinetworkboot.png

I have not been able to duplicate access via the ubuntu shim since I initially setup the configuration. It appears that the shim now checks the chained kernels or the secure boot code has been improved to check for signed kernels.

As for the raid-on issue. That is a known issue with the intel raid controller and linux.

I wish you well working with the 7400 2in1. I images ours last jul when they were first released. Those are interesting and finicky systems to image. Once they are imaged they are very nice computers. I can tell you the power button is only a suggestion to do things. Also if you want to get into the F12 boot menu watch the logo as it is powered up. As soon as the logo dims a bit then it will take the F12 key for a few seconds.

@techtalk I removed the external link in the topic headline. Please post more details to confirm this is no an ad post.

@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.