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.

Thanks for help.

[url=https://www.gclub88.com/play-on-website/][color=#FFFFFF]gclub online ผ่านเว็บ[/color][/url]

Hi, I have the same problem.
Ubuntu 12.04 with 0.32 is working fine, as soon as I put the upgrade 1.1.0 I have this error :

[ATTACH]981[/ATTACH]

I have double check the 066 and 067, 067 is undionly.kpxe.

Here is my ipxe boot.php :
#!ipxe
cpuid --ext 29 && set arch x86_64 || set arch i386
colour --rgb 0xff6600 2
cpair --foreground 7 --background 2 2
console --picture [url]http://10.6.2.102/fog/service/ipxe/bg.png[/url] --left 100 --right 80
:MENU
menu
colour --rgb 0xff0000 0
cpair --foreground 0 3
item --gap Host is NOT registered!
item --gap – -------------------------------------
item fog.local Boot from hard disk
item fog.memtest Run Memtest86+
item fog.reginput Perform Full Host Registration and Inventory
item fog.reg Quick Registration and Inventory
item fog.sysinfo Client System Information (Compatibility)
choose --default fog.local --timeout 60000 target && goto ${target}
:fog.local
sanboot --no-describe --drive 0x80 || goto MENU
:fog.memtest
kernel memdisk iso raw
initrd memtest.bin
boot || goto MENU
:fog.reginput
kernel bzImage32 root=/dev/ram0 rw ramdisk_size=127000 ip=dhcp dns=10.6.0.12 keymap= web=10.6.2.102/fog/ consoleblank=0 loglevel=4 mode=manreg
imgfetch init_32.xz
boot || goto MENU
:fog.reg
kernel bzImage32 root=/dev/ram0 rw ramdisk_size=127000 ip=dhcp dns=10.6.0.12 keymap= web=10.6.2.102/fog/ consoleblank=0 loglevel=4 mode=autoreg
imgfetch init_32.xz
boot || goto MENU
:fog.sysinfo
kernel bzImage32 root=/dev/ram0 rw ramdisk_size=127000 ip=dhcp dns=10.6.0.12 keymap= web=10.6.2.102/fog/ consoleblank=0 loglevel=4 mode=sysinfo
imgfetch init_32.xz
boot || goto MENU
autoboot

[url=“/_imported_xf_attachments/0/981_IMG_20140612_083144.jpg?:”]IMG_20140612_083144.jpg[/url]

Hi,
Apparently a “no password” setting does fix this issue across the board, reliably, every time.

I would much rather have a password in my situation, that is my goal.

The strangest thing is how it happens randomly - my new FOG installations have been fine being up all weekend, but I’m guessing that sometime this week it will happen again…

Thanks for any help and/or advice,
D.L.

I’m not going to assist with this further.

Why you ask yourself expectantly?

You’re requesting we download files, but hosting through not necessarily good sources. This leads me to think you’re attempting to gain access to systems.

I’m not saying this is WHAT you are actually trying to do, but I’m not going to download files from those links.

Next reason,

You’re making requests and saying, it’s not working. And the only “information” you can give is “you give it a try”?

MMMMMMMMM sounds sketchy to me.

If you want help, provide information in a more detailed nature such as “This error is happening.” Or upload screenshots of the problems your having.

MOD’s, if you can Please remove the links from the posts (or David you can) as they are known “bad” sites.

I also followed the wiki installation instructions Step-by-Step. FTP was missing from my install and SeLinux didn’t actually disable. I would verify the /etc/selinux/config has SELINUX=disable.