engage wrote: > I'm now getting "Failed To Locate GUI Server". The wiki states > ...is it a problem with my dongle.bin.conf file?
No. That message occurs before the dongle is transfered, and the startup script (dongle.bin.conf) doesn't come into play until after the mvpmc dongle has booted. But if you are troubleshooting mvpmc boot issues, I always recommend eliminating your dongle.bin.conf until after you have accomplished a successful boot. The startup script is *not* required for a basic boot. Similarly, I'd skip all the VLC stuff until you've gotten mvpmc to load. > According to the wiki, I'm suppose to use port 16869 instead of the > standard port of 69. In addition to, would be more accurate. The .ver and dongle file are retrieved via this high numbered port. The startup script and theme file are retrieved via the standard port. That's assuming you're using a H or later hardware revision. If you're using rev. D hardware, the high numbered port isn't used. > /etc/rc.local has this line: > /usr/sbin/in.tftpd -l -a 192.168.1.4:16869 -c -s /var/lib/tftpboot & Have you confirmed these command line arguments, or just cut-and-pasted them from the wiki. They appear to be for atftpd, which I don't currently have installed, so I can't easily check the man page. In order for this to work, the tftp daemon needs to be running in "stand alone" mode (the -l switch is probably for "listen" which would accomplish this). By default, tftp daemons are designed to run as children of the inetd super daemon, and they don't directly interface with the network. I'd recommend setting up your tftp daemon to run from inetd or xinetd (which is more efficient than having it constantly running). Just copy the entry you found for the stock tftpd, and change the port. With inetd that's just a matter of replacing the service name with a port number. You should find numerous examples of this on the wiki and in the list archives. Someone else just ported an example for xinetd. Most importantly, you should take steps to test your setup. Try connecting to your tftpd on both ports with a tftp client running on another computer. Try disabling both tftp servers, verifying that you can't connect, enable the one on the standard port, verify you can connect, disable the standard port and enable the high port, and verify you can connect. (For each test you can try retrieving the .ver file.) Watch your logs as you do this. If you find your logs aren't telling you enough, adjust the command line switches for tftpd to increase the verbosity. I also recommend using the BSD tftpd instead of atftpd, if you can conveniently switch, as it provides better logging. > Apparently, there's a difference between in.tftp and tftp. I believe the in.tftp version is compiled to use the tcpwrapper libraries, which allow you to use the hosts.allow and hosts.deny files to create firewall-like rules. > /usr/sbin/mvprelay 16881 5906 6337 192.168.1.4 & I recommend using mvpboot instead. It provides better logging, and in the typical case requires no command line options. Give these things a try and port your logs if you run into further trouble. -Tom ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Mvpmc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mvpmc-users mvpmc wiki: http://mvpmc.wikispaces.com/
