Have to image 8 labs by Monday
-
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
-
This post is deleted! -
I get nfs-common: Depends: portmap (> 6.0.0-1ubutnu2.1) E: Broken packages when I try to install all of those things.
-
Looking into this further, try removing rpcbind and just:
apt-get install nfs-common nfs-kernel-server portmap
-
It gets stuck at “Starting NFS kernel daemon.”
Before that, it says:
exportfs: /etc/exports [1]: Neither ‘subtree_check’ or ‘no_subtree_check’ specified for export “:/images" exportfs: /etc/exports [2]: Neither ‘subtree_check’ or ‘no_subtree_check’ specified for export ":/images/dev”
-
I just added another storage node and when I PXE boot, it attempts to mount it but still ends up with the RPC connection refused error.
-
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) -
Alright. I’ll try to modify my exports file in a second.
What’s interesting is that the NFS share mounts perfectly fine through an NFS client on Windows. I don’t know why PXE can’t get to it.
-
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?
-
I upgraded this morning to the latest version of the kernel.
-
I think that we’re close to figuring this out!
I just tried to upload an image from a machine on the same subnet as the Fog and DHCP server and it worked!
Any ideas on why it’s not having my machines on other subnets route to the NFS share correctly?
-
Maybe check firewall on the fog system or network.
-
There’s no internal firewall on the network and the Ubuntu Server that Fog is running off of has its firewall disabled.
I’m thinking about when I first installed Fog. It asks me what my router’s IP address was and I set it to the IP of my Windows DHCP 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?
-
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.
-
That’s something that I’ll look into! I’ll see what I can do tomorrow morning and hopefully, I’ll be able to get it working. I think that you’re right though. I’ll keep you posted on how it goes tomorrow!
-
I GOT IT!
I read this post earlier today and didn’t think much of it. Turns out, it fixed my issue.
I had to edit my.conf and change bind-address to my Fog server IP instead of 127.0.0.1.
Thank you so much, Tom! I couldn’t have fixed it without your support. I greatly appreciate it!
-
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.
-
Well, I spoke too soon…
Last night, I was remoted into virtual machines on physical PCs in different subnets and that worked.
This morning, I tried to perform a full registration and image the physical PCs in different subnets and I am still getting the RPC error.
When I perform a quick registration, it works. When I perform a full registration, it just keeps trying to send the information but it never completes.
My DHCP server gave the virtual machines no reserved IP address where as my physical boxes get a reserved IP. Maybe that has something to do with it? Not sure.
-
The error is: “RPC No Route to Host” whenever I attempt to mount the NFS share to upload an image.
There must be a reason as to why these computers can’t find their way back to the Fog server.
