Have to image 8 labs by Monday



  • Hello,

    I’ve been posting a lot recently and I apologize but I am running out of time.

    My latest issue is that whenever I attempt to upload an image, I get:
    “RPC remote system error connection refused” and something similar to NFS share could no be mounted.

    Does anyone have any ideas on how to solve this?

    Thanks!

    VMware ESXi - Ubuntu 10.04 (x64) - Fog
    VMware ESXi - Windows Server 2012 (x64) - DHCP/DNS Server
    Physical PCs across multiple subnets (subnets other than what the DHCP server and the Fog server are on)


  • Senior Developer

    I guess that would do it as well. Awesome man. Maybe try posting your findings into the tutorial section so others can troubleshoot their issues a little quicker as I’m sure this isn’t the only one to have happened.



  • It ended up being that all of my PCs were in AHCI mode when they needed to be in IDE. It’s all solved now! Thanks!



  • After doing some more testing, I’ve found that:

    Host PC running a virtual machine, virtual machine will do EVERYTHING perfectly! No errors.
    Same host PC will only do quick inventory. Can’t mount NFS because of RPC issue.

    Why does a virtual machine work but the physical box does not when they are on the same exact subnet, port, everything?
    The only difference is that I have IP reservations on my DHCP server for the physical boxes and not the virtual machines.



  • 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.



  • 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.


  • Senior Developer

    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.



  • 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!



  • 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!


  • Senior Developer

    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.


  • Senior Developer

    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?



  • 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.


  • Senior Developer

    Maybe check firewall on the fog system or network.



  • 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?



  • I upgraded this morning to the latest version of the kernel.


  • Senior Developer

    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?



  • 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.


  • Senior Developer

    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)



  • 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.



  • 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”


Log in to reply
 

383
Online

39.3k
Users

11.0k
Topics

104.4k
Posts

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.