Agreed, worse comes to worse, also check the apache error logs during startup as it is referencing php files.

It is a good idea to create master images on “tiny” drives and have either a script resize the final (or OOBE in windows do it). I always create my golden images in a VM with jsust enough HDD space to do what I want (I expand the drive if the image gets bigger). That way you can use whatever size final drive you like.

You can always script extra partition creation too. I have a script that resizes and creates an extra partition and moves a folder into that partition for my W7 images. That way I can use smaller drives as appropriate.

It seems my old kk20 account was deleted for being a “spammer”. Great as I had quite a few fixes posted under that username (from when I installed fog) and had never spammed in my life… oh well.

anyway I am revisiting this as I have moved my FOG to a new server and came up with the same error, luckily someone had “quoted” my original fix so I could look in the post_stage2.php file for changes I made (and I had commented them! yey!). Here is the change I made to post_stage2.php

this line:

[B]$dest = $noderoot . $_GET[“to”];[/B]

I changed to

[B] $dest = “/raid6/data/FOG/” . $_GET[“to”];[/B]

It seemed that the $noderoot was somehow incorrect for me. No idea why as it was only the final FTP that failed for me. Anyway, after hard coding my FTP location (not ideal but I needed a quick fix rather than a debug) this works fine for me and has done for years.

for information, /raid6/data/FOG is my listed NFS share in FOG (which also has FTP share enabled in openfiler). I have no idea why the $noderoot does not work yet everything else does. Anyway, that single change in post_stage2.php fixed my final FTP issue (so no more manual image moving necessary!)

Well, went back to the drawing board. Created a new VirtualBox server running Ubuntu 10.04 and installed Fog 0.32. Having run the install again, I realized that I had to have deviated from the standard installation instructions at least twice over username/password instances. Noting this, I did a trial run and was able to successfully do everything PXE-related (Memtest, Register, etc.). I followed the instructions for Uploading an image and was able to do so on the 1st try.

With this success in hand, I went back to the physical server and removed Fog following the instructions here:
[url]http://www.fogproject.org/wiki/index.php/Uninstall_FOG[/url]

Reinstalled Fog on physical server and voila! Happy image uploading. 🙂

well, without LVM, no, if you have a separate dir… it’s gonna get annoying for NFS… and using a storage node is probably not a good idea.
But copying data over to the LV, then umounting /images, remounting the LV on /images, then lvextending, that’s less than a minute of downtime if done properly… 🙂

I can now register and uploading an image seems to be working but it’s going very slowly. After about an hour, it’s only 5% uploaded where normally we would be close to half way.

When will .33 be available for upgrade?

Yep,

I’ll bet it’s in GPT as I stated before.

sorted it thanks guys, Stopped the WDS service for a starting. Then realised I had the DNS server setting in fog set incorrectly. Rebuilt Linux and reinstalled Fog correctly (

This is a known issue with tftp-hpa service and Ubuntu 12.04.

Horray! It works perfect.

Thanks!

Found some software on the master for making recovery discs. Sorry for not looking for this sooner, I’m looking over the mountain instead of at the base.

If these work, I may remake the image quickly on the second to have an image.
Still wondering what Panasonic has on these causing fog to think the File Table is corrupt.

Thank you Tom.

Also, almost relevant for how I feel:
Quote from Simpsons, Ned Flander’s Mother:
[QUOTE]You gotta help us, Doc. We’ve tried nothin’ and we’re all out of ideas.[/QUOTE]

That is correct Tom. Will try redownloading

Alright, now I have my own switch A Netgear prosafe GS108E. I’m hooked up to it, but when I try now to start the isc-dhcp-server, it gives me the error:
[CODE]Starting ISC DHCP server: dhcpdcheck syslog for diagnostics. … failed!
failed![/CODE]
And in /var/log/syslog I have
[CODE]No subnet declaration for wlan0 (10.247.57.50).
** Ignoring requests on wlan0. If this is not what
you want, please write a subnet declaration
in your dhcpd.conf file for the network segment
to which interface wlan0 is attached. **[/CODE]
I don’t want wlan0 at all. I want it to use eth0.
In my dhcpd.conf file, I have:
[CODE]GNU nano 2.2.6 File: dhcpd.conf

DHCP Server Configuration file. see /usr/share/doc/dhcp*/dhcpd.conf.sample This file was created by FOG

use-host-decl-names on;
ddns-update-style interim;
ignore client-updates;
next-server 10.126.6.26;
subnet 10.126.6.0 netmask 255.255.255.0 {
option subnet-mask 255.255.255.0;
range dynamic-bootp 10.126.6.10 10.126.6.254;
default-lease-time 21600;
max-lease-time 43200;
option domain-name-servers 10.98.1.1;
option routers 10.126.0.1;
filename “pxelinux.0”;
}[/CODE]
I’m not quite sure what to do from here.

THANK YOU VERY MUCH.
I was able to register the laptop. Now I have to test uploading the image.

Thanks again,

Tom

It is working now, and I have been told it is a cabling issue. I can’t see why, as the cable works fine, but I have been told to stop questioning it and just accept it will work where it is now and not where it used to be.

Thanks again for the help.

I look forward to using the new version in the future. It sounds like it will be vastly superior to .32.

The problems with my drive are largely due to the fact that it’s an advanced format drive. Even the Windows 8 recovery partition won’t work because it was created on a non-AFD disk. Also my laptop is 64-bit but my desktop is 32-bit so I can’t simply create an install disk from the windows 8 installer. Ugh!

FOG, however, has performed very well. This little adventure has helped me test out version .33b so when we do upgrade I the server at work I know what to expect. At present my plan is to wait until it’s finalized. Since we have about four spare computers (and only need about that many images) at work recreating reference images is not much of an issue. My main concern is for the FOG database since rebuilding it would require going around to the public computers. Is it possible to copy the database, store it somewhere, and then put it back on the server when version .33 is installed? Or is the best way to upgrade simply to have two servers? Note that we do not have any FOG server as of yet, although I do not want our big Windows 7 roll out to be dependent on software which is still in Beta.

Thank for letting us know, I lost internet while trying to get caught up on these posts O.o

The proxyDHCP service added from the dnsmasq, only doles out ip addresses when booting the pxe information. Any ip address given to the machine is temporary and will be removed when it moves from the pxe boot screen, i hope this will help to appease the higher ups.

Tom is correct, there currently aren’t any downloads for a USB version of FOG, however Tom and I recently helped someone to do something similar… [url]http://fogproject.org/forum/threads/fog-image-choice-with-usb.10015/[/url]

He wanted do do EVERYTHING from the usb drive almost like the usb drive was a mobile fog server. I feel it’s better to have a server as you can store a number of images and revisions of those images and you can deploy/revert to them at any time, I only feel a USB option would be acceptable if you had only one make an model of a machine, or a golden image for ALL machines in your area.

I personally, don’t feel that the USB option is that good of an option… if I want to carry a device with me I would go back to using clonezilla.