Thanks for all the help.

My first image is deploying on the server i built from scratch. 😄

[quote=“Bruce D, post: 31695, member: 24717”]Also recommend that the 50-Gb root partition issue in CentOS be discussed, and instructions be added to move the images directory to a larger partition as part of the installation instructions, to avoid the likely issue of someone trying to upload an image bigger than 50 Gb to the root partition.[/quote]

This “50Gb root partition issue” as you state is not really a FOG issue, but rather an issue with CentOS itself. This isn’t something any of the FOG developers opted into. How can we fix something we have NO control over? What’s your recommendations on how the FOG developers can fix this issue? I’m not trying to say you’re wrong that it is an issue, but it’s not something we have any type of control over.

[quote=“Bill G., post: 34965, member: 24757”]WOW! Kudos to everyone who participated in making FOG version 1.2 so quickly. My Linux image has worked flawlessly with various size hard drives. I’m new to the open source community and I’m totally impressed… thank you![/quote]

Glad we could be of help.

[quote=“x23piracy, post: 34648, member: 3982”]Hi,

if so the wiki should not recommend ubuntu anymore:

[IMG]http://i.imgur.com/CKoow6J.png[/IMG]

Regards X23[/quote]

Removed the (Recommended) parts from this page.

Thanks.

I decided to forgo the surface scan for now.

The multi-partition image is currently uploading.

I appreciate the help and thank you both for your time.

Is it reporting, Console error, then the IO error?

Ben ensure your php.ini file has your timezone defined, ubuntu location is "/etc/php5/apache2/php.ini
date.timezone = “Europe/London”

Timezone list can be found [url]http://php.net/manual/en/timezones.php[/url]

also ensure you have a daily cron for an ntp update

