Posts made by george1421

I know Sebastian asked you quite a few of these same questions but I’m looking at it from a different perspective.

1. We may need the actual pcap file to debug what is going on. Its best to upload it to a google (or such) drive and then post the link here. That way you can take down the pcap whenever you feel the need.

2. What is your dhcp server? (Windows 2012 or newer server)?

3. Before FOG was introduced into your environment, did you already have dhcp options 66 and 67 configured?

In the case of fog, if you have an existing dhcp server don’t have fog install one. The fog dhcp server is intended to be when you have an isolated imaging network and you need dhcp services. If you have an in place dhcp server and its capable use it. You fog install should just be a standard FOG install.

As for the dhcp-helper/relay settings on your router. You only need those if you are running dnsmasq on your fog server. Normal pxe booting you don’t need to touch your routers unless you can’t route between the subnets.

@Sebastian-Roth FWIW it looks like we need some kind of regex expression to catch both cases.

$ lspci -nn|grep net
00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM Gigabit Network Connection [8086:1502] (rev 04)

$ lspci -nn|grep etwork
00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM Gigabit Network Connection [8086:1502] (rev 04)
02:00.0 Network controller [0280]: Intel Corporation Centrino Advanced-N 6205 [Taylor Peak] [8086:0082] (rev 34)

@totoro OK what I want you to do here is this:

1. Manually register this target computer with FOG
2. Schedule a capture/deploy (don’t care) but before you hit the schedule button, check the debug check box, then schedule the task .
3. PXE boot the target computer.
4. After a few enter key presses, you should be dropped to a linux command prompt on the target computer.
5. At the linux command prompt key in: ip addr show I’m interested in what it lists for eth0. Just post a screen shot of that output.
6. I’m also interested in the output from this command: lspci -nn|grep etwork

Based on the output of those two commands we’ll decide the next steps.

The intent of the following tutorial is to show you how its possible to use FOG to pxe boot a live environment with FOG: https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images
Again creating a disk-less boot environment is not the intent of FOG, its just a proof of concept.

@jmason First let me say, thank you for being so detailed and helping debug this issue. I know it takes quite a bit of time to do these iterative testing, so Thank You.

So I see from the pictures you have a 20% rate where it looks like the nvme disk 1 inits before disk 0. Can we correlate the 6th and 9th order with the swap when shown by lsblk.

I also see from the picture that the PCI address for nvme disks are not changing, at least the location vs name. My intuition is telling me that this problem is probably rooted in the linux kernel and or hardware/linux kernel race condition.

@jmason said in Dell 7730 precision laptop deploy GPT error message:

There is a BIOS update with the following fixes, but don’t see anything related to our issue. I can go ahead and update the system with all the latest fixes available if requested.

I would do this no matter what even though the change log shows the fix primarily dealing with the usb-c dock.

It would also be interesting to see if the 4.15.2 kernels gave us the same random results (Actually I’d like to push it earlier than 4.13.x but the inits would get in the way, because we had issue with kernels after that and the Dell Precision swappable nvme drives that have been since fixed). To see if this randomness is linux kernel related or not. I’m not really sure what this will tell us other than if the problem was introduced in later kernels.

@Sebastian-Roth (this is more of a brain dump than an answer)
Do we have empirical evidence that these disks are being swapped as being reported by the uefi bios? It would be a bit more telling if that second disk (for debugging purposes) could be exchanged for a different size disk, then run the test again. I might see the order being swapped between models of computers, but not the same computer depending on the boot. I might think this is an oddity in the uefi firmware. The Precision 7730 generation is pretty new, so the first thing I would check/watch for is firmware update availability.

Do we know if this issue is model or machine specific? It could also be a linux kernel issue where one of the drives may init faster/slower than the other so its detected by the linux OS at different times. It would be interesting to compare the FOS boot logs between the two states to see if there are any telling events. But again trying to get it to break and know when its broken is the hardest part.

@jmason Will you schedule a capture/deploy to both your master image computer and target computer, but schedule with the debug option.

On both the source and destination computers pxe boot them. You will enter debug mode and be dropped to a linux command prompt. Att he linux command prompt key in lsblk Post the output on both systems. This will print the geometry of both the source and destination disk(s).

@Taspharel https://forums.fogproject.org/topic/12929/error-rcu_sched-self-detected-stall-on-cpu-on-legacy-bios-capture-job/13

Sebastian recompiled the inits to support the older kernels back to 4.15.x. The links are a bit hidden in his post they are under the 64 and 32 bit words. It is safe to replace your existing inits in /var/www/html/fog/service/ipxe directory with these inits. They work with the current as well as legacy kernels back to 4.15.x. As always rename the current inits before you download and install these. You WILL have to do this from the linux command line since the webgui doesn’t have a solution to download inits.

@Sebastian-Roth Ugh…

