Posts made by george1421

@darkxeno First thing you have to keep in mind that the XX70 generation is still very new. The FOG Project relies heavily on the Linux Kernel developers for hardware support. When hardware support is added by the Linux kernel developers the FOG Project devs integrate that kernel into FOS Linux. The Linux kernel developers will always be behind in releasing supporting hardware drivers because hardware vendors and chip manufacturers sometimes release hardware in a closed manner where they release the chips and provide the windows driver.

But from a wireshark perspective, we can see what is flying down the wire using a witness computer connected to the same subnet, or the FOG server if its on the same subnet as the pxe booting computer. The FOG server is preferable since it would also collect unicast communications between the target computer and the FOG server. If the fog server can be used (i.e. same subnet as target computer) I have a tutorial for that: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

If you are using wireshark from a witness computer (i.e. computer plugged into the same subnet as the pxe booting computer) you can (should) use the capture filter of udp port 67 or udp port 68 That will only capture the dhcp/bootp part of the booting process. This is possible since dhcp uses broadcast messages to communicate so all hosts on the subnet will receive these broadcast dhcp messages.

@Schuede said in Xps15 Fail to deploy image - Ipxe / Uefi:

listen-address=127.0.0.1

Sebastian, good point I skipped right over that. In this case that command is telling dnsmasq to bind to the loopback interface. So only DHCP DISCOVERS on the loopback interface would get a response. Probably not what the OP wants. While that’s not the issue in the picture it would be the cause of the other issues reported.

@Sebastian-Roth said in Very slow registering host and pushing images to Dell Optiplex 7070 ultras.:

Maybe you have a rough DHCP in your network?

Just as a comment, I’ve seen organizations that have a primary and secondary dhcp servers setup intentionally, but only one of them has the pxe boot information. But looking at the OPs picture it looks like FOS Linux is unable to get an IP address. At that point the PXE boot information isn’t needed. But it does make me think its a networking (or possibly) a dhcp server issue. We probably can/should trap that error with wireshark so we can see who is saying what to the target computer.

@darkxeno Thank you for the feedback.

@Sebastian-Roth tagging you only so you are aware of the issue with the Dell system disks too.

@roc1479 Very nice, well done. We’ll have to go over it and test it in the lab, but the configuration is pretty straight forward. Thank you.

@darkxeno Well what’s not clear is if its a network issue or a disk (nvme) issue at the moment. We are seeing newer (select) nvme drives having a slowness issue writing the image to disk. That issue is being discussed in this thread: https://forums.fogproject.org/topic/13777/extremely-slow-deploy-to-nvme-drives/28

One thing you can test is to go into the global kernel parameters under the fog configuration and add in this kernel parameter
nvme_core.default_ps_max_latency_us=0 You will see an error with that name during booting, but its a warning, it will set the kernel parameter correctly. The issue is that there is a dot in the parameter name. See if that kernel parameter changes anything with write speed. What it does is keep the nvme drive from using any low power mode during imaging. We are seeing random successes with that.

We might also want to get you to move to the dev branch of FOG, that will take your FOG version to 1.5.7.55 or later. The developers added a nvme command line tool that we can use to push commands directly to the nvme disk. But lets first see if the kernel parameter masks the issue.

@darkxeno said in Very slow registering host and pushing images to Dell Optiplex 7070 ultras.:

So on the linux side it would be [8086:15BE] While I know that network adapter, that may have been a new model. But I looked in the linux docs and that driver was added in kernel version 4.12.x, you are at 4.19.64 so its been supported for quite a while.

@darkxeno First you have to remember I don’t know your network design so I need to ask 20 questions to understand how things are setup. So we’ve already ruled out a spanning tree issue since you’ve used a cheap switch on your bench and the issue is only with the 7070s so far. You are on the latest version of FOG with a moderately new kernel.

For the 7070s, under windows device manager can you get us the hardware id of that nic? We’ll need both the vendor and hardware IDs. Then I can look into the linux kernel to see if there is a driver for it. If its a realtek nic, I have a test kernel you can try that has an updated nic driver specifically for realtek 8168 series nics.

I guess a couple of questions to start off with.

1. In regards to dnsmasq, is the fog server on the same IP subnet as your pxe booting computer? If they are on different subnets then you will need to add the fog server’s IP address as the last address in your vlan router’s dhcp-helper/relay service.
2. What chipset is in that USB NIC? If you don’t know go into the windows device manager and pots here the hardware ID we’ll need the vendor and device IDs.

While its not as clean of an answer, if you were to manually register that target computer with the fog server. Then schedule a deploy task to that computer, but before you hit the schedule button, tick the debug check box. Now pxe boot the target computer. After a few screens of text on the target computer that you will need to clear with the enter key, you will be dropped to the FOS Linux command prompt. At the FOS Linux command prompt key in lsusb and post the results here (picture). That will give us the codes if FOS Linux sees the network adapter. I guess the output of this command would be handy too ip addr show