[FONT=Helvetica Neue][COLOR=#000000][SIZE=14px]create a file/etc/cron.daily/ntpdate containing:[/SIZE][/COLOR][/FONT]
[FONT=Helvetica Neue][COLOR=#000000][SIZE=14px][/SIZE][/COLOR][/FONT]
[COLOR=#000000]ntpdate ntp.ubuntu.com[/COLOR]
[COLOR=#000000]sudo chmod 755 /etc/cron.daily/ntpdate[/COLOR]

One thing I just noticed, the timestamp on your tftpd entries in syslog are all really weird, I’m not sure why, and I don’t see how it could cause a problem, but it is odd.

I’ve now added the ability to add “individual” password login settings to menu items
My current menu that is tested and working, although very minimal, is:
[code]isset ${userID} && goto do_me || goto MENU
:do_me
kernel bzImage root=/dev/ram0 rw ramdisk_size=127000 ip=dhcp dns=10.10.10.1 web=10.10.10.118/fog/ consoleblank=0 loglevel=4 type=down img=win7actsysprep ftp=10.10.10.118 imgType=n osid=7 storage=10.10.10.118:/images capone=1 imgFormat=0
imgfetch init.xz && boot || goto MENU
:MENU
menu
item --gap Please Select one of the images below
item fog.local Boot from hard disk
item d101_64 D101 Base Image (64 bit load)
item return Return to main menu
choose --default fog.local target && goto ${target}
:fog.local
sanboot --no-describe --drive 0x80 || goto MENU
:d101_64
chain -ar ${boot-url}/service/ipxe/advanced.php?login=1 || goto MENU
:return
chain http://${fog-ip}/${fog-webroot}/service/ipxe/boot.php?mac=${net0/mac} || goto MENU
autoboot[/code]

Notice the :d101_64 how it has the [B]chain -ar ${boot-url}/service/ipxe/advanced.php?login=1 || goto MENU[/B] ?That’s all that’s needed to have a “login” for your menu item. Notice the top where it says :do_me? This is important to note that it’s ABOVE the menu generation part of the advanced menu setup.

As I stated, this is very basic, but a method to :sort: the different functions could be:
[code]isset ${userID} && iseq ${bootnum} 1 && goto do_me ||
isset ${userID} && iseq ${butnum} 2 && goto do_me2 ||
goto MENU
:do_me
kernel bzImage root=/dev/ram0 rw ramdisk_size=127000 ip=dhcp dns=10.10.10.1 web=10.10.10.118/fog/ consoleblank=0 loglevel=4 type=down img=win7actsysprep ftp=10.10.10.118 imgType=n osid=7 storage=10.10.10.118:/images capone=1 imgFormat=0
imgfetch init.xz && boot || goto MENU
:do_me2
kernel bzImage root=/dev/ram0 rw ramdisk_size=127000 ip=dhcp dns=10.10.10.1 web=10.10.10.118/fog/ consoleblank=0 loglevel=4 type=down img=blahblah ftp=10.10.10.118 imgType=n osid=7 storage=10.10.10.118:/images capone=1 imgFormat=0
imgfetch init.xz && boot || goto MENU
:MENU
menu
item --gap Please Select one of the images below
item fog.local Boot from hard disk
item d101_64 D101 Base Image (64 bit load)
item return Return to main menu
choose --default fog.local target && goto ${target}
:fog.local
sanboot --no-describe --drive 0x80 || goto MENU
:d101_64
set bootnum 1
chain -ar ${boot-url}/service/ipxe/advanced.php?login=1 || goto MENU
:d102_64
set bootnum 2
chain -ar ${boot-url}/service/ipxe/advanced.php?login=1 || goto MENU
:return
chain http://${fog-ip}/${fog-webroot}/service/ipxe/boot.php?mac=${net0/mac} || goto MENU
autoboot[/code]

FWIW, I’ve found htop to be a lot more useful than top.

i’ve heard of problems with some cards, that they have a power setting (configurable from windows) that will drop to 100m in low power mode, and may not come back out of it and into 1000m when booting into linux. but when booted into windows, they come back up to full speed. if you disable that setting in windows, the problem goes away completely.

Hi Tom,

Thank you.

I tried that and unfortunately, it doesn’t work for me. I checked the permissions for /etc/rc.local and tried using the full path name of service (/usr/sbin/service) to no avail. I would welcome your suggestions of what to try next.

Would it be possible for future versions of the services to syslog something meaningful if they die and try to respawn themselves a couple of times with a delay for each please?

Thanks,
Paul.

I run all my FOG servers as VMs, mainly in VMware ESXi or XenServer 6.2.

for 0.32 I had all Ubuntu but for 1.x.x I’m now using Debian 7 and it’s not been a problem at all. My virtualbox test clients boot loop but none of the physicals do the same…

You may be limited by your storage if you have lots of active VMs on the same SR/Datastore since disks only go so fast and aren’t the best performance for random IO. You may also get limitations on your network if you have active VMs on the same physical NIC… a 1gb link can be swallowed quickly while imaging.

everything depends how much performance you need, what hardware you have and how often you are going to be imaging.

There is something similar in the wiki: [url]http://www.fogproject.org/wiki/index.php?title=Error_Messages[/url]. Could you try what they suggest and see if it makes a difference? They are suggesting that there is a problem in the startup scripts for debian but that temporarily removing the fog startup scripts from /etc/init.d seemed to work.

I’m going to guess you named the system “fog” when you installed it?

CentOS 6.5 defaults the filesystem type to lvm disk management. The root partition is usually defaulted to a maximum size of 50 GB.

When FOG installs, it creates a directory in the root filesystem as /images which would be mounted on the root of the drive or / as you’re seeing.

If you need it to load to a different disk you can very simply. Just mv the /images to a folder on a filesystem that has much more space. My guess is /home in your case is also on it’s own filesystem labeled as:
/dev/mapper/vg_fog-lv-home.

thanks for your hints. finaly i could fix the problem, i had to reinstall libc6-dev

[FONT=Verdana][COLOR=#000000]apt-get install --reinstall libc6-dev[/COLOR][/FONT]

Yes editing fstab worked for exactly what i was trying to do.

It sounds like the problem is with the DHCP service rather than Fog. Your Fog install could be fine, but if there is a problem with DHCP your clients won’t even try to talk to fog.

One thing to try might be sniffing out some of the DHCP traffic on your network to confirm that it looks it should. Wireshark should help there. My hunch from what you say above is that your Citrix setup might have a DHCP service somewhere which is handing out DHCP leases in competition with your FreeBSD box. If that is the case, and your client gets it’s lease from that other DHCP server then it wont work.

In case anyone else is interested in doing this I’ve updated my instructions on the fog wiki to describe
[LIST]
[*][URL=‘http://fogproject.org/wiki/index.php/Include_SystemRescueCD’]how to include SystemRescueCD [wiki][/URL]
[/LIST]
You [I]can[/I] do it by just booting from the CD instead, but we found it a really handy addition for resetting admin passwords, fscking filesystems, recovering broken systems etc. so we put it into fog.