Best posts made by george1421

@developers Here’s the final update on this issue.

I reset my kernel build environment and then created 2 new kernel builds. The first was to remove the imposed CPU limit on the linux kernel this kernel was called bzImageMaxCPU. I reset the kernel build environment and then went through the ACPI settings turning on what I turned on in the debug kernel. This kernel was called bzImageACPI.

The OP tested both and the bzImageMaxCPU was the only kernel that booted on those Dell servers. So in the end @Quazz was right about the CPU not liking some of its cores disabled.

So I would recommend that we add the following settings to the official kernel build

CONFIG_INTEL_IDLE
and
Processor type and features —>

We have seen a recent uptick in reports of rcu_sched stalls with kernel panics Maybe we are running into this issue more often as the core counts go up on these processors.

@TTellez said in Cloning only installed files VS entire drive?:

…but do it with “Single Disk - Resizable” chosen just as a test to see what it would do differently.

That is the right choice. Just make sure you are on FOG 1.3.5 (stable) since the developers put a ton of effort between 1.3.4 and 1.3.5 to get the resizeable bits working well for all disk formats.

FWIW: You have to capture it in the resizeable mode to get it to expand/contract correctly on the target machine.

@zclift15 That’s not the same error log as your picture. I see the php warnings about ftp (that is something else that needs to be addressed). What the devs will be interested in is the PHP Fatal error at 11:46 it may be nothing but it also could be something. Fatal generally means something bad.

You need more details here.

Where is the iSCSI target? What are you using it for? Will this iSCSI target be for the deployed client or used by the FOG server.

The short answer is probably because its a block level device, but it depends.

The FOGImageReplicator is run as a service not a cron job. Look in the /etc/init.d directory for the service descriptor. (next is going to be a rhel based command) Run the chkconfig FOGImageReplicator --list to show you if the image replicator service is set to auto start. Under debian based systems chkconfig may not be installed by default.

In fog Groups are used to set properties on the members of the group. So to your answer the last value set wins even if the host is a member of 100 other groups.

@zclift15 said in 1.4.1 Unable to register host (/bin/fog.man.reg):

PHP Warning: ftp_rename(): Rename failed.

As for this one. Where we typically see this error is if someone mucks about with the FOG service account. This is a linux account called fog. The installer manages this user account and password. The linux user fog (not the same as the web gui admin called fog) is used by FOG to move files around on the FOG server after image capture. The linux account password needs to match the password defined in the gui configuration for the storage node. If these are out of sync you will get the ftp errors like in your log.

First let me say that I’ve only used clonezilla for DR purposes (image->archive and then archive->bare metal on DR). So I can’t speak too much on using clonezilla for image deployment. I believe that if you use a clonezilla server you can do multicasting as well as unicast deployments. But again my use of clonezilla is very narrow and specific. How we use clonezilla would be more closely equivalent to how we use Ghost back in the day.

With WDS I’ve used it many years ago and it worked but quickly moved beyond it to just using ghost and then FOG in the early days of FOG circa 0.29-0.31 and now 1.2.0++. I do use MDT today to create the reference images that we capture with FOG. With MDT I can create the same exact image each time in an unattended manner and then capture with FOG for image testing and deployment. In our current environment we recreated our reference image each quarter with the latest OS updates and application patches. This is all done by MDT.

For FOG, the developers are trying to expand a bit beyond just image deployment to more of image management. I would equate where I see (from the outside) where FOG is going to be a bit more like what Altiris is (use to be). FOG is moving more towards system management not only for deployment but post deployment with snapins (application installs) and workstation inventorying (FOG 2.0).

I can say that FOG is much faster at target image deployment than WDS/MDT. FOG uses a block level disk copy where WDS/MDT uses a file level image copy. This makes FOG much faster to first target image boot than WDS/MDT. FOG also supports multiple operating systems (much, much more than WDS).

FOG is also extendable in that is open source software that can be used out of the box or functions can be added by the end users or 3rd party developer because the source code that makes up FOG is always available.

With FOG you can setup a pretty complex master node, storage node schema for your entire organization. Where you will have to go to SCCM to get a similar deployment environment with Microsoft products. You have to also realize the management/skill set overhead with going with SCCM vs WDS vs FOG.

With FOG you don’t need a MS Windows ecosystem in place to use it. For example if you are 100% Mac shop, why would you set WDS to deploy your Mac images (even if that is possible). For FOG image deployment you don’t need to burn a windows server license too to install your imaging management software.

You touched on one of the great points about FOSS software, the support community. Think about it, through the fog forum you could have immediate contact with one of the developers of the software. If you are running into issues deploying to a specific hardware you have someone you can reach out to for assistance. With the big software company you have no chance to talk with the developers of the software. The FOSS developers aren’t building wonderful things for money (it would be nice if they could at least pay the light bill through donations) they create this software because they love to code, to do something better and faster than someone else, or because it hasn’t been done before.

I realize there may be a language understanding issue here, but could you explain this statement

i cant register every host to take a image.

Does that mean:

1. You physically can’t register the machines (i.e. fog 1.2.0 is broken)
2. You do not want to register the machines in that volume on a per day basis because it is too labor intensive

Version 1.2.0 is really different than 0.32, its more of a fork of the original FOG project. The newer version of FOG gives IT support much more control over the client than 0.32 ever supported. That additional control does come with some requirements I do have to say. To answer your question, is there a way to make 1.2.0 work like 0.32 does? The short answer is no, but you can get close.

In the FOG PXE boot menu there is an option called Quick image. This is similar to a load and go for deployment. You only need to supply a user ID and password (to avoid unintentional image deployment) and then select the image you want to deploy. This will install the image without needing to register the system with FOG. But by doing it this way you are missing out on a lot of function in the new FOG.

@zclift15 said in 1.4.1 Unable to register host (/bin/fog.man.reg):

@george1421
ddeatrich was the one who posted that

Sorry only looked at the color of the icon not close enough. Sorry.

Then the second post was directed at you about the FTP issue.

@adukes40 yes, that what ever was in the unattend.xml file is overwriting the registry. That sounds logical to how a sysprep’d image would work.

One might think that the following sed magic would change that computer name * to something FOG could manage. Where $unattendfile would be the full path and file name of the unattend file. One could slide that in a existing post install script or make a new one call fog.sethostname. Then you wouldn’t need the fog set host function at all.

 sed -i -e "s#<ComputerName>\([^<][^<]*\)</ComputerName>#<ComputerName>$hostname</ComputerName>#gi" $unattendfile

@thomasdec Hey, I’d just like to thank you for hanging in here with us. We really need to get to the root of the issue with these “broken” efi firmware. Its not really broken, there is just something that iPXE is not handing off correctly under all efi firmware. Most efi firmware works correctly, there are a few systems that it is not. To get to the root of the problem we need people like you who are willing to hang in there with us to see if we can pinpoint the conflict.

Again I’d like to say thank you for helping with the try this, change that process. In the end this info will help the iPXE project as well as the FOG project to deliver a better product.

@ddeatrich said in 1.4.1 Unable to register host (/bin/fog.man.reg):

ftp_rename(): RNFR command failed

Interesting you also have an ftp issue (probably related to that linux fog user). This is the command to rename an image after capture.

Uncaught Error: Call to a member function lastInsertId()

And equally as interesting this error. I’m sure I’ve see this error in the last 24 hours in another thread too. That user was using cento 7.

I’m still in the process of building a new fog server. Its almost done installing centos 7. Once updated I’ll install fog and test it out.

Can you explain what you mean by managing these items?

Unless you are in a workgroup environment, these items are best managed via AD/GPOs. If you are in a workgroup then you can deploy a vbs/ps script to create these items. But for AD a GPP is the much easier way to go.

@saif said in host restarted when deploy image:

@george1421 yes its built in RAID, i will try to boot from live linux and check
BUT why do i need a RAID driver under windows? the FOG will make a clone for the volume and the windwos will not start to use this driver

Sorry I should have explained my self a little better. There are 2 main types of raid controllers (generally) and one hybrid. There are hardware raid controllers, software only raid controllers, and then hybrid raid controllers.

The more common is a hardware raid controllers where it has its own microcontroller that manages the disks. It runs its own special software and then presents the disk array to the operating system or bios as just a single disk volume. There are software raid controllers that typically function as part of the OS. You will find this type of raid controller in higher end unix systems. The software only raid controller us all done in the OS and uses the main processor to manage the disks. The last type is a hybrid raid. In that some of the disk control functions are done in hardware and some in the OS software, this kind of gives you the best of both worlds. You will get some performance acceleration with the hardware without the expense of having a dedicated raid microcontroller. The hybrid raid is managed by the OS so it requires to OS to maintain the integrity of the raid. Without the OS you have no raid functionality.

So with the T3500 they have the hybrid raid setup that comes with a windows driver. To linux (or actually windows without the software raid driver) your raid array looks just like a just a bunch of disks (jbod). Individual disks with no real structure, and in your case since they are in a raid 5, no intelligent data because of the disk striping.

While I can’t speak for the FOG developers, but cloning this type if disk structure is beyond the scope of the fog project.

@Olduser If it was me, I would create some conditional tests.

Does the S: drive exist
Does the user account running this batch copy script have user rights to S:
Does the path S:\PAT exist
Does the file tdpunt.bat exist in the path S:\PAT
Does the C:\Temp path exist, if not then create it
Write the negative results of your tests to a log file in C:\Temp to help you figure out what went wrong.

@lawrence1997 First I have to say I don’t know ubuntu. But it looks like from the error message that Apache 2.4 isn’t available for LTS 12.04. With that said a quick google search found this article.
http://stackoverflow.com/questions/21390544/installing-apache-2-4-and-php-5-5-on-ubuntu-12-04

Look at the accepted post. Install apache 2.4 using this method and then rerun the installer. I can’t say if this is a bug in the fog installer or just because LTS 12.04 is old and apache 2.4 is not available from the OS dev team.

If you setup a debug capture/deploy and then pxe boot a target computer, after a few presses of the enter key on the target computer you will be dropped to a command prompt on the target computer. This is the FOS command shell.

If you key in lsblk it will show you the block structure of the disks that are seen by the OS.

I would suggest that you upgrade to RC5 on all of your storage nodes and your master node. Then we can check into this more. I know there have been about 40 fixes since rc1.

FOG current does not inventory software. That is something that was talked about for FOG 2.0. But it also brings into question what is the focus of FOG. Is it an imaging tool or a system management tool that also does imaging. The point being the direction for FOG hasn’t been defined just yet.

If you are looking for a really nice and free software to inventory your campus then look at Spiceworks (the application). This tool is really mature and just works. If you are only interested in software inventory and possibly application deployment then I might suggest PDQ Inventory and PDQ Deploy. They have free versions, but the paid for versions are well worth the minimal cost.

For software license management I would again look at Spiceworks.

If I was setting up a SMB, and needed affordable tools, I would go with Spiceworks for helpdesk, hardware, software inventory, purchasing, PDQ Deploy for software deployments (which can hook into FOG) and or PDQ Inventory for software inventory (the paid for versions allow you to create software policies) , FOG for imaging, then a few free tools from Netwrix, ManageEngine, and SolarWinds to fill in the gaps.