Best posts made by Tom Elliott

@robertkwild yes, it can.

@tesparza You can update the information in FOG Settings, but it will not automatically apply it to the hosts. This is just the “default” storage point, not the thing each host uses.

If you update the AD information on each of the hosts, it will rejoin the domain using the new information. No need to redeploy the image or client.

To change all the hosts more quickly, create a group, add all the hosts you need to change into the group. Then update the AD information from within the group.

@michaeloberg

As this is for testing I’d suggest:

wget -O /var/www/fog/service/ipxe/bzImage-rt-v215 https://drive.google.com/uc?id=1qxcjC9ZrV8lVh4T6rgBtmtgSp7SWRzL9&export=download
wget -O /var/www/fog/service/ipxe/bzImage-rt-opts https://drive.google.com/uc?id=1t4WgWHOv3wIFjnodRtMsRcaO87XIZxM4&export=download

From the host in question, assuming it’s registered, go to edit it and in the Kernel field type in the name of the kernel file to test:

E.G.:
bzImage-rt-v215
bzImage-rt-opts

I don’t know if you purposely deleted, but I will say our community isn’t as harsh as the arch community with questions.

That said if you’re okay with it, copy the files you change to your git clone as appropriate and run git diff

To complete installation run:

./installfog.sh -yX

it will take a bit but it will continue.

@fabiano-matos et al.

The TSC DEADLINE disabled due to Errata; please update microcode to version: 0x52 (or later)

Isn’t really an issue in the context of imaging. This is just meaning the microcode of the controller is older than what the kernel is expecting. Itself, is not an issue you should have to be worried about.

As far as your DHCP failed or we were unable to access…, that’s seeming to indicate the issue in your case is specific to not being able to get a DHCP address for some reason. This could be due to STP going alive, then down, then alive but the down period is longer than the period that FOG is trying to get the IP address. I haven’t been around very often recently, but I do recall there was a version or hold pattern that was set by the UI that could hopefully determine if this was indeed the issue.

Please see if STP is enabled on your network and maybe enable Fast STP RSTP or whatever it is called in your environment or disable STP altogether if you can.

@fabiano-matos I’m only giving information that I know when I don’t know all the details.

If other machines aren’t having an issue, maybe try changing the port the machine is linking up to to see if that helps.

@robertkwild Yes, at least by default. I don’t know how frequently we’ve had things actually usable from a partition to partition image, but typically the flow is:

Erase the Existing drive
Configure the Existing with the image partitioning schema
Write the image to the disk
(If resizable - expand partitions)
Reboot

@george1421 yes, you can extend an xfs partition but we can’t decrease it. Not nicely that I’m aware of at least.

@zaboxmaster You can probably accomplish this with a postinit script to overwrite the existing erasure script that runs.

I don’t have a direct example, but you can use the base script to essentially iterate over all hdd’s on the machine and perform the same actions.

@lukebarone Just so you know I’m not crazy lol:

https://github.com/FOGProject/fogproject/blob/b619bfe7b4cd8afff80a7c0a3fa56c1f6d3741e3/packages/web/lib/fog/fogftp.class.php#L464

@Jasper507446 Just because a host is part of a group does not mean they have an image associated to it.

@alexamore90 That sounds like a job for the unattend.xml file as part of a generalized hardware agnostic build of windows, not something FOG in a post-install script would be able to accomplish.

@AlkarimJ Are the disk sizes equivalent to the original source machine that created the image?

A lot of new machines have a smaller built in (or sub ssd) that links to the main drive, but FOG would see this as its own individual drive.

(I don’t know if that describes it)

The fact that the image type os Single Disk (Not Resizable) is the reason I ask the question.

The original partition layout is LARGER than the size of the disk on this specific machine, which it should fail. There’s not enough space to put the image in the appropriate places on the drive.

@zuchowra This often happens because of either the DHCP server isn’t presenting boot options, but more often it’s because you ahve multiple things responding with what server should be used. The system has no idea which one to use, so it requests you manually enter it.

Please check your dhcp server to ensure the boot option is sending option 66/boot server name

@Enigma Are you sure it’s booting PXE and not UEFI?

In case it is UEFI, please disable secure boot on the machine.

This is actually really simple to accomplish.

In the file that you found (/var/www/fog/lib/fog/BootMenu.class.php:

Look for the four lines:
[php] else if ($_REQUEST[‘qihost’] && !$_REQUEST[‘imageID’])
$this->setTasking();
else if ($_REQUEST[‘qihost’] && $_REQUEST[‘imageID’])
$this->setTasking($_REQUEST[‘imageID’]);[/php

They are at about line numbers: 655 thru 658

Place the lines in the else statement at line 677? right after the curly brack. Remove the first else in the statement so it’ll look like:
[php] if ($_REQUEST[‘qihost’] && !$_REQUEST[‘imageID’])
$this->setTasking();
else if ($_REQUEST[‘qihost’] && $_REQUEST[‘imageID’])
$this->setTasking($_REQUEST[‘imageID’]);[/php]

This won’t, by itself, keep the system from requesting a username and password, but all you should have to do is press enter.

With that you still have to select which image (if host has image already, it defaults to point at that hosts image, but you can choose any you please.)

An even better method would be to just remove the:
[code]login[/code]
from the fog.quickimage database entry.

Replace the lines
[code]param username ${username}
param password ${password}[/code]
With something like:
[code]param username fogusername
param password fogpassword[/code]
In the fog.quickimage database entry.

This should keep it from asking about a username and password as well as allow BootMenu.class.php to remain un touched.

I’ve decided, based on the multiple people wanting to customize the main boot items directly even, to re-enable editing so you can do this from the GUI now as well. So you don’t have to edit a file and you can make your changes
as needed.

@george1421 This sounds very similar to old old equipment?

Hubs vs Switches and the Hub is literally at capacity

@DBCountMan Yes,

There’s under FOG Client Settings from the FOG Configuration page, a “Pending” option that can be disabled “globally”, among other items.

See here:
https://wiki.fogproject.org/wiki/index.php/FOG_Client#Features_overview

You’re specifically looking for Host Registration

@DBCountMan It knows nothing of GUIDs as we don’t have a nice way to know what is what and in a consistently generatable method (believe me when I say we went down that Path and while we made some progress it wasn’t exactly feasible and has since more or less fallen off the radar.)

We use the device’s mac address’ to determine which host is attempting.

So if the primary device’s name is ME and the mac is 00:00:00:00:00:00, and you add a device with mac address 00:00:00:00:00:01, it will send both macs and lookup the device. ME will be found and 01 ending will be associated as pending mac to the device.