Best posts made by Sebastian Roth

@FlareImp I just played with this stuff and seem to be able to update the inventory of a host through the custom iPXE menu using this as parameter:

kernel bzImage loglevel=4 initrd=init.xz root=/dev/ram0 rw ramdisk_size=275000 web=${boot-url}/ consoleblank=0 rootfstype=ext4 mac=${mac} storage=${fog-ip}:/images/ storageip=${fog-ip} loglevel=4 mode=inventory
imgfetch init.xz
boot || goto MENU

This is very close to what @george1421 came up with but I removed the deployed=1 parameter at the end of the kernel line because that would make the inventory task to try and check in (NFS mount, task list and so on) though this is not needed for a simple inventory.

EDIT: Though it seems to do the inventory update the entries in the DB don’t get updated yet. I will take a look at why this is not working.
EDIT2: Needed to add mac=${mac} parameter to make it work, updated parameter code above should work now. Note this is the first MAC address found by iPXE (same as variable ${net0/mac}). You might need to add some more logic in the iPXE code if you have more than one network adapter in some of your hosts and the inventory update does not work.

@foggymind said in NBP filesize is 0 Bytes; PXE-E18: Server response timeout:

Just started randomly receiving this error while attempting to UEFI boot

We probaly focused too much on the word “random” here… If you had told us this stopped working altogether, then we might have considered the TFTP service to be an issue but not if it’s random or if legacy BIOS clients still work. Anyhow. Let us know if you need further help with this.

@btoffolon The partition layout looks like it’s Win 10 2004 where Microsoft decided to change the layout and put a smaller partition (/dev/sda4) after the actual system drive (/dev/sda3 or C:\ in the Windows world) that you want to be resized.

For historical reasons (MBR layout and fixed boot sectors) FOG did not move partitions and so you see even when sda3 is being shrunk in size (72062114 sectors instead of 975486976) FOG does not move sda4 forward to make up for the gap.

We are working on this part of FOG currently and you are welcome to test a alpha version of this. Read through this topic and see if you want to give it a try: https://forums.fogproject.org/topic/15025/move-partition-in-gpt-layout-need-people-to-test

Be aware you should have a backup copy of your image and master machine as this is not officially part of FOG yet and not tested enough to be sure.

@danieln said in ipxe/boot.php and bzImage running very slow:

My FOG deployment speeds seem to be normal, however, when any client pxeboots into FOG, /fog/service/ipxe/boot.php and bzImage are running very slow . They eventually work, but after each attempt to run there are maybe 30 or so dots after it.

This is within iPXE that is used by FOG for some of the PXE boot process. So as a first guess I would say there is a driver issue within iPXE with a particular NIC (network interface card). But the question arises if this happens with all of your hosts in exactly the same way?

Are your hosts and the FOG server all on the same subnet?

This just started occuring today.

This makes things even more interesting. What changed since it worked fine? Update on the FOG server (new iPXE binaries)? Changed network components? Used different hosts (NICs, maybe USB ethernet adapters)?

@geardog Two things from the tutorial I just want to point out:

3. Make sure its at least version 2.76 by issuing this command at the fog server’s linux command prompt sudo dnsmasq -v. The version needs to be 2.76 or later.

and as George already mentioned here:

6. Be sure to replace <fog_server_ip> exactly with the IP address of your fog server. Be aware that <fog_server_ip> appears multiple times in the config file.

@o71 Interesting find! This has been in the code since a long time (long before I joined the team) and I am not sure if it ever worked like expected.

Digging way back into the code repo at sourceforge we used before github I think I found when this was added. Though this was part of a major code change and it’s not mentioned why.

• SVN r3996 when this part of the code was in a different location (service/snapins.file.php)
• SVN r4032 as the snapin code was moved to it’s own class/file and X-Sendfile header added - see line 53 and line 96 of SnapinClient.class.php

@Tom-Elliott Do you remember why this header was added? I’d think we can just remove it as it never made it into the Apache code and the module is not being maintained anyway.

If we want to keep the header I guess we should make it:

header("X-Sendfile: $filepath");

@Tom-Elliott I just pushed the change to header("X-Sendfile: $filepath"); in both dev-branch and working-1.6.

@Deblau73 The fog-ip variable always points to the main FOG server node. We added a new variable called storage-ip in dev-branch version 1.5.9.37 (github commit) or manually add the change in /var/www/html/fog/lib/fog/bootmenu.class.php. So you can update to the latest dev-branch to get it. It will be a few months till we get all things ready for the next official release.

