@fortasse: Thanks for your quick reply. My apologies in advance if I am not supplying the correct requested information as I am very much a layman at this.
Please note that I had to delete the link headers as was not allowed to post more than 5 links due being a new user.
I have continued to attempt the update and recieve the same error. This time with “binary-amd64” in the request line. Complete results below:
E: Some index files failed to download. They have been ignored, or old ones used instead.
The whonix version appears to be up to date per whonixcheck if this is what you meant by " Is your apt out of date?" and returns the following from the teminal. Please let me know if I’ve misunderstood this.
user@host:~$ whonixcheck
[INFO] [whonixcheck] whonix-ws | Whonix-Workstation | TemplateVM | xxxxxxxxxx UTC 2016
[INFO] [whonixcheck] Connected to Tor.
[INFO] [whonixcheck] SocksPort Test: Testing Tor’s SocksPort…
[INFO] [whonixcheck] SocksPort Test Result: Connected to Tor. IP: xxxxxxxxxxx
[INFO] [whonixcheck] TransPort Test: Testing Tor’s TransPort…
[INFO] [whonixcheck] TransPort Test Result: Connected to Tor. IP: xxxxxxxxxxx
[INFO] [whonixcheck] Stream Isolation Test Result: Functional.
[INFO] [whonixcheck] Whonix News Download: Checking for Whonix news and updates…
[INFO] [whonixcheck] Whonix News Result:
√ Up to date: whonix-workstation-packages-dependencies 2.9-1
√ Up to date: Whonix Build Version: 11.0.0.3.0
[INFO] [whonixcheck] Debian Package Update Check: Checking for software updates via apt-get… ( Documentation: Operating System Software and Updates )
[WARNING] [whonixcheck] Debian Package Update Check Result: Could not check for software updates! (apt-get code: 100)
Please manually check inside this TemplateVM (‘whonix-ws’).
Open a terminal. (dom0 → Start Menu → Template: whonix-ws → Terminal)
Update. sudo apt-get update && sudo apt-get dist-upgrade
[INFO] [whonixcheck] Whonix APT Repository: Enabled.
When the Whonix team releases JESSIE updates,
they will be AUTOMATICALLY installed (when you run apt-get dist-upgrade)
along with updated packages from the Debian team. Please
read Placing Trust in Whonix to understand the risk.
If you want to change this, use:
sudo whonix_repository
Quote: fortasse: “Can you post the relevant lines from your sources.list? (if you don’t know, it should be in /etc/apt/sources.list or /etc/apt/sources.list.d/[a file here], I can’t quite remember)”
Not sure what the relevant lines would be but below is all the data from the 4 files in /etc/apt/sources.list.d/.
No. I did not edit the line in the file. I only edited the line in the post (deleted http) due to not being allowed to post more than 5 links as a new user. The full line from the whonix.list file as copied is:
I tried to enable the stable repository again but still receive the same error.
Steps taken in order were:
Enable the stable repository per APT Repository instructions.
No change.
Enable the stable repository, shutdown and restart whonix template VM.
No change.
Disable and reenable the stable repository.
No change.
Disable the stable repository. Restart the system. (whonix.list was no longer in /etc/apt/sources.list.d/ ) Enable the repository. (whonix.list repopulated in /etc/apt/sources.list.d/).
No Change
For reference:
I have made no manual changes to whonix or qubes. The whonix updates have functioned well for over 4 months until a few days ago. The only other updates have been the qubes fedora template updates which continue to function.
Not sure if it’s relevant but did have a qubes DOM0 update show as “pending” a week or 2 ago but when attempting to update via the terminal, appeared to not update and the “pending” notification disappeared.
Second tried “sudo apt-get dist-upgrade” only via terminal and the upgrade succeded. The “update pending” notification in VM Manager disappeared.
Ran whonixcheck on both whonix and sys-whonix. Received a good report on both checks. See below for the sys-whonix check.
user@host:~$ whonixcheck
[INFO] [whonixcheck] sys-whonix | Whonix-Gateway | whonix-gw Template-Based ProxyVM | xxxxxx UTC 2016
[INFO] [whonixcheck] Connected to Tor.
[INFO] [whonixcheck] SocksPort Test: Testing Tor’s SocksPort…
[INFO] [whonixcheck] SocksPort Test Result: Connected to Tor. IP: xxxxxxxxxx
[INFO] [whonixcheck] Whonix News Download: Checking for Whonix news and updates…
[INFO] [whonixcheck] Whonix News Result:
√ Up to date: whonix-gateway-packages-dependencies 2.9-1
√ Up to date: Whonix Build Version: 11.0.0.3.0
[INFO] [whonixcheck] Debian Package Update Check: Checking for software updates via apt-get… ( Documentation: Operating System Software and Updates - Kicksecure )
[INFO] [whonixcheck] Debian Package Update Check Result: No updates found via apt-get.
[INFO] [whonixcheck] Whonix APT Repository: Enabled.
When the Whonix team releases JESSIE updates,
they will be AUTOMATICALLY installed (when you run apt-get dist-upgrade)
along with updated packages from the Debian team. Please
read Placing Trust in Whonix ™ to understand the risk.
If you want to change this, use:
sudo whonix_repository
Third, ran whonixcheck on both whonix-ws and whonix-gw but recieved the same Debian Package Update WARNING and apt-get code 100 as before. See below.
user@host:~$ whonixcheck
[INFO] [whonixcheck] whonix-ws | Whonix-Workstation | TemplateVM | xxxxxxxx UTC 2016
[INFO] [whonixcheck] Connected to Tor.
[INFO] [whonixcheck] SocksPort Test: Testing Tor’s SocksPort…
[INFO] [whonixcheck] SocksPort Test Result: Connected to Tor. IP: xxxxxxxxxxxx
[INFO] [whonixcheck] TransPort Test: Testing Tor’s TransPort…
[INFO] [whonixcheck] TransPort Test Result: Connected to Tor. IP: xxxxxxxxxxxx
[INFO] [whonixcheck] Stream Isolation Test Result: Functional.
[INFO] [whonixcheck] Whonix News Download: Checking for Whonix news and updates…
[INFO] [whonixcheck] Whonix News Result:
√ Up to date: whonix-workstation-packages-dependencies 2.9-1
√ Up to date: Whonix Build Version: 11.0.0.3.0
[INFO] [whonixcheck] Debian Package Update Check: Checking for software updates via apt-get… ( Documentation: Operating System Software and Updates - Kicksecure )
[WARNING] [whonixcheck] Debian Package Update Check Result: Could not check for software updates! (apt-get code: 100)
Please manually check inside this TemplateVM (‘whonix-ws’).
Open a terminal. (dom0 → Start Menu → Template: whonix-ws → Terminal)
Update. sudo apt-get update && sudo apt-get dist-upgrade
[INFO] [whonixcheck] Whonix APT Repository: Enabled.
When the Whonix team releases JESSIE updates,
they will be AUTOMATICALLY installed (when you run apt-get dist-upgrade)
along with updated packages from the Debian team. Please
read Placing Trust in Whonix ™ to understand the risk.
If you want to change this, use:
sudo whonix_repository
Fourth, tested whonix-ws and -gw template update functions again . Still get the same results from Qubes VM Manager update and the terminal using “sudo apt-get update && sudo apt-get dist-upgrade” and only “sudo apt-get update”. “sudo apt-get dist-upgrade” by itself appears to function.
Are there any other steps I can try to resolve this?
Thanks.
With a newly downloaded and installed whonix-gw template in qubes, it shows updates available in qubes-manager. However, doing :
“sudo apt-get update”
…from within whonix-gw terminal , produces some errors. Most repos are contacted fine, but one of them causes an error like:
“Error, http code 403 received from proxy after CONNECT”
I don’t have my qubes/whonix machine here with me so can’t copy-paste it exactly, but the affected repo is something related to “amd64 packages”.
And because of this, it ends up with:
“E: Some index files failed to download. They have been ignored, or old ones used instead.”
This glitch means that trying “sudo apt-get update && apt-get dist-upgrade” fails entirely, because the error is considered fatal and not even other updates will complete. Manually forcing “sudo apt-get dist-upgrade” will get the other updates, but even so, doing “whonixcheck” reports that it was unable to check for package updates, due to apt error 100.
Normal non-qubes Whonix running under KVM on Linux Mint has no issue, and updates check and complete correctly. Only whonix template on qubes is affected.
Can anyone/Patrick confirm that the repo in question is just offline at the moment, and if so, advise how to proceed? This has been the case for at least 4 days straight now, so it is not a “quickly-resolving” temporary problem.
Ah sorry, I didn’t see this original similar (identical) topic when posting mine. For the record, I have made absolutely no manual changes to anything in either whonix or qubes, and am getting this same error. It is a fresh clean install, and just trying to update the whonix-gw template. No text files were ever edited or customized in any way.
User tinyproxy
Group tinyproxy
Port 8082
Timeout 60
DefaultErrorFile "/usr/share/tinyproxy/default.html"
#StatHost "tinyproxy.stats"
StatFile "/usr/share/tinyproxy/stats.html"
Syslog On
LogLevel Notice
PidFile "/var/run/tinyproxy-updates/tinyproxy.pid"
MaxClients 50
MinSpareServers 2
MaxSpareServers 10
StartServers 2
MaxRequestsPerChild 0
DisableViaHeader Yes
Allow 127.0.0.1
Allow 10.137.0.0/16
ConnectPort 443
# Explicitly block connections to the proxy IP, to return an error in such
# case. This error page contains a magic string which is used in Whonix to
# detect whether proxy is torified or not.
# See https://github.com/qubesos/qubes-issues/issues/1482 for details
Filter "/etc/tinyproxy/updates-blacklist"
It is Qubes 3.1, by virtue of having updated from 3.0 directly within qubes via “sudo qubes-dom0-update”. Not a new install of 3.1 out of the box. But all went smoothly with no errors from that update.
I will have to check the tinyproxy config settings when I am back at that machine. I presume this is done within the whonix-gw terminal itself.
Ah, I think this is my fault from being away from Qubes for so long. I’ve been using Whonix by itself with KVM, and only this weekend went to try Qubes again. I just read this page:
and the last line:
“Existing users of the 3.0 and 3.1-rcX releases should be able to easily upgrade
without re-installing. Enjoy!”
I figured qubes-dom0-update was all that was necessary to go from 3.0 to 3.1, just as recent update from Whonix 11 to 12 was achievable through similarly simple commands (nice job and applause on that, by the way!!).
It was my ignorance being unaware of that special update instruction page, since I haven’t kept up with Qubes in recent months. So, I am probably still in fact on 3.0 without having realized it. I thought that 3.0 → 3.1 was just a natural, automatic update no different from any other sporadic one, with no additional steps. I will revisit the update later and try again.
I appreciate the report! It’s not confirmed yet, that R3.1 will not have this issue. Too early to blame it on tinyproxy configuration. Let’s see. Please try if you will still be having this issue with R3.1.
I had a chance to do a fresh install of Qubes R3.1 to a different device, and on that installation the whonix template updates worked perfectly fine with no 403 error complaint. On Qubes R3.0 I am still seeing the same issue.
Unfortunately I encountered a completely new non-whonix-related problem, in that Qubes 3.1 totally breaks functionality with my Realtek wireless card. It worked fine on 3.0, but on 3.1 it glitches and freezes constantly, and won’t connect to wifi spot.
I don’t know whether it’s a fedora 23, kernel, or Qubes core issue, but I am going to try importing my fedora 21 template from 3.0 and see if using that for sys-net helps at all. Like I said though, not a whonix-specific issue there, but still annoying.
I can also confirm that his is a problem on R3.0. As far as I can see, the main “confusion” seems to be whether this problem is related to Qubes R3.0 or if it is something more general. Otto_Kratik seems to have isolated it to R3.0.
There are various reasons why people are still on R3.0, and not al of them are laziness. Has the root cause of the problem been determined yet? If so, can someone offer a workaround?
Just for completeness, I should also make it clear that I have made no manual changes to my Qubes-Whonix configuration.
My /etc/tinyproxy/tinyproxy-updates.conf file differs slightly at the end:
[code]cat /etc/tinyproxy/tinyproxy-updates.conf
User tinyproxy
Group tinyproxy
Port 8082
Timeout 60
DefaultErrorFile “/usr/share/tinyproxy/default.html”
#StatHost “tinyproxy.stats”
StatFile “/usr/share/tinyproxy/stats.html”
Syslog On
LogLevel Notice
PidFile “/var/run/tinyproxy-updates/tinyproxy.pid”
Filter “/etc/tinyproxy/filter-updates”
FilterURLs On #FilterExtended On #FilterCaseSensitive On
FilterDefaultDeny Yes
ConnectPort 443[/code]
and /etc/tinyproxy contains the following files:
ls -l /etc/tinyproxy
total 8
-rw-r--r-- 1 root root 1026 Nov 15 2015 filter-updates
-rw-r--r-- 1 root root 542 Nov 15 2015 tinyproxy-updates.conf
ie there is no updates-blacklist file.