DNSMasq takes less than 5 minutes to configure and can save you a mountain of time troubleshooting. There could be a number of reasons you are experiencing this error. Do you have access to manage/edit the DHCP scope?

DNSMasq alleviates the need to make changes to the entire scope of the DHCP, I would recommend trying DNSMasq as it has helped many others in the past. DNSMasq involves the installation from apt-get, and a single configuration file, and we already created the template for you in the wiki, you copy and paste and change the ip address information to match that of your location.

Continuing any further without permission of your Network engineer/manager is NOT recommended. You MUST edit the settings at the DHCP server in order for your server to be seen by your network properly.

[url]https://github.com/mastacontrola/fogproject/issues/1[/url]

It’s very possible, I haven’t even tried that route due to lack of time over the summer when I just had to put the legacy/UEFI boot file issue to rest.

The fog system you’re running does not have a mount point labeled as:

/mnt/USB

You need to, in the debug, run:
[code]mkdir /mnt/USB
mount /dev/<usbdevicehere> /mnt/USB
[/code]

All should work then.

[FONT=Arial][COLOR=#333333]I believe I found the issue. I had one DHCP scope in which I had missed updating option 67 to undionly.kpxe. It was still set to pxelinux.0 Once I changed that, it seemed to fix the issue.[/COLOR][/FONT]

Fixed issues mentioned in previous post.

changes made to:
lib/common/input.sh
Due to: “ifconfig and route commands, which were used in older versions of Linux. They are now deprecated in Arch Linux; you should use ip instead.”

See: [url]https://bitbucket.org/david_fear/fog-project/commits/43dfbe784022f04002249ee3491f0ea3d35de77e[/url]

First, lvm is not supported as it controls the volume and formats of those volumes under its control.

You’re sure the second partition is EXT4, or the LVM that, for all purposes, is the second partition is formatted as EXT4?

sorry for the late respond but i not trying to boot from PXE any more.
i try to make it the first boot device and nothing change.

only two things that work is to create an offline repository and then run the boot - repair process
or
[SIZE=14px][FONT=UbuntuRegular][COLOR=#333333]copy GRUB from [/COLOR][/FONT][/SIZE][COLOR=#222222][FONT=Ubuntu Mono][SIZE=14px]EFI/ubuntu/grubx64.efi[/SIZE][/FONT][/COLOR][SIZE=14px][FONT=UbuntuRegular][COLOR=#333333] to [/COLOR][/FONT][/SIZE][COLOR=#222222][FONT=Ubuntu Mono][SIZE=14px]EFI/BOOT/bootx64.efi [as published in [URL=‘http://askubuntu.com/questions/380447/uefi-boot-fails-when-cloning-image-to-new-machine]’]here[/URL]] [/SIZE][/FONT][/COLOR]
but it will only boot from UEFI and not when i try to repair on legacy,

what i need and want to try is to install fresh copy on legacy and then upload it with FOG, then i will try to deploy it on another computer and see…

thanks Cadyfish and Tom

hope that this post will help others

Nir

I’m currently working a different system to this.

I have built a clamav system from source.

Stored the source in /opt/fog/clamav.

Gave it 777 permissions throughout.

Added it to nfs mounts.

Making the mount point happen at boot, along with a checkin to let the system know it’s in progress.

Use those binaries to load the data. Freshclam can be run, and it will update the database files on the fog server as well.

Hopefully this will help us out. If you need the files right away, you can update the freshclam from the fog server using:
[code]/opt/fog/clamav/bin/freshclam[/code]

This is in testing and there may be bugs to work out, but for right now I’m hoping this will help.

It has the added benefit that the init can be that much smaller as it won’t require building the init with clamav built into it. So when clamav updates, you can update on the fog server. I’ll see about building a "zip’ to keep this updated autonomously, but that can wait. I hope this will help everybody out.

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.