Best posts made by george1421

@Scott-B said in chainloading failed advanced menu:

Doh! I must have only allowed it temporarily. The field is there now. It’s blank.

OK great this is what we were seeing in the database with our sql query. Somewhere along the way this field must have been reset. You will need to hand code this menu entry for it to work correctly. I can tell you that by using the boot.php url I provided below which was displayed in your browser, you can see the structure of what you need to include in your advanced menu design.

@Sebastian-Roth what kind of shady stuff are you doing to have that field blocked by the ad blocker?? <just kidding> I wonder why this field still exists? If you look in the ipxe menu configuration there is a field Menu show on, some options are Advanced menu and Advanced menu with password. Were these options never implemented? I had the idea to make just a checkbox in the ipxe menu configuration to be advanced menu but it looks like someone already thought of that??

@Sebastian-Roth said in IPXE Chainloading error in certain type of computer:

40:01:c6

FWIW that comes back to 3Com Europe it might just be a IDS/IPS system involved here. A TCP reset is a typical response from a firewall/screening router to a filtered connection requested.

@Sebastian-Roth said in HP DC7800 network boot:

Yes -> https://fogproject.org/binaries1.5.2.zip ->

This is why you are one of the FOG Project Digital GODS.

@mclapper68 Depending on your deployment volume. You could download and extract the zip file. Save the init.xz as init152.xz and move it to /var/www/html/fog/service/ipxe on the fog server. Then finally update the init field for this host to init152.xz and for the kernel do the same, rename bzImage from the zip to bzImage152 and move to the same location then update the kernel field for this host to bzImage152. (sorry for the disjointed post I was thinking linearly here). That workaround will allow you to continue to use fog as it was deigned for the new kit, and still support his older stuff without fear of an update breaking your older systems.

@Jpolk91 excellent results. I did make a mistake and should have had you enter a command line switch on the lspci command. lspce -nn|grep etwor That command will give us the vend and device ID that should match what windows sees.

@Jpolk91 There has been some issues with the 1.5.x line but most have been ironed out with 1.5.5 (1.5.6 is not to far off either). The 1.5.x has a new web gui with a bit heaver load on the FOG server CPU, its not quite a snappy as 1.4.x versions, but its not bad with quite a few improvements in other areas making it a wash performance wise.

See if the steps outline here addresses your issue: https://forums.fogproject.org/topic/10006/ubuntu-is-fog-s-enemy

This is usually the case when fog has been working all along and then it stops for no reason with a database connection issue.

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?

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.

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

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

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.

@foguser said in Client doesn't boot from FOG:

Please stick with me with these (many) questions. I’m trying to draw a picture in my mind of your setup by using your words.

We have a set of clients provided with the service of the pxe citrix server. Notebooks are not part of this (locally installed, no need for pxe-boot until now). I plan to configure them on the dhcp once and leave the options as they are, no switching after that. So every device just needs one service, fog or citrix.

Lets come back to this since you have a windows 2012 dhcp server you can create filters to send the right boot file if needed. We use this technique for sending the right boot file for uefi vs bios type computers. I’m pretty sure we can make this all automatic once we get the pxe booting worked out

The Citrix server provides the client with a streamed image. The dhcp Option 11 is set for this and have been a few years untill i installed fog some days ago.
The options 11, 66 and 67 are configured on the scope of the client network to use the citrix pxe. No individual options until fog

FOG doesn’t care about dhcp option 11 so we can ignore that for now. For testing dhcp option 66 should be the IP address of your fog server (not the fqdn name of your fog server). The reason is some pxe booting roms are pretty dumb where they don’t do a dns lookup for dhcp option 66. For dhcp option 67 it should be either ipxe.efi for a uefi computer or undionly.kpxe for a bios computer.

The main Problem i still have is, the Notebook boots and gets the address and file of the citrix server.

OK to debug this we will need a second computer on the same vlan/subnet as the pxe booting computer. On this second computer install wireshark with the capture filter of port 67 and port 68. Start wireshark and then pxe boot the target computer. Once the target computer errors out stop wireshark. Please post the pcap so I can review it. I am interested in the DHCP OFFERS (not show in your initial picture). I’m interested in the OFFERS to see what the dhcp server is telling the target computer for boot-server and boot-file.