@adrian-a This is a known restriction of NFS itself. You cannot export stuff via NFS that is mounted from somewhere else via NFS.

@imagingmaster21

Your branch is behind 'origin/master' by **1023** commits..
src/buildroot/package/fog/scripts/bin/fog.download

Those two lines of the output tell us that you haven’t used that git repo for a very long time. That path doesn’t even exist in that repo anymore. While I am not sure what the local change is (you can check via git diff) I would guess that a git reset --hard is the way to go forward.

Mind you, this topic is going all over the place, from partition issue to PXE/DHCP issue to git repo questions. We really try hard to help but this is high potential for confusions and I ask you to just open new topics for each question you have. New topics don’t cost you anything and it’s way easier to follow each issue and find a solution more quickly.

@jacob-gallant said in HP ProBook 640 G8 imaging extremely slowly:

Here are the results from iperf for ubuntu (still quite a few retries when connecting to the main FOG server):
https://photos.app.goo.gl/FDvPSgLoKVAUWDpY7

Looks pretty similar to what we had with FOG with many retries from my point of view: https://photos.app.goo.gl/xXFPLZFHAJT7dPEo9

As well Arch shows the retries. I really wonder why we don’t find more people reporting issues with that driver/NIC?!?

About the lspci command, I am sorry I got that wrong just typing it from the top of my head. I meant: lspci -k | grep -A 2 -i net (so we see which kernel driver is used)

@jtappen said in PXE boot issue with HP Probook 450 G8 (Realtek Nic):

So we changed all of our DHCP settings to point to snponly.efi and we are able to pxe boot into FOG…

Well that’s good news!

So a question, once it is able to FOG boot… is there a way (in fog or something) to see the Arch info needed to configure for ipxe.efi?

Do you mean you want to use ipxe.efi as default but only set snponly.efi for specific machines like the Probook 450 G8? Does snponly.efi cause an issue for other machines? If not then you can just keep using that for all.

@wayne-workman said in Fog for Dev - Save each capture in its own folder automatically.:

Research about FOG’s post download scripts.

Sorry but those are only run on deploy, not on capture.

@tvigneau This looks like the device is in UEFI mode and tries to load the BIOS legacy mode file undionly.kpxe - not gonna work.

You surely wanna read this: https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence

@jonhwood360 Thanks! I didn’t get to it over the weekend but hopefully will this upcoming week.

@BlankZapper Had a look at the client code and it looks like if you set CLIENT CHECKIN TIME to below 30 seconds it will default to 60 (ref).

Wasn’t me who came up with that code but I am fairly sure this was made to prevent from an overload. All clients will checkin to the FOG server that often and that will cause a high load on the server and database when you have hundreds of host with fog-client installed in your network. So they put that in as a measure to prevent people from locking up their server.

As well I think it takes two checkin loops of the FOG client to do the reboot - not sure but from the top of my head. One to schedule the reboot and the next to actually run it. So 30+30 seconds is probably the fastest you can go with the current fog-client.

Feel free to join in and work in this code if you feel this should be changed.

@claw22000 said in Imaging works in VM and not on bare metal:

When I try to connect to do the same thing it says "Reason: mount: mounting x.x.x.x:/images/dev on /images failed: Connection timed out.
Again the VM’s do not have this issue just the bare metal.

Not sure I understand this. The mount error on /images/dev happens when you want to capture an image from a host, right? That error only happens when you capture from bare metal but not when capturing an image from a VM?

I would look at the firewall rules on the VM host then.

Probably the best to ask about the API is @JJ-Fullmer

@greg-plamondon said in Fog Version 1.5.9.62 hostSecToken problem:

I am not sure where that is anymore.

Open the hosts list. On the left side you have the menu with “List All Hosts”, “Create New Host”, … If you have hosts pending you will also see a menu item “Pending Hosts”. If that is missing non of the hosts in the DB is pending.

You might also query the database for the other MACs:

SELECT hmHostID FROM hostMAC where hmMAC IN ('c0:3e:ba:3c:4a:6a', 'dc:41:a9:fc:05:30', 'dc:41:a9:fc:05:31', 'de:41:A9:fc:05:30');

@rogerpenn I guess you have installed FOG when the machine still had the IP 10.10.10.159 (maybe pulled from a DHCP server at some point).

Anyhow, here you find information on where to correct the IP address and what to do: https://docs.fogproject.org/en/latest/reference/change_fog_server_ip_address.html