To my knowledge, ownership of these folders really don’t matter.

They’re usually given permissions of
[code]chmod -R 777 /images[/code]

However, it’s FTP that moves the file from /images/dev to /images.

Make sure your FTP username and password are correct.

[code]passwd fog[/code]

Set the password and make sure you set this same password under:

Storage Management->Storage Node->Management Username/Password and that it’s set under:
FOG Configuration->FOG_TFTP_FTP_PASSWORD

That should help you out.

Thanks for this post…its going to be useful very soon for me!
[quote=“danuel, post: 4659, member: 628”]Hi!

Finally! I can Deploy and Upload Caixa Magica and Ubuntu 12LTS.

My resolution:
MAKE INSTALLATION IN VMWARE MACHINE 🙂
…[/quote]

THANK YOU!! You helped a lot by posting the method you used, this helps brain dead zombies like myself, do the same for my setup!

Debug the install script, it probably fails somewhere here:

In file fog_0.32/lib/redhat/functions.sh
configureHttpd()

Maybe you just comment out the checks and make sure things are running as the script expects it

If you would read the post and he did not edited the post after your questions you could read: “After some searches, i could resolve the issue by restarting the nfs service… The portmapper caused troubles for me as well, so i include it here :”

You need to get your network admin to setup the network to allow multicasting across subnets see example here:-
[url]http://www.fogproject.org/wiki/index.php/Cisco_Multi_Cast[/url]

We fixed this by adding the following to our dhcpd.conf
[CODE]class “pxeclients”{
match if ((substring(option vendor-class-identifier, 0, 9) = “PXEClient”) or (substring(opti
filename “pxelinux.0”;
max-lease-time 120;
}
[/CODE]

Alright man,

Sorry I wasn’t able to help out too much but good luck. Maybe I can help with your other issues then.

The IOCTL error isn’t particularly important then. I see it with my home-made kernel because it has RAID drivers built in, but the devices don’t have raid drives. If you’re having issues with imaging a specific drive, it may point you in the right direction, but by itself it’s perfectly fine.

edit (nano or vi) " /etc/default/tftpd-hpa " and add “sleep 30” on the top line so it looks like :

[I][B]sleep 30[/B][/I]
[I][B]# /etc/default/tftpd-hpa[/B][/I]
[I][B]# FOG Modified version[/B][/I]
[I][B]TFTP_USERNAME=“root”[/B][/I]
[I][B]TFTP_DIRECTORY=“/tftpboot”[/B][/I]
[I][B]TFTP_ADDRESS=“0.0.0.0:69”[/B][/I]
[I][B]TFTP_OPTIONS=“-s”[/B][/I]

will have to restart the service or reboot

easy way of finding default gateway and subnet mask is to set the workstation to dhcp - wait until it gets and ip address - fo to the information - note down the dg and subnet - pop out to a terminal try pinging and address up the top or down the bottom of the ip range (to find out a address that hasn’t been allocated out) find a non responding address and use that along with the dg and subnet mask details… most if not all subnet masks will be 255.255.255.0 …

One of the things I’ve learned with building a custom kernel is to Read the friendly Wiki page or (RTFW) as other so like to display.

If you’re building the kernel on a 64 bit system, make sure your make commands are:

make ARCH=i386 <command>

So when you’re doing the menuconfig do:

make ARCH=i386 menuconfig

Then make your changes and save the new config.

Then when you create the bzImage file do:

make ARCH=i386 bzImage.

I would almost recommend making this an actual part of the WIKI rather than just a note, as it wouldn’t hurt anything to do this from any platform whether i386 or 64 bit.

Thank you,

Try this: [url]http://www.fogproject.org/wiki/index.php/Setting_up_ProxyDHCP[/url]

When you get to step 7, modify line [B]dhcp-range=192.168.1.10,proxy[/B] (almost at the end of the file) to match your DHCP server IP address (dhcp-range=x.x.x.x,proxy).

This is a solution when you cannot -or you don’t want to- modify DHCP options 66 and 67. I have it working this way because options 66 and 67 are already busy.

Don’t think there’s a way to do it with “chain.32”. I found other references to “pxechain.com” from the linux utilities.
I added the following and it seemed to start booting but unfortunately didn’t boot WDS:

LABEL Windows Deployment Services
kernel pxechain.com
append IPADDRESSGOESHERE::boot\x64\pxeboot.n12
MENU LABEL Windows Deployment Services
TEXT HELP
Loads the Windows Deployment Services Imaging Environment.
ENDTEXT

So I’m going to give up on this one and do what everyone else seems to have done.
Which is to put the linux boot files onto the WDS location and modify from there instead.
Reference: [url]http://www.syslinux.org/wiki/index.php/WDSLINUX[/url]

Actually, someone found this as well (multi-PXE boot) which I might try out first:
[url]http://www.vcritical.com/2011/06/peaceful-coexistence-wds-and-linux-pxe-servers/[/url]

OK it seems to be a grub2 issue, this thread explains it [url]http://fogproject.org/forum/threads/grub-issues-reboot-loop.3904/[/url]

view hidden files:

[CODE]ls -a

ls -al

ll[/CODE]

Turns out the power outage caused the original (physical) fog server to turn on when the power was restore. I arrive at this conclusion after I removed the network cables form the machine that fog should be on and stopped the another old virtual fog server on another, yet I was still able to PXE boot with fog. After calling the previous tech guy we came to the conclusion that the original fog server had to be on, and it was. It was a combination of miss-information and mother nature. I did find that the original fog servers mysql database was not running and I was unable to start it again. Now the virtual fog server is up and running fine. Thanks for the help and fast responses, sorry wasting your time 😄

I am having an issue where I can’t upload a duel boot system because the ubuntu system is a extended partition. Anyone have any ideas how to do that?

Lol, I found the solution on the first link after googling…

Move your FOG* files to another directory than /etc/init.d/, install you package, and then replace the FOG* files 😉

Awesome info Dustin! We use static IPs on our printers, but we have quite a few HP 4000 series printers, so this is good to know. Good find.