Posts made by mr626

I’m trying to start work on this, but I could use a hand in understanding how fog operates.

I can see in the ‘default’ file that holds the configuration for the fog pxe menu that different fog functions are called from the menu like so:

[CODE]LABEL fog.quickimage
kernel fog/kernel/bzImage
append initrd=fog/images/init.gz root=/dev/ram0 rw ramdisk_size=127000 ip=dhcp dns= mode=quickimage keymap= web=192.168.1.1/fog/ loglevel=4 consoleblank=0
MENU LABEL Quick Image
TEXT HELP
This mode will allow you to image this host quickly with
it’s default assigned image.
ENDTEXT[/CODE]

In the above example, the ‘mode=quickimage’ is obviously what determines how fog will operate when that menu item is selected. What I’m not clear on is where the underlying code is located that receives this argument. In theory, we can then write a function for renaming the host (probably re-using lots of code from one of the existing functions, as we’ll be accessing similar parts of the fog database). Then, we can simply add a new entry to the ‘default’ pxe menu config file with ‘mode=renamehost’

For the time being, I’ve left a grep -iR command running to see if I can find the code myself

Cool, well I’m glad I’m not the only one who would value this.

Depending on my workload I’ll attempt to start work on this soon.

We get a lot of those kind of ‘no chip’ messages when using FOG on several of our Dell desktops. They’ve never stopped anything from working however so I tend to just ignore them

Hello,

Would it be possible to have a ‘rename host in FOG’ option on the PXE menu?

This would be really handy for us, mainly because our naming convention for computers reflects the physical location of the machine within our organisation. So, when I decommission / redeploy machines if I haven’t remember to edit or delete them in FOG first it can cause problems when I try and register them with FOG again.

A few times I have been re-deploying old machines that already exist in the FOG database, and I can’t remember if I previously deleted them from FOG when they were deployed elsewhere (and had different hostnames). When I boot into the FOG menu and attempt to register the host with FOG, FOG correctly tells me that it can’t register the host, as there is already one with the same MAC address in FOG.

What would be great is at this point, rather than just rebooting, if there was an option to change the hostname in FOG.

I appreciate that the FOG devs are probably already quite busy, so I’ll probably attempt to add this functionality myself. Would anyone else find it useful?

I’d rather not- it contains a lot of things like server names, ip addresses etc that relate to my organisation and it would take me ages to strip them all out. Sorry.

What I’ve already posted should be plenty to go on- it contains all the relevant information. You can see that in my configuration, the extendospartition happens during the ‘specialize’ pass, but from what I understand it can be run in some of the other passes too if for some reason that suited you better.

The technet link I posted mentions the component that contains the setting in Windows System Image Manager, which allows you to add the extendosparition to your unattend.xml

Found out how to have the partition extended to cover the whole disk via this thread:

[url]http://fogproject.org/forum/threads/resizing-partition-with-windows-7-image.250/[/url]

[quote=“Stephen Perkins, post: 1332, member: 501”]If you are syspreping your windows partition in the XML file you can set it to expand disk to full. That is what we do for our images which only contains one image. The Settings Pass “specialize” then
<ExtendOSPartition>
<Extend>true</Extend>
</ExtendOSPartition>
Hope that helps others :)[/quote]

Many thanks, I can confirm that this works. Here’s another reference:

[url]http://technet.microsoft.com/en-us/library/cc766473(v=ws.10).aspx[/url]

I didn’t have any luck manually entering it in to my unattend.xml so I ended up using the Windows System Image Manager to open the xml and add it that way (I’m sure you can add it manually, but I must have been doing something wrong).

Anyhow, here’s an extract from my unattend.xml with the relevant info:

[CODE]
<settings pass=“specialize”>
<component name=“Microsoft-Windows-Deployment” processorArchitecture=“x86” publicKeyToken=“31bf3856ad364e35” language=“neutral” versionScope=“nonSxS” xmlns:wcm=“http://schemas.microsoft.com/WMIConfig/2002/State” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”>
<RunSynchronous>
<RunSynchronousCommand wcm:action=“add”>
<Order>1</Order>
<Path>net user administrator /active:yes</Path>
</RunSynchronousCommand>
</RunSynchronous>
<ExtendOSPartition>
<Extend>true</Extend>
</ExtendOSPartition>
</component>
[/CODE]

Update- choosing the ‘non resizable’ image type fixed the issue. I have been able to successfully deploy the image on two different machines.

Next up is to work out how to have the image use the entire disk via sysprep. Any pointers on this one?

Thanks guys

That’s news to me about the 100mb partition being expected by FOG for a single partition type. I’m sure that when I started looking at Windows 7 deployment via Fog, the general consensus was that if you wanted to have a single, resizable partition you needed to ensure that your Windows 7 image was a single partition. When did this change? Is it documented somewhere?

For what its worth, there’s nothing wrong with running Windows 7 without the 100mb partition- it isn’t like you are using a hack or something that will make the installation unstable. If when installing Windows 7 a ntfs partition already exists that takes up the whole disk, Windows 7 will happily install on that.

Thanks for the suggestions. I guess I can try a non resizeable image and then do the resizing via sysprep mini setup.

Hi guys,

