So rpcbind from alternate subnets requires mysql to allow connections from its Ethernet and not local host. I guess that makes sense. I wouldn’t have thought of that so awesome man.

Just a track for understanding,

All systems are communicating via PXE and able to load bzImage and init.gz to attempt to start. After that, when it tries to connect to the NFS <fogserverip>:/images/dev and systems not within the same subnet cannot connect?

As your systems within the same subnet of the fogserver communicate properly, it isn’t a storage node user configuration issue, as far as I can tell. It also wouldn’t be a storage_ftp user issue either as you’ve already uploaded the images.

The only thing it seems like, is the internal network can’t route through to the fog server’s ip address to connect to the nfs share. This is why I would suggest port forwarding, for each of the switches in the path, to point directly to the fog server.

Maybe see if you can change the router to the gateway that all the subnet’s can communicate with each other across. This would typically be the DHCP server itself which, as far as I can tell, works perfectly fine. Maybe have your switches forward the nfs ports to your fog server. 111 and 2049 are the typical ports.

Other than that, I don’t know. Maybe setup dhcp for tftp to use the same LAN as your fog server?

Maybe check firewall on the fog system or network.

It isn’t pxe unable to mount it at that point. It’s the kernel. bzImage is that kernel. What version are you using? Try upgrading and see if that’ll help maybe?

Looked up the issue and found a page with similar issues as yours:

[url]http://fogproject.org/forum/threads/fog-32-on-ubuntu-11-10-unable-to-upload-image.852/[/url]

It sounds like nfs-kernel-server is having issue actually mounting. One issue I ran into on my setup was RPC, but I’m running centos which is redhat based. I just installed rpcbind and had to add fsid=1 to images and fsid=2 to images/dev so my exports looks like:

/images *(rw,sync,no_wdelay,insecure_locks,no_root_squash,insecure,fsid=1)
/images/dev *(rw,sync,no_wdelay,no_root_squash,insecure,fsid=2)

Looking into this further, try removing rpcbind and just:

apt-get install nfs-common nfs-kernel-server portmap

I was looking into the init.gz system, but I haven’t been able to figure which parts happen in which order. There’s kind of a lack of comments. So this will be one of the long winded projects, where I try to break the system to figure out exactly what’s happening and when. Hopefully we’ll see partclone working here shortly. I’m actually looking to figuring out how to build partclone into the initrd filesystem and maybe figure out how I can use it.

apt-get install apache2 php5 php5-gd php5-cli php5-mysql php5-curl mysql-server mysql-client isc-dhcp-server tftpd-hpa tftp-hpa nfs-kernel-server vsftpd net-tools wget xinetd sysv-rc-conf tar gzip build-essential cpp gcc g++ m4 htmldoc perl libcrypt-passwdmd5-perl lftp openssh-server php-gettext clamav-freshclam rpcbind nfs-common

try this:

apt-get remove portmap;
apt-get install nfs-kernel-server nfs-common

try removing rpcbind and nfs-kernel-server
then try to have apt install them

I don’t know what else to work on then.

try
apt-get install rpcbind nfs-kernel-server
or
apt-get reinstall rpcbind nfs-kernel-server

I don’t remember ubuntu’s method of on boot startup, I think it’s update-rc

[COLOR=#333333][FONT=UbuntuMono]update-rc.d rpcbind nfs-kernel-server[/FONT][/COLOR]

make sure both nfs and rpcbind are set to start on boot. Then I’d say try restarting the server, see if that helps you out at all.

Don’t forget to restart the nfs services.

When you setup the task before uninstallation, did your systems start uploading their images?

I don’t know what else to suggest here.

I’d check your server and make sure NFS server is running.

Check your /etc/exports file to make sure it’s enabling the NFS Share to the correct shares.

NFS requires RPCBind to operate, so check that rpcbind service is running then make sure nfs server is running and/or can be started.

Ok,

For now I’ve removed the OS Association Field, and create new group menu from the submenu.include.php file, and for ease of use I moved submenu.include.php from:
{fogwebdir}/management/include/submenu.include.php
TO:
{fogwebdir}/commons/submenu.php

I’ll post this file and the updated:
{fogwebdir}/management/index.php

Also, I’ll post the GroupManagementPage.class.php file.

I’ll update my tarball as well with these changes so far.
Inventory of simple changes:

{fogwebdir}/management/index.php (just changed reference of submenu.include.php to submenu.php}
{fogwebdir}/commons/submenu.php (this file has OS Association removed from Group menu. Moved file from management/includes)
{fogwebdir}/lib/pages/GroupManagementPage.class.php (removed OS Association area, included parts for Image Association, and Removing hosts from membership field. Membership area, host names are links to edit host directly if needed.)

[url=“/_imported_xf_attachments/0/382_GroupManagementPage.class.php?:”]GroupManagementPage.class.php[/url][url=“/_imported_xf_attachments/0/383_submenu.php?:”]submenu.php[/url][url=“/_imported_xf_attachments/0/384_index.php?:”]index.php[/url]

I figured out the image association but I will not post the update until I work out the other sections a little bit. I think I’m getting to the point, that the only reason I have the includes folder is to reference these for the class building.

I hope you guys don’t mind the time as I am, as the true developers, working a full time job with all of this.

I’ve got a new kernel based on the core config for 3.10.7

I don’t have a lot of hardware to test on, so please test.

It can be downloaded from:

[url]https://mastacontrola.com/fogboot/kernel/bzImage[/url]
OR
wget --no-check-certificate [url]http://mastacontrola.com/fogboot/kernel/bzImage[/url]

Then the next question is … Is /storage a raid system with a possible bad drive? I don’t know what else to check then and I’m sorry.