@darkxeno What version of FOG are you using? What version of the FOS Linux kernel are you using? You can see the kernel version in the fog configuration page. It would be a number like 4.19.64.

From the picture that is uploaded I see that (potentially) the client is on a different subnet than the fog server?

Also on the systems that have this issue of not being able to get an IP address, if you place a dumb (read cheap) unmanaged switch between your building switch and the pxe booting computer does it work correctly every time?

If you had time, it would be interesting if you could document the way you setup db replication between the two fog servers. It could be a great addition to the wiki pages.

@TOXYKILLER Well from your picture the first thing I noticed is that your fog server is at 10.<something off the screen> but your storage ip is 11.101.212.165 is that correct?

@kmonroe79 said in Starting cmain( )...:

What exit type or other FOG configuration settings need to be applied, so that computers will boot REGARDLESS of model?

This one is a little confusing to understand. Most companies that use FOG boot through the fog menu into the operating system. In this method the computer will pxe boot to the FOG iPXE menu wait until the timeout then boot the default menu item, this is typically the local hard drive.

In my case I have the HD set first in the boot order and then require an IT tech to press F12 during booting to select PXE boot to image. That way if the fog server goes away or the user takes a laptop off site it will always boot normally. Plus requiring the IT Tech to purposely boot into the iPXE menu we don’t have any imaging mishaps like imaging the wrong computer if everything was automated.

@kmonroe79 said in Starting cmain( )...:

However, my Lenovo M73 desktop gets hung up on reboot with the following message: Launching GRUB… begin pxe scan … Starting cmain

I would recommend that you set the BIOS exit mode to SANBOOT and only use GRUB if SANBOOT is giving a problem. The default for uefi is rEFInd. If refind has issues there is a config file you can use to boot. But circling back SANBOOT works for 99.5% of the bios based systems just fine.

@mikmatcr ok what I would do is run fdisk from command prompt

sudo fdisk /dev/sdb

d
p
2

d
p
1

w
e

Note it may be q to quit and not e to exit. I did that from memory.

That should delete both partitions and write them back to the disk.

Now you can start with the instructions https://forums.fogproject.org/topic/11048/moving-fog-s-images-files-off-the-root-partition-2017-edition up to and including step 7. That will create a new partition and then format it. Once you have it formatted then we can go through the steps to copy the files over and then remap the drive.

@mikmatcr Ok I see you have 2 disks installed (via the lsblk) command. That second disk appears to have some data on it. Was that your intention?

@TOXYKILLER Well I would expect that menu if you haven’t told FOG what to do.

I take it you have registered the host with FOG by either doing a quick inventory or a full inventory. Once that is done there will be an entry in the host management view. From there if you want to capture an image you need to create an image definition and then go back to the registered computer and link the registered computer with the image definition you created. Then finally on the host definition create a capture task and schedule it. When you reboot the computer and pxe boot it, the target computer will check in with the FOG server and since there is a task, start imaging the computer.

@greichelt You can reply to this thread as long as its in the same concept as the title. Just be sure to tag me so I see it.

@greichelt said in Windows 10 hangs at "Just a moment..." on Dell Latitude 5500:

. I got several prompts titled “Windows can’t verify the publisher of this driver software.” Manual install of the drivers

Ok that right there will cause the issue you describe. Its prompting for input on an invisible desktop.

There is a way around the “unknown publisher” error by turning off driver verification in the golden image and then turning it back on at the end of the setupcomplete.cmd file, but that is a bad hack. Its better to get solid drivers or remove the troubling drivers from the driver directory on the FOG server so they don’t cause problems on the deploy end.

So to me its not clear where its hanging during OOBE. If it was a driver issue, one would think that it would happen at the beginning of OOBE. Rebooting the system unexpectedly will throw an error on the reboot. Something about windows can’t continue, reboot to run setup or some nonsense like that. So with that said I would think it might be done with OOBE and maybe something in the setupcomplete.cmd, because that is the last thing OOBE does before the login prompt is loaded. So this is just a wild guess, but lets start the startupcomplete.cmd file started to execute, but got hung up before the pnputil or during the pnputil program was running. Rebooting the computer would then just bring you to the login prompt because OOBE was done.

So there is two ways to test this.

1. Use a post install script to remove the setupcomplete.cmd file and see if it images without hanging.
2. On a botched install, recopy the setupcomplete.cmd file and run it again using an elevated privileged account. See if it completes correctly.

I have seen (in earlier days), the pnptuil go to install an unsigned driver and pop-up with a dialog box saying its an unsigned driver and prompt the IT tech to accept this driver. Well the setupcomplete.cmd runs without a desktop so no one would be able to see the prompt or respond to it.

I also wonder if any of the log files in c:\windows\panther or where ever the unattend.xml file was would provide any help. I know it takes a masters degree to decipher the logs but they do tell you what was going on at the time.