I’ve started work on my Windows 7 soe. I’m creating it on a virtual machine, and occasionally uploading the image to Fog at various points to test it on some physical machines.

I have just attempted to deploy the image to a Dell Optiplex gx745. The image deploys fine, but on first reboot instead of starting the sysprep minisetup like it should, it just says ‘operating system not found’

Some info about my setup:

The windows 7 image is created as a ‘NTFS Only, resizeable’ image (I made sure that during initial install of Windows 7 I only used 1 partition, so there is no hidden 100mb partition to worry about). The virtual machine that I am creating the image from has a 40GB virtual disk. I run the fogprep tool before capturing the image.

The client machine I am deploying fog to is a Dell gx745 with an 80gb hard drive. In Fog, I’ve changed the host os for this client to be Windows 7. I’ve tried both ‘normal’ and ‘legacy’ options for sata operation in the bios.

Just not sure why it isn’t working. Any suggestions?

Thanks

A follow-up for those interested.

Re-uploading a fresh SOE image to Fog solved the issue: once I had done that it was fine. Still not 100% sure why I had the issue with restoring the image files I restored from backup, but maybe it could be related to the following…

I use the standard Fog backup script, which does a good job of getting all the important stuff. One thing it doesn’t backup by default though is the /tftpboot/ partition. Now, you don’t really need to back this up unless, like me, you have made changes to anything pxe-related.

In my case, I had applied the chainloading fix described here:

[url]http://fogproject.org/wiki/index.php?title=FIX:_Chainloading_alternate_SYSLINUX_to_force_boot_from_first_hard_drive[/url]

Of course, that was ages ago and I had forgotten about it…until all of our newer Dell machines (optiplex 790) started rebooting when they tried to load the pxe boot menu Once I reapplyed the fix it was fine though.

The end result is that I manually added the /tftpboot/ partition to my fog backup scrupt, just to make things easier next time I have to do a restore (hopefully not for a while!).

Hi,

A few questions:

-What particular version of ubuntu are you using?
-What software did you choose to install during OS installation? (eg I usually choose the LAMP option during installation)
-Have you checked the logs relevant to apache?

Obviously, apache isn’t able to start for some reason. I’d be tailing the relevant log files (/var/log/messages, /var/log/apache/error.log etc) and manually attempting to start apache (/etc/init.d/apache2 start) and see what the log output is.

If needed, you can edit the httpd.conf file to make apache logging more verbose. Search for ‘LogLevel’ and set it to ‘Info’ (it will probably be on ‘Warn’ by default). Make sure you keep an eye on log file disk usage though, as apache will be spitting out much more log info than normal with this setting.

Other than those suggestions, I can’t think of much else without extra information on your part- all I can tell from you above post is that some undetermined error is stopping apache from working).

Hope that helps.

A quick update- as a test I uploaded an image of a computer I had in my office (IBM T60 laptop) to a brand new image file I created via the web interface. I then restored the image back to the laptop, and it worked perfectly- no hal.dll missing error.

So, obviously there is something wrong/missing from the image file I restored from backup although I’m not sure what. I’ll proceed to re-upload the image of our main SOE from my SOE building machine and see how that goes. A few pieces of software needed updating anyway, so no big deal

Hi all,

Firstly, thanks for the work that has gone into the new forums. I’m sorry that it took a problem with FOG for me to finally sign up to the new one.

Here’s what happened to leave me in my current predicament:
[LIST]
[]A couple of days ago, the hard drive in our fog server failed (a 500GB Seagate ES drive). Although inconvenient, I of course had backups so it wasn’t the end of the world.
[]I installed a new hard drive in the fog server (2TB Hitachi), and proceeded to reinstall the operating system (Ubuntu server 10.04.3 32 bit- the same as the fog server was running previously).
[]I then installed Fog 0.32 (same as I was previously running).
[]Once I had verified that the fog installation was working, I then proceeded to restore my backups. I had backups of the following: the snapins, the image files, the fog.sql database file.
[]After restoring my backups, everything seemed to be back to normal. The fog web interface showed all of my clients, snapins and image files
[]As a test, I tried running memtest from the fog pxe menu on a client. This worked perfectly. I then tried to register a new client via the pxe menu, this also worked perfectly
[]Finally, I attempted to re image a client using our main SOE image that I had copied over from backup. Everything appears to go fine, right up until the client reboots after the imaging is complete. The first time it attempts to boot into Windows, the following message appears: “Windows could not start because the following file is missing or corrupt: <windows root>\system32\hal.dll. Please reinstall a copy of the above file”
[]I have tried on two different machines (different Dell GX620 and GX280) and the result is the same- the image is deployed fine, but on first reboot you get the missing hal.dll message. Both these machines worked perfectly with the same image prior to the fog server crashing and being rebuilt.
[/LIST]
Is it possible that there is some setting I have missed that would be causing this to happen? Any other possible causes for this behaviour? As mentioned, the image I am restoring is our main SOE image that I have restored from backup, that previously worked perfectly on all our machines.
One thing that I will try today is uploading a new copy of our SOE image from my SOE building machine, so I can test if it is a case of there being something wrong with the image file that I restored from backup.
Thanks in advance for any help you can offer, if you need any additional information to help me work this out please let me know.