If you have any questions, feel free to ask at any time.
Finally had the time to do this. The first time I tried uninstalling, it claimed there was nothing to do and reinstalling did nothing either. Presumably, I hadn't used aptitude the first time.
OK, not a problem. I ran through the uninstall/reinstall a second time and this time things went the way you described, but, alas, still didn't work. I tried
boincmgr --verbose
and got a metric megagrunch[1] of info, including something about not being able to connect to BOINC DOMAIN. (I think.) I'd seen that before on my own box, so I know that's easily fixable, but don't remember how. If nothing else, we now know it's all installed the way it should be. Thanx for all your patience!
[1]as compared to an imperial megagrunch or an SAE megagrunch
Finally had the time to do this. The first time I tried uninstalling, it claimed there was nothing to do and reinstalling did nothing either. Presumably, I hadn't used aptitude the first time.
Really weird. It's like two different machines. :)
Quote:
OK, not a problem. I ran through the uninstall/reinstall a second time and this time things went the way you described, but, alas, still didn't work. I tried
boincmgr --verbose
and got a metric megagrunch[1] of info, including something about not being able to connect to BOINC DOMAIN. (I think.) I'd seen that before on my own box, so I know that's easily fixable, but don't remember how.
Ok, I did that too and also get grief about 'catalog file for domain 'wxstd' not found'. Doesn't seem important because my MGR connects fine anyway.
Quote:
If nothing else, we now know it's all installed the way it should be. Thanx for all your patience!
Ok, sounds reasonable. :)
Something from another thread comes to mind:
Do you have a localhost entry in /etc/hosts?
Maybe you can post the contents of the /etc/hosts file here from that box? Please munge the IP though, if it's a possible security threat.
I'm expecting something like:
127.0.0.1 localhost
127.0.1.1 yourhostname
# And then some IPv6 lines below this
Another thought. Is the loopback device present and configured?
Do you see something like this:
[edit]
Final thought of the day:
Is the manager perhaps getting blocked by a firewall rule?
The following shows no firewall rules in effect on my box. If you get different output, it could be worth looking into a bit more.
wandering@minstrel:~$ for TABLE in filter nat mangle raw; do echo "Showing table: $TABLE"; sudo iptables -t $TABLE -L; done
[sudo] password for wandering:
Showing table: filter
Chain INPUT (policy ACCEPT)
target prot opt source destination
All that was fine. Looking at the verbose output from boincmgr, I noticed that it was looking for /usr/share/locale/en_US and /usr/share/locale/en_US.UTF8, neither of which was there. Alas, creating the folders didn't help. I'm beginning to think that it's just a matter of telling boinc that it has to attach to the projects my sister was working on so that it can get some work to do. For some reason, it's skipping this step.
I am using SuSE Linux 10.3 and boinc 5.10.45. When a new boinc version appears I download it into my home directory and sh it with my Bourne shell command after giving the killall boinc command to stop my six projects (Einstein, SETI, QMC, LHC, climate prediction, CPDN Beta). Then I cd to the BOINC directory and give 2 shell commands, run_client & to start the client and run_manager & to start the manager. The first starts all running projects, the second gives me the boinc manager window in my KDE GUI. All very simple.
Tullio
I just had a D'oh! moment. The client wasn't running! Of course, it's got that stupid password issue, but I have instructions somewhere on how to fix it. Now, the only question is why it isn't starting @boot.
I've found at least four versions of that file, gui_rcp_auth.cfg and edited them all to have the same password. After each time, I've stopped and restarted boinc, but the manager still insists I've got the password wrong. Sigh!
Now, the only question is why it isn't starting @boot.
Edit the file /etc/default/boinc-client and check this setting ENABLED="1".
="0" means don't start
="1" means start
By default it should be set to "1".
If it isn't set to "1", even if you do a sudo /etc/init.d/boinc-client start, it will just ignore you and not start boinc.
This may also be the cause of your other problem regarding the password.
Edit the file /etc/default/boinc-client and check this setting ENABLED="1".
="0" means don't start
="1" means start
By default it should be set to "1".
If it isn't set to "1", even if you do a sudo /etc/init.d/boinc-client start, it will just ignore you and not start boinc.
This may also be the cause of your other problem regarding the password.
It was. I used /etc/init.d/boinc-client to stop, then restart it. Now, if I run boincmgr from a terminal, it comes up, and I can log on to local host. I now have einstein@home running. (I need to get password data for her other project.) Alas, if I start if from her main menu, it fails to connect and I have to go into the advanced view and reconnect. Not quite there, but at least we have boinc itself running! Thanx for all your patience.
(BTW, her main menu starts /usr/bin/boincmgr. I don't need to specify the path from the command line because that's on her PATH. Any ideas?)
I'm Joe's sister, and I just wanted to say "Thank you soooooo much for all the help". I think part of the problem was with the password, as there are several ways to spell it.
Once Joe got the correct spelling, everything dropped in to place, and is now working, and happy as a clam.
RE: If you have any
)
Finally had the time to do this. The first time I tried uninstalling, it claimed there was nothing to do and reinstalling did nothing either. Presumably, I hadn't used aptitude the first time.
OK, not a problem. I ran through the uninstall/reinstall a second time and this time things went the way you described, but, alas, still didn't work. I tried
boincmgr --verbose
and got a metric megagrunch[1] of info, including something about not being able to connect to BOINC DOMAIN. (I think.) I'd seen that before on my own box, so I know that's easily fixable, but don't remember how. If nothing else, we now know it's all installed the way it should be. Thanx for all your patience!
[1]as compared to an imperial megagrunch or an SAE megagrunch
RE: Finally had the time to
)
Really weird. It's like two different machines. :)
Ok, I did that too and also get grief about 'catalog file for domain 'wxstd' not found'. Doesn't seem important because my MGR connects fine anyway.
Ok, sounds reasonable. :)
Something from another thread comes to mind:
Do you have a localhost entry in /etc/hosts?
Maybe you can post the contents of the /etc/hosts file here from that box? Please munge the IP though, if it's a possible security threat.
I'm expecting something like:
# And then some IPv6 lines below this
Another thought. Is the loopback device present and configured?
Do you see something like this:
wandering@minstrel:~$ ifconfig lo lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:21206 errors:0 dropped:0 overruns:0 frame:0 TX packets:21206 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:77064610 (73.4 MB) TX bytes:77064610 (73.4 MB)[edit]
Final thought of the day:
Is the manager perhaps getting blocked by a firewall rule?
The following shows no firewall rules in effect on my box. If you get different output, it could be worth looking into a bit more.
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Showing table: nat
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Showing table: mangle
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
Showing table: raw
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
[/edit]
All that was fine. Looking
)
All that was fine. Looking at the verbose output from boincmgr, I noticed that it was looking for /usr/share/locale/en_US and /usr/share/locale/en_US.UTF8, neither of which was there. Alas, creating the folders didn't help. I'm beginning to think that it's just a matter of telling boinc that it has to attach to the projects my sister was working on so that it can get some work to do. For some reason, it's skipping this step.
I am using SuSE Linux 10.3
)
I am using SuSE Linux 10.3 and boinc 5.10.45. When a new boinc version appears I download it into my home directory and sh it with my Bourne shell command after giving the killall boinc command to stop my six projects (Einstein, SETI, QMC, LHC, climate prediction, CPDN Beta). Then I cd to the BOINC directory and give 2 shell commands, run_client & to start the client and run_manager & to start the manager. The first starts all running projects, the second gives me the boinc manager window in my KDE GUI. All very simple.
Tullio
I just had a D'oh! moment.
)
I just had a D'oh! moment. The client wasn't running! Of course, it's got that stupid password issue, but I have instructions somewhere on how to fix it. Now, the only question is why it isn't starting @boot.
I've found at least four
)
I've found at least four versions of that file, gui_rcp_auth.cfg and edited them all to have the same password. After each time, I've stopped and restarted boinc, but the manager still insists I've got the password wrong. Sigh!
RE: Now, the only question
)
Edit the file /etc/default/boinc-client and check this setting ENABLED="1".
="0" means don't start
="1" means start
By default it should be set to "1".
If it isn't set to "1", even if you do a sudo /etc/init.d/boinc-client start, it will just ignore you and not start boinc.
This may also be the cause of your other problem regarding the password.
RE: Edit the file
)
It was. I used /etc/init.d/boinc-client to stop, then restart it. Now, if I run boincmgr from a terminal, it comes up, and I can log on to local host. I now have einstein@home running. (I need to get password data for her other project.) Alas, if I start if from her main menu, it fails to connect and I have to go into the advanced view and reconnect. Not quite there, but at least we have boinc itself running! Thanx for all your patience.
(BTW, her main menu starts /usr/bin/boincmgr. I don't need to specify the path from the command line because that's on her PATH. Any ideas?)
Hi Everybody, I'm Joe's
)
Hi Everybody,
I'm Joe's sister, and I just wanted to say "Thank you soooooo much for all the help". I think part of the problem was with the password, as there are several ways to spell it.
Once Joe got the correct spelling, everything dropped in to place, and is now working, and happy as a clam.
--
LosCon 36, But Wait...There's MORE!
LosCon 36
But Wait...There's MORE!
RE: Once Joe got the
)
Another happy cruncher. That's good news. :)