Thanks for posting back what ended up fixing it.

I have seen that sometimes some things don’t install properly.

Over the last few days, it seems people who are having problems simply re-run the installer and they’re good to go after that. I don’t know why.

I haven’t seen it so much in 0.33b but that’s not to say it won’t happen once we release.

None of the machines were able to be queued!
[ftwlx132] Unable to connect to tftp server.

Hi,

As has been said above, Ubuntu is Debian with newer versions of some stuff, a different install program and a pretty desktop.

I’ve had what you experienced happen on one of my machines when I installed a different desktop. I installed something that hadn’t been Ubuntu-customised and that caused the boot screen to revert to the original one it had before Ubuntu applied their look. Is it the boot screen that has changed (the one that shows up when you turn the machine on) or the login screen (the one you type your password into)?

There’s almost certainly nothing to worry about. Nobody has compromised your box.

Awesome, glad to have been of some help.

The issue I think, is not with the image or deploy. I think it’s more related to the GRUB and MBR file.

You’re systems aren’t booting because they don’t know where to look at the hard drive for the information, so they just reboot, and the cycle keeps happening.

Thank you for the replies! The “server” I currently have it on is an old PC whereas I have a new server to implement Fog because I love it so much! The old PC was tampered with and the install of Ubuntu is clobbered. I’m not that ubuntu savvy but when I left the server was functioning fine, when I come back it locks up at boot. I have the new server anyways so I really don’t think it’s wise for me to search the forums day in and out to try and figure out the issue with it.

I’m sorry I didn’t read -.-

The setting should be under the video\display settings on that virtual machine and should be a value you can increase. Sorry for not knowing exactly where, we are a VMware shop here, but there aren’t many differences between settings on a VM with the type 1 hypervisors.

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,