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.

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.