Posts made by george1421

The disk structures are different between bios (legacy mode) and uefi so you need to maintain 2 different golden images. A bit off point, but we use MDT to build our reference images (1 for bios, 1 for uefi using the same task sequence). MDT reduces our build out time for our golden images quite a bit.

@farooq-hussain-m There is a bug in 1.5.0 that will be fixed in 1.5.1, which I hear will be released soon (maybe early april). There is a way to install a pre-release version of 1.5.1, if you can’t wait until april. Tom provided instructions below on how to switch your git repository to the “working” branch.

@nexqs so from an elevated linux command prompt can you key in
sudo apt-get update and have it complete successfully?
What about sudo apt-get upgrade?

@chris-whiteley

If we were to parse this, location might site? If so does each site have its own IP address range?

What about floor, what is unique about the floor?

The same for place?

The idea here is to find something unique about each specific OU.

I guess a logical question might be how many OUs are we talking about?

@chris-whiteley Well it depends on what you mean by easy? Everything has trade-offs.

Can you provide what your AD structure looks like and how you might calculate the OU?

@tom-elliott Would this request be closer in design to the plugin for managing windows keys? I don’t know what was involved with that plugin, but on the surface it sounds like a similar task.

@chris-whiteley Lets look at this from another direction.

Can the target OU be calculated during deployment? I have a complex OU structure [image][hwclass][site][domain] (ou=soe,ou=desktop,ou=nyc,dc=domain,dc=com) that is calculated during image deployment, and I use a post install script to update the unattend.xml file with the proper OU placement. I let the unattend.xml file connect the computer to AD and not FOG.

Check the apache error log to see if there are any errors thrown. The upgrade should not touch the login credentials for the web gui.

If by chance you are talking about the linux console user fog, then you have problems.

@tiagoluz I agree either Debian or Centos is a good choice for a first time FOG installation. Ubuntu sometimes causes FOG issues.

But FOG is tested against 9 linux distributions every day to ensure FOG installs using an automated process that Wayne developed.

@kabaiz As Wayne has said there are many tutorials on the wiki. It just depends on which operating system you pick as your fog server OS (linux only at this time). For example here is how to install FOG on Centos: https://wiki.fogproject.org/wiki/index.php?title=CentOS_7 Just be aware that there is nothing simple with imaging. There are a lot of parts to imaging and any of them can cause imaging to fail. FOG is a great software for the price, but FOG is only a small part of the entire imaging process.

FOG has many options depending on your current network environment. You do not need to use FOG as your DNS or DHCP server. Those options are available if you don’t currently have the networking resources. If you do have existing services then don’t enable them during FOG setup.

You can do unattended imaging, or require a technician at the target computer to start the process. The decision is yours and how much risk you want. Risk in the idea you might accidentally tell FOG to image the wrong computer if you have a completely no touch imaging.

FOG handles both uefi and bios booting and imaging. FOG does support LVM but it can’t currently resize the LVM partitions like it can do for standard partitions. So if you are imaging linux and want FOG to resize the partitions to the size of the target computer, then create your master linux images using traditional disk partitions and not LVM.

You can decide if you want the clients to pxe boot into the fog menu each time (which will grant the unatteded imaging option), or require the IT technician to be at the target computer to call up the boot menu to select pxe booting into FOG. That decision is a business workflow that you need to decide.

@nexqs OK, it sounds like you have all of the bits in place. Then if it still fails to install, there is a sub directory of where the installfog.sh script it. I think its called logs or such. In there should be an error log that might give us a clue to which repository its having an issue with.

The error means, that the FOG installer can’t connect to your linux distributions repository to download required components.

@kafluke I would start here and review this document the cron schedule is pretty powerful, but very cryptic. https://en.wikipedia.org/wiki/Cron

Once you are totally lost you can start with this process.

Switch over to the root account by issuing this command at the linux command prompt.
sudo su -
Then edit the crontab (the config file that manages cron) with
crontab -e
once in the crontab editor you might put something in there like this (don’t blindly copy and paste it in, really understand what its doing)

0 7 * * * systemctl stop FOGImageReplicator
0 18 * * * systemctl start FOGImageReplicator

slighly off point post, but recording for reference.

MBR 512n

Disk /dev/sda: 17.2 GB, 17179869184 bytes, 33554432 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x00006e8c

