@Wallae said:

I’ve tired uploading the DBAN.iso(16MB) to the server but the limit of 8MB is stopping me from doing so.

What are you using to upload? Where is there an 8MB limit?

Ok thanks so i will write a expect script to install fog automaticly

@bakgat As far as I can tell the options 66 and 67 in the bootp.plist are base64 encoded. Trying to decode (e.g. www.base64decode.org) I only get a sensible result for option 67 (‘undionly.kpxe’) but not for opt 66.

The other thing I notice is that the packet you posted is a request (‘Message type: Boot Request (1)’) from a client machine. You don’t see the options in a request only on replys. See if you can find the answer from the server. DHCP goes like this: Client-Discovery, Server-Offer, Client-Request, Server-Ack (https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#Operation)

So you should actually see at least four DHCP packets! If you don’t see any reply DHCP packets from the server I am wondering if the bootp service is actually started?!

Here you can find a discussion (https://forums.fogproject.org/topic/6074/extending-a-file-system-on-redhat-base-distros) and wiki article on this topic (https://wiki.fogproject.org/wiki/index.php/Add_%26_Extend_a_2nd_Virtual_HDD).

Depending on your setup (you haven’t told us anything about that yet - OS, version, virtual/physical, partition layout, free space or second hard drive?) you probably need to adjust most of the tings mentioned there. But this should give you a good starting point. For further assistence we do need more information!

@erkax https://forums.fogproject.org/topic/6154/selinux-policy

Using the CloudOS from Neverware. I successfully installed it on a computer and imaged it successfully. I think you would classify it as Chromium OS but it has been modified with more driver support and other things. I am using the free version not the paid for one with Google Apps support.

I used the Linux with multiple partitions single disk.

I was actually able to install this on several different hardware models with no issues as long as the hard drive was the same size or larger than my original test machine.

Optiplex 360.380, and 390
Lenovo X130
Inspiron Duo

Might be able to extend some of the old hardware this way.

Ok so here is the result, I got it working thanks to a person on this forum named aaoyagi.

When I followed his instructions my Linux distros booted without fail via my fog server over the network!!!

In case anybody wants the steps:

First in your /etc/exports add this line:
/var/www/fog/iso/15.04_64 *(ro,sync,no_wdelay,insecure_locks,no_root_squash,insecure)

Then restart your nfs server. If you’re running Ubuntu it’s sudo service nfs-kernel-server restart

Next, extract the Ubuntu iso to a direcotry named 15.04_64 in your /var/www/fog/iso directory.

In your Advanced menu use this:
:MENU
menu
item --gap – ---------------- iPXE boot menu ----------------
item ubuntu15.04_64 Boot Ubuntu 15.04
item return return to previous menu
:ubuntu15.04_64
set path /fog/iso/15.04_64
set nfs_path /var/www/fog/ISO/15.04_64
kernel http://${fog-ip}${path}/casper/vmlinuz.efi || read void
initrd http://${fog-ip}${path}/casper/initrd.lz || read void
imgargs vmlinuz.efi root=/dev/nfs boot=casper netboot=nfs nfsroot=${fog-ip}:${nfs_path} ip=dhcp splash quiet – || read void
boot || read void
goto start

Hopefully it works for you too. You don’t have to set the variables. I just did it that way in case I ever have to change where the iso directory lives.

@Killklli Are you still working on this? I have done a lot of testing and I am pretty sure that dnsmasq is not able to boot most UEFI devices as it uses DHCP option 43 which they don’t like (see here: https://www.mail-archive.com/dnsmasq-discuss@lists.thekelleys.org.uk/msg09233.html). I am working on a node.js proxy DHCP to support BIOS/UEFI and Mac OS X. But will be still a while I suppose - BIOS works pretty good and UEFI is not far either but the code is still a big mess.

Follow this thread: https://forums.fogproject.org/topic/5870/dhcp-proxy-for-fog

yes, /etc/hosts as told in my post indeed, and /etc/resolv.conf as well. All information required to be fetched a way or another. Be it by a custom client or something else.

@Uncle-Frank @Wayne-Workman 4848 solved my extended partition problem. Thanks a lot!

@need2

Thanks. I began reinstalled using Fedora 22 server 64bit. hope to have FOG back up and running soon.

@Wayne-Workman I do not know. Pinging directly may be a better option, but I would not recommend it. ICMP is not really a good mechanism to test up/down state. This is because ICMP knows nothing about the host, nor does it really care. Remember, we aren’t directly tracking the IP of a host any more, and this is for good reason in my eyes. Basically, the current mechanism knows what host is what because it translates the Hostname to its corresponding IP address. If you want to just know if a host is “pingable” then you should probably add the Host IP field back and enter the corresponding host’s IP address. This way, even if the host is currently rebooting, it will respond if the network is up and running.

@Wayne-Workman Holy crap I got it working again. After upgrading to 14.04 I re-ran the SVN from the link previously mentioned and now I can access my fog server again.

So the problem isn’t the cloning but that I was transferring from an IDE/Compatible VM to an Physical system with AHCI enabled. Setting the physical to IDE/Compatible mode fixed that. However IDE mode is not a solution. I required building AHCI into the kernel prior to deployment.

Thanks to some help from centos.org forums I have a working solution.

I’ve moved the OS update and some other new code that forces the recompiled kernel to include AHCI drivers to the final mastering.

Server building occurs for me in several steps.

Install the Minimal Server to a VM, nothing else, no updates Purpose the VM (in this case for FOG and all that entails, no updates) Master the image (every update and generalizing code) Capture the image Distribute the image Align the Deployed system

I’ve added the following code to the Mastering:

03> Master the Image ## Login REMOTELY with Kitty ( http://kitty.9bis.net/ ) ## Elevate Access Level ## -- ## Disable root access via SSH (CentOS only) ## Direct next Kernel recompilation update to include AHCI drivers & be HW generic ## Clean & Update the OS ## Shutdown sudo su if [ -f /etc/centos-release ]; then sed -i "s|#PermitRootLogin yes|PermitRootLogin no|g" /etc/ssh/sshd_config systemctl restart sshd.service sed -i 's|#add_drivers+="|add_drivers+="ahci|g' /etc/dracut.conf sed -i 's|#hostonly="yes|hostonly="no|g' /etc/dracut.conf yum clean all yum makecache yum update -y shutdown now fi

Windows share that use CIFS/SMB mount will only work with user space NFS server such as unfsd3 or NFS-Ganesha
The regular kernel mode nfs_kernel_server does not compiled to support NFS re-export.

@Nicolas-Bricet Thanks for reporting back on this! I am still working on improving this article. Knowing what works and what not for different machines is very helpful. I am marking this thread as solved. If you see new issues with Mac OS you might want to open up a new post.

@cnaud86 What @ch3i is saying, is it’s still an FTP issue. You manually moving things around, or not, means it is most likely an FTP problem even still. That said, if all of the stuff is “working” automatically, there is still the chance that FTP just can’t read the file size as you would like.

@Tom-Elliott In first sorry if I seemed to insist heavily.
As i said before your works is great and the help on the forum also.
I will install fog as you explained me with “./installfog.sh -D /var/www -W fog/ -y” parameters.

Sorry again and thanks again for your precious help 😉