| Author |
Message |
|
|
Post subject: smxi freezes on gpg update
 Posted: Dec 22, 2007 - 08:55 PM
|
|
Joined: Dec 22, 2007
Posts: 3
Status: Offline
|
|
I've been using sidux for several months now. I can dist-update/dist-upgrade without problem. I have never been able to successfully run smxi because it freezes at the step, "updating keys for gpg" I get no error, message or feedback of any kind. I even tried letting it run overnight--still stuck at the same place come morning. Suggestions?
Thanks! |
|
|
| |
|
|
|
 |
|
|
|
Post subject:
Posted: Dec 25, 2007 - 06:13 PM
|
|
Joined: Dec 29, 2006
Posts: 55
Location: Germany
Status: Offline
|
|
| Hi, I'm sorry that I have no solution, but I had the same problem. Fortunately, it solved from alone after leaving it for a while as what you already did. |
|
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Dec 25, 2007 - 06:46 PM
|
|
Joined: Nov 28, 2006
Posts: 4279
Status: Offline
|
|
it has to be something with how your isp/router is handling a certain type of connection request, nothing in smxi itself. These weird, impossible to diagnose, connection issues come up now and then, but have remained impossible to diagnose, sadly.
My top guess is this: linux kernel ipv6 handling triggers tiny bug in router firmware, which then fails to send request properly to destination, and maybe also a tiny bug in isp routing software triggered by this. Try to disable ipv6 and see if that helps, search forums for ipv6 to find out how.
If that helps, let me know, since we have never been able to figure out these weird little errors. |
_________________
sidux Maintenance script: dist-upgrade, kernel install, general utilities: smxi
Backup script [using rdiff-backup]: rd-h2.sh
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Dec 27, 2007 - 05:17 AM
|
|
Joined: Dec 22, 2007
Posts: 3
Status: Offline
|
|
| Thanks for the replies! I tried disabling ipv6 and that didn't help, unfortunately. I'll try bypassing my router and see what happens. |
|
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Dec 27, 2007 - 05:57 AM
|
|
Joined: Nov 28, 2006
Posts: 4279
Status: Offline
|
|
I have also suspected that it's an isp or dns issue, coupled with the way certain apps that access the web handle connections. These types of issues happen in an amazingly small percentage of all uses, and seem annoyingly random, one small app will work, then for a single user somewhere, it will fail. We have never managed to trace the problems, which is what made me start to suspect that it's an ISP, or DNS, issue, coupled with weak error handling in some apps, I know wget at rare times suffers from that for example.
Thanks for checking the ipv6, that's been a sneaking suspicion, but my strongest suspicion is some combination of kernel, router firmware, isp/dns handling. Almost impossible to figure out unfortunately. |
_________________
sidux Maintenance script: dist-upgrade, kernel install, general utilities: smxi
Backup script [using rdiff-backup]: rd-h2.sh
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Jan 25, 2008 - 05:57 PM
|
|
Joined: Jan 29, 2007
Posts: 49
Location: Frankfurt am Main
Status: Offline
|
|
I have the same problem with smxi.
My ISP is the German 1&1 company, but I think they're using leased lines from Telekom. My WLAN-Router is a avm FRITZ!Box Fon WLAN 7170 (UI), Firmware-Version 29.04.40 and IPv6 seems to be active.
The information given about the DSL counterpart equipment on ISP side is: Infineon, DSL-Version 113.28 - H3, Herstellerkennung 00, Versionsnummer 00, Seriennummer 00
Are there any special requirments for the firewall settings in the Fritz!Box like port forwarding to get the script running?
By the way, the script seems to be very useful. Thank you for this work! |
|
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Jan 25, 2008 - 06:39 PM
|
|
Joined: Nov 28, 2006
Posts: 4279
Status: Offline
|
|
no port forwarding is needed.
I really can't say why certain things in debian do not work and certain ones do, smxi isn't doing anything but running standard commands like wget, gpg --keyserver wwwkeys.eu.pgp.net --recv-keys ... and so on
I don't have any control over why a router, isp, etc, or sidux itself, might throw up an error on this.
Just to narrow it down, try running these out of smxi, as root:
gpg --keyserver wwwkeys.eu.pgp.net --recv-keys 6070D3A1 &> /dev/null && apt-key add /root/.gnupg/pubring.gpg 1> /dev/null
gpg --keyserver wwwkeys.eu.pgp.net --recv-keys F80994F6 &> /dev/null && apt-key add /root/.gnupg/pubring.gpg 1> /dev/null
If they don't work, try removing the: 1> /dev/null
And: &> /dev/null
from the end of hte line, and try it again, see what it reports.
If those don't work in smxi, and do work in regular bash, then it looks like it's something with how bash handles certain requests made from within a script.
Before you do this, confirm with smxi that the test fails, edit: /etc/smxi.conf and remove this line: keyrings-update-4
before running smxi again.
if smxi fails to update those two, and doing it manually in console/terminal succeeds, at least we're a little closer to learning what is actually happening. |
_________________
sidux Maintenance script: dist-upgrade, kernel install, general utilities: smxi
Backup script [using rdiff-backup]: rd-h2.sh
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Jan 25, 2008 - 08:10 PM
|
|
Joined: Jan 29, 2007
Posts: 49
Location: Frankfurt am Main
Status: Offline
|
|
My problem with smxi is solved. The problem was located just in the middle between screen and wall behind me. Shame on me!
But let's do it step by step:
1. /etc/smxi.conf doesn't contain line: keyrings-update-4, so nothing was to delete
2. smxi still stops when trying to update gpg keys
3. gpg --keyserver wwwkeys.eu.pgp.net --recv-keys 6070D3A1 &> /dev/null && apt-key add /root/.gnupg/pubring.gpg 1> /dev/null
didn't work
4. gpg --keyserver wwwkeys.eu.pgp.net --recv-keys F80994F6 &> /dev/null && apt-key add /root/.gnupg/pubring.gpg 1> /dev/null
didn't work
5. gpg --keyserver wwwkeys.eu.pgp.net --recv-keys 6070D3A1 &> /dev/null && apt-key add /root/.gnupg/pubring.gpg
didn't work
6. gpg --keyserver wwwkeys.eu.pgp.net --recv-keys F80994F6 &> /dev/null && apt-key add /root/.gnupg/pubring.gpg
didn't work
7. gpg --keyserver wwwkeys.eu.pgp.net --recv-keys 6070D3A1 && apt-key add /root/.gnupg/pubring.gpg
gpg: requesting key 6070D3A1 from hkp server wwwkeys.eu.pgp.net
gpg: Interrupt caught ... exiting
didn't work
8. gpg --keyserver wwwkeys.eu.pgp.net --recv-keys F80994F6 && apt-key add /root/.gnupg/pubring.gpg
gpg: requesting key F80994F6 from hkp server wwwkeys.eu.pgp.net
gpg: Interrupt caught ... exiting
didn't work
9. /etc/init.d/guarddog stop
after this , number 3 worked fine, as well as whole smxi script.
10. /etc/init.d/guarddog start
smxi now works fine, the problem seems to be that the firewall blocks the gpg command
So, in short words, the local firewall was the obstacle for getting the keys. |
|
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Jan 25, 2008 - 09:28 PM
|
|
Joined: Nov 28, 2006
Posts: 4279
Status: Offline
|
|
ah, thank you for doing such excellent tests, it's important to know what actually is doing the break, and this is the best test result I've ever gotten for this particular problem.
Guarddog is a thing I briefly experimented with, but in my opinion, it is an outstanding server level software firewall, but has no place on a consumer desktop, because it's simply too good at its job by default, it shuts down everything in AND out, I forgot about that completely.
I use firestarter, which is much less agressive, it only filters incoming stuff.
I may add a small guarddog check to turn it off then turn it back on on exit. But I'll wait, it's good however to see what the problem with that gpg thing was at least in this case, thanks. |
_________________
sidux Maintenance script: dist-upgrade, kernel install, general utilities: smxi
Backup script [using rdiff-backup]: rd-h2.sh
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Jan 26, 2008 - 12:51 AM
|
|
Joined: Dec 02, 2006
Posts: 221
Status: Offline
|
|
Guarddog can be configured to permit the port / protocol of anything. Of course, it requires some steps that some users may not want to spend time doing. But I use guarddog on both of my computers. To permit GPG (I don't know if guarddog uses translations, but if so the German might use completely different words),
0) start guarddog
1) click the Protocol tab
2) click Miscellaneous
3) Make sure box for PGP is check-marked, not blank and not x-marked
4) Click Apply, OK, OK
5) Try tests again. |
|
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Feb 02, 2008 - 08:06 PM
|
|
Joined: Nov 23, 2007
Posts: 29
Status: Offline
|
|
Sorry, I can't confirm that guarddog is guilty. guarddog ist not installed. I did a new install of the christmas edition and run now into this issue. I never hat a problem with it before. No fix from the hints above.
Greets Laptix |
|
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Feb 02, 2008 - 08:22 PM
|
|
Joined: Nov 28, 2006
Posts: 4279
Status: Offline
|
|
No firewall, no router misconfigurations?
When all else fails, I assume DNS issues between linux / router, and isp.
If every single person who had seen this issue had posted full technical specs, eg: router, router firmware version, isp, plus some basis traceroute type data, as well as the excellent tests results by spiralnebelverdreher, the issue would probably have been understood a year ago. Probably not fixable I'd guess, but at least understood.
Bad burn of iso too of course, failure to burn dao/8x iso, makes all issues reported non-supported until that is fixed. |
_________________
sidux Maintenance script: dist-upgrade, kernel install, general utilities: smxi
Backup script [using rdiff-backup]: rd-h2.sh
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Feb 02, 2008 - 08:24 PM
|
|
Joined: Nov 23, 2007
Posts: 29
Status: Offline
|
|
Quick solution? I did a reset (System -zurücksetzen) of the AVM FritzBox, which was very slowly responding to any menu options. Thanks for jumping in so quickly, everything is fine. Internet connection wasn't significantly slower, may be the AVM Box has an issue with certain commands?
Happy Laptix |
|
|
| |
|
|
|
|
|
|
|