GPT 512n

Disk /dev/sda: 36003.6 GB, 36003637100544 bytes, 70319603712 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: gpt
Disk identifier: 3DAC1844-EDDA-43CD-9334-E0F3515F0AC7

MBR 512e

Disk /dev/sda: 1098.4 GB, 1098437885952 bytes, 2145386496 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk label type: dos
Disk identifier: 0x00000000

4Kn

Disk /dev/sda: 999.0 GB, 998997229568 bytes, 243895808 sectors
Units = sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk label type: gpt
Disk identifier: 4CD4D7DC-B85C-47B5-A8D0-BCFA2345A58D

I’m sure there is a better way…

fdisk -l /dev/sda|grep -e "Sector size"|awk '{print $4, $7}'

There is

fdisk -l /dev/sda|awk '/Sector size/{print $4, $7}'

@breit That’s not exactly what I was asking (but good info none the less). I wanted to ensure that the target drive is larger than the nvme drive where you captured the image to. I understand you picked single disk resizable, I want to ensure that you’ve tried to deploy the image to a SATA disk larger than the source disk.

@breit said in Hard Drive, SSD, & M.2:

So for clarity you are capturing a ~256GB NVMe disk and deploying to a SATA disk of a larger size?

Also for the developers. Can you post the contents of d1.partitions and d1.fixed_size_partitions of the source image?

I can say that the naming convention between a sata and m.2 interfaces are different. I’m not sure if that would cause the error you mentioned. I might expect the target disk size to be an issue before naming.

I can also say its best practices to use a VM to create your reference images. That way it removes all hardware dependencies. But I also understand that circumstances dictate how you can do things.

I might recommend a few things to offer a successful installation of fog.

1. Your FOG server needs to have internet access when fog is being installed. Internet access is ONLY required during installation. Once installation is done then FOG can run in an isolated environment.
2. The FOG server does not like it when its IP address is changed after FOG is installed. So for your FOG server, give it a static IP address that won’t change.
3. Since you are running FOG inside a virtual box instance, make sure you are running a bridged network adapter (not nat). The target computers will talk to the FOG server using the FOG server’s IP address. If the FOG server is behind a NAT interface, the clients will not know how to reach it.
4. Installing FOG using the github method is preferred over downloading the tarball and installing it that way.
5. FOG 1.4.4 is now old. FOG 1.5.0 is the latest release, with 1.5.1 being actively worked on. If you use the github process upgrades are quick and easy.

Below is the recommended way to get the FOG install image.
NOTE: The fog server must have internet access for this process to work successfully.

sudo apt-get update && apt-get install git

sudo -i
git clone https://github.com/FOGProject/fogproject.git /opt/fogproject
cd /opt/fogproject/bin
./installfog.sh

To upgrade FOG the process is:

cd /opt/fogproject
git pull
cd bin
./installfog.sh

The FOG installer will use all of the answers you previously provided when upgrading FOG.

@callumhird said in Best way to utilize FOG_1.5.0 on LAN:

so we can install all the required software from our file servers

I would challenge you, that you don’t “need” to connect to the domain to map a drive to your file server to install software. If there are applications that require AD credentials to install, then those should be installed post imaging via a snapin or some other software deployment tool like PDQ Deploy.

The only software that I “must” install after imaging is our antivirus software because that application creates a unique GUID when its installed to identify the machine to the AV console. its not possible to clone a system after AV is installed because of this. But most all other applications can be installed before imaging without AD rights.

@callumhird said in Best way to utilize FOG_1.5.0 on LAN:

Can anyone attach a unattend.xml they have that works perfect that i can tweak?

Here is a good place to start if you need a generic unattend.xml file: http://windowsafg.no-ip.org/

@callumhird said in Best way to utilize FOG_1.5.0 on LAN:

this required us to drop PCs off the domain when “taking” an image

This makes me think you are doing something different than traditional MS style imaging. Its best practices to never connect your reference image to AD before sysprepping and image capture. What is your logic to connect to AD during reference/golden image build up?

In my comapny’s case we use MDT to build the reference image so its consistent each time we recreate the reference image. There is no need to connect the reference image to AD for anything during its build out. Actually by not connecting to AD it avoids any GPO policies from being applied and breaking imaging.