@EduardoTSeoane said in Store location:

mount /images on one disk and /images/dev on another disk

For fog, this is not a good idea. The issue comes on image upload. FOG will capture an image to /images/dev directory because that is the only directory that has a share level of read-write. At the end of the upload process the FOS Linux engine connects to the fog server over ftp and issues a mv command to move the files from /images/dev/<mac_name> to /images/<image_name>. The problem is this: If the image is on the same physical disk the only thing that is changed is the file pointers no data is copied anywhere. The raw data files stay on the hard drive where they were uploaded only the directory file pointers are changed. Now if /images/dev are on one disk and /images are on a different disk, the ftp mv command has to copy all the data from one disk to the other disk. This takes time copying a multi-GB file from one disk to the next. Will it work, yes. Will your upload take a long time, yes.

There is no advantage to splitting /images and /images/dev into two disks, but there are a few disadvantages.

@rurap Some small/older switches don’t have the internal bandwidth capable to send out multicast streams to all switches. On your tp-link switch, if it has a management interface see if it has an option for igmp snooping or anything regarding to multicasting and sparse mode or dense mode. You may just want to shop on ebay for older enterprise switches from HP or Cisco.

As for wake on LAN, that is a feature that needs to be enabled in the computer’s firmware to support WOL. I’m sure the FOG server is sending out the WOL packet, the computer has to be configured to accept it.

@rurap If you simply rerun the fog installer it will recreate these files in the proper location.

Also you can search the entire disk for these files with sudo find / -name undionly.kpxe

@rurap Please check to see if the files are in /tftpboot directory. It sounds like the tftp service didn’t get configured properly for fog to function.

As I said dnsmasq should have been working, with that final change (which you will probably want to remove now) if it didn’t work then we would have focused on the tftp server. So you did good moving forward to debug.

So if the files are in /tftpboot change the file path in the tftp config file to match then restart the tftpd service.

To answer your question, Yes you can.

Please tell us a bit more about what your problem is and how you want to solve it.

Because the image is extracted and compressed it would be more than difficult to make that a live image where you can patch it and then reseal the image. It would be faster to deploy it to a VM patch and then recapture. But with this method you will run into a limit on the number of times you can sysprep an image. There are workarounds but its just one more hoop to jump through.

I can tell you how my company handles this (which may not be the best way for you), we use Microsoft’s Deployment Toolkit to build our reference image using the lite touch method. So every time we need to update the golden image we make the adjustments in MDT and then have MDT rebuild the golden image, we then sysprep it and capture with FOG. MDT gives us a consistent golden image each time we run the task sequence so we don’t need to validate the image each time its rebuilt. That single captured image is then deployed to our fleet of 14 different dell models. One image for all. (truth be told its 2 images for all, one is for bios based computers and the other is for uefi based computer. MDT builds them both the same way for us).

@rurap The more I look at your picture the more I think it should be working. (I can see that its not) but the auto select says “Booting to FOG” so that means its getting and processing this line:

pxe-service=X86PC, "Boot to FOG", undionly.kpxe

We can see in the picture the boot server IP is 192.168.25.117, so we know its processing this line.

dhcp-boot=undionly.kpxe,,192.168.25.117

It should have everything it needs to boot.

We may need to grab a packet capture to see what the client is objecting to.

@rurap The 16.04 version will not dynamiclly support uefi and bios the 18.1 will. Now certain firmware needs an additional kick to get it to boot.

In this section add in the fog server’s IP address.

pxe-service=X86PC, "Boot to FOG", undionly.kpxe
pxe-service=X86-64_EFI, "Boot to FOG UEFI", ipxe.efi
pxe-service=BC_EFI, "Boot to FOG UEFI PXE-BC", ipxe.efi

change it to

pxe-service=X86PC, "Boot to FOG", undionly.kpxe,192.168.25.117
pxe-service=X86-64_EFI, "Boot to FOG UEFI", ipxe.efi,192.168.25.117
pxe-service=BC_EFI, "Boot to FOG UEFI PXE-BC", ipxe.efi,192.168.25.117

Then restart dnsmasq

@rurap Please post the content of your ltsp.conf file.

@rocksteve69 said in HP Elitebook 830 Gen 6: Issues Capturing Images and Deploying Images:

3b:00.0 Non-Volatile memory controller [0108]: Sandisk Corp Device [15b7:5003] ( rev 01)
Subsystem: Sandisk Corp Device [15b7:5003]
Kernel driver in use: nvme

I also wanted to look into this disk controller in the kernel build. This is not the typical intel nvme disk controller, its something new. I’m wondering if there is some kernel settings missing for this new hardware.

But I would surely try the kernel parameter that Quazz posted because that has fixed other strange nvme performance issues.