@Scott-B Understand that link is for BIOS based computers. I might expect the UEFI mode computers will need a bit different boot kernel.

Looking at that error message again, why is it asking about bootmgr.exe that is a “MS Windows” thing. The Rescue CD of the link appears to be booting a linux (variant) kernel.

@Joe-Gill FWIW: I have a Pi3 at home with FOG 1.4.4 installed on it. I haven’t tried 1.5.x series yet since the new GUI has a bit heavier CPU requirements. Its more of a trade show novelty, but it does work well. I happen to have Raspbian installed without the gui.

@Joe-Gill said in Presenting On FOG at conference?:

I may end up giving a talk here this summer

If you really want to impress them (with at least the possibilities) take a Raspberry Pi3 and make a fog server out of that. Understand you are not going to have blinding fast deployments. But for a demo deployment it will work very nicely. The point being that fog doesn’t need a real powerful server for image deployment since all of the heavy lifting is done by the target computer. If you also installed dnsmasq and Wyane’s auto FOG reconfigure script script you could create a mobile FOG deployment server out of that Pi. Just bring it to a client network, boot it and then pxe boot the target computers into fog

@Qyjong said in FOG--How to Manually Restore an Image?:

If there was an easy way to convert a FOG image to Clonezilla,

Truthfully the quickest and easiest way is to deploy and capture. You will spend less time tinkering around with this method. Depending on the size of your image, you can deploy with FOG in less than 4 minutes. Have fog power off the target computer after the deploy, then boot with clonezilla and capture. The only unknown is capture time with clonezilla. Using this method you are assured that when you capture with clonezilla all of the bits are in the right spot for clonezilla to deploy it again.

[edit] Sorry I missed the main point of your post, how to manually restore an image. If this is the case then you won’t have the ability to deploy first…

I guess the first thing I would do is schedule a debug capture/deploy (doesn’t matter). Then pxe boot the target computer. After a few enter key presses you should be dropped to a linux (FOS) command prompt on the target computer.

From the FOS command prompt I would key in…

1. ip addr show and post the output here. My hope is that eth0 is present, shows a mac address and an IP address. Watch to see if there are more ethernet adapters detected other than eth0
2. If step 1 fails, then issue /sbin/udhcpc -i eth0 --now My hope is that it will pick up a dhcp address. If it gets an IP address then try to ping ping 192.168.8.2
3. If step 2 fails, then issue lspci -nn|grep etwork and post the results here.

This is a real interesting error. Its not clear if its a hardware controller error, disk error, or a linux kernel issue.

Do you have a second computer of the same model you can test on? Do you get the same results?

Here are a couple of ideas.
Make sure the geometry of file.png matches (exactly) the geometry and color depth of bg.png. Also if I remember correctly size does matter. There is a maximum total byte count of this background image.

Secondly some uefi firmware can’t / doesn’t display background images. There is nothing you can do it make it work, its flaky uefi firmware.

As for the uefi boot manager. Yes I’ve seen that myself. I think one of the developers was going to look into that issue. I don’t know if the fix will be in 1.5.6 or 1.5.7 if they can work it out. One of the issues we’ve seen is some people want windows to be the first boot option after imaging and other want to keep what ever boot order they currently have and not have FOG change the boot order.

This may be useless information at the moment, but I’m going to post it here for completeness.

1. I deployed a Dell 7010 today. The system is/was in uefi mode but I had to deploy the image in bios mode because in uefi mode iPXE will never finish initializing the devices. In this configuration the Windows Boot manager was not installed in the firmware and I had to go in manually and select the hard drive for booting. I can understand why this seems a bit broken but in this case FOG didn’t change the boot order.
2. When I was working on another project I know that efibootmgr (linux utility) can be used to modify the uefi boot order. So it may be possible to write a postinstall script to change the order to what ever order you need (if its fog that is changing the boot order and not windows). At this time I don’t know if the efibootmgr is compiled into the inits or I grabbed it from a centos install when I was testing the project.

And in the fwiw bucket, the dell cctk was mentioned below. There is a linux version of cctk that again could be used in a postinstall script. But that would be a dell hardware specific tool, where the efibootmgr would be hardware agnostic.

@iot said in Cliente não inicializa o servidor FOG:

ok the picture tells me that its trying to pxe boot but never receives boot information. I understand you are using vmware workstation. Sometimes this does not boot via pxe we see this as a problem.

If you pxe boot with a physical computer do you get the same error… no pxe boot or do you get an error number?

Also can you tell me about your dhcp server? What do you have configured for dhcp option 66 {next-server} and dhcp option 67 {boot-fil}? For dhcp option 67 if your pxe booting computer is BIOS firmware then you need undionly.kpxe if your pxe booting computer is UEFI firmware then you need ipxe.efi for dhcp option 67.