The DHCP-Server is Windows Server 2012 R2.

This wiki page will help when you get things working to automatically manage uefi and bios boot files: https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence#Using_Windows_Server_2012_.28R1_and_later.29_DHCP_Policy

Lets get the pcap from the target computer’s perspective. In my tutorial you will only see the FOG server’s side of the conversation because your target computers are on a different subnet from the fog server. If the target computer is on the same subnet as the fog and dhcp server you can get a complete picture of the booting process. In you case we will need to look at each side to understand what is going wrong.

@jemerson93 While it doesn’t help you at the moment, then can we say the issue of the cpu stall and other linux kernel strangeness is related to to hyper-v under windows 2016 server?

I have a hyper-v server running Windows 2016 Data Center in our backup hot site. This is for spinning up our Veeam images. The point is, I haven’t messed with hyper-v (ever sorry I’m a vmware guy) but I’m willing to see if I can create a VM and duplicate the same thing you see. The first step is to see if we have correlation between my server and your server. Then see if this is a common problem with linux OS running under hyper-v.

Lets start out with 2 questions:

1. If you place a functional windows computer on this same vlan does it get an IP address?
2. If you place a cheap/dumb/unmanaged switch between the pxe booting computer and the building network switch can you image every time?

My experience is telling me if you don’t get an ip address during FOS startup, but can issue the udhcpc command at the command prompt and get an IP address then its probably a spanning tree issue. Question #2 from above would prove that out.

@IndustrialTech87 OK for 1.4.4 that’s a bit old. I checked the linux kernel site and the first kernel release that supported that network adapter is 4.12.

hardware ref: vendor: 8086 (“Intel Corporation”), device: 15bb (“Ethernet Connection (7) I219-LM”)

So Download the FOS kernels from this web site https://fogproject.org/kernels/ Download 4.12.3, don’t go any newer. Its questionable if 4.12.3 will work with FOG 1.4.4. Just be aware of this. Don’t go any newer than what is absolutely necessary with 1.4.4. You will need to download both bzImage and bzImage32 and place them in /var/www/html/fog/service/ipxe directory. Make sure you rename the existing bzImage and bzImage32 so you can go back if you need. The downloaded kernels will need to be named bzImage and bzImage32 exactly (case is important).

@PITSKing Right with FOG there are 2 parts to “images”. The first part is the raw data files stored in /images/<image_name> the second part is the metadata stored in the database. You moved the raw data files but what is lacking at the moment is the metadata. If your old fog server is running and its 1.4.4 or newer, you can export the metadata from the old server using the web ui and then import that metadata using the web ui into the new fog server. If you don’t have the old fog server available, you will have to recreate the metadata by hand.

@PITSKing said in New FOG install, now can't find old image files in FOG:

I’m assuming that means I need to create the new Image inside the FOG web ui?

Yes.

@vanopy Will you do this for us? On your golden (source system). Schedule a capture/deploy again, but before you schedule the task, check the debug checkbox. Then pxe boot the computer. After a few enter key presses you should be dropped to a linux (FOS) command prompt. At the FOS command prompt key in lsblk and post the results here. Do the same on this target computer that is giving this disk size issue. Post both results here so we can see the disk geometry.

@chadman00 While I don’t like to jump right into capturing network traffic, I think its going to be the easiest way to understand if you have the filters setup right with dhcp.

place a target computer on the same subnet as your fog server and dhcp server for the best picture of what is going on then follow this tutorial: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

Take that pcap and look at it with wireshark. Looks at the OFFER response from your dhcp server. Make sure the boot file name is correct. If you are lost looking at the pcap upload it to a google drive and share it as public and post the link here and one of us will look at it to see if your dhcp server is responding correctly.

@Chris-Whiteley said in Issue with the "Deploy Image" option:

item Windows101809b - Windows 10 1809 (208)
item -Windows101809-Office2013 - Windows 10 1809 - Office 2013 (209)

I suspect these. Remove the dashes from the image names and see what happens.

More precisely its probably this image name :-Windows101809-Office2013