Debian Template Updates Failing (Reading from proxy failed)

[evol]

Hello, I am struggling to update templateVMs.

I have chosen to install Whonix qube at installation, but wish not to use it yet.
Internet comes in from a usb device. Browsing works, apparently.
Update checking works, as I get notifications for new updates.

There are two issues:

Issue 1 - template updates keep failing:

GUI updater tells me that the Debian template is up to date. It is not.

Upon entering sudo apt-get update into debian-10 template terminal, I get:

Err:1 https://deb.debian.org/debian buster InRelease
  Reading from proxy failed - read (11: Resource temporarily unavailable) [IP: 127.0.0.1 8082]
Err:2 https://deb.qubes-os.org/r4.0/vm buster InRelease
  Reading from proxy failed - read (11: Resource temporarily unavailable) [IP: 127.0.0.1 8082]
Err:3 https://deb.debian.org/debian-security buster/updates InRelease
  Reading from proxy failed - read (11: Resource temporarily unavailable) [IP: 127.0.0.1 8082]
Reading package lists... Done                        
W: Failed to fetch https://deb.debian.org/debian/dists/buster/InRelease  Reading from proxy failed - read (11: Resource temporarily unavailable) [IP: 127.0.0.1 8082]
W: Failed to fetch https://deb.debian.org/debian-security/dists/buster/updates/InRelease  Reading from proxy failed - read (11: Resource temporarily unavailable) [IP: 127.0.0.1 8082]
W: Failed to fetch https://deb.qubes-os.org/r4.0/vm/dists/buster/InRelease  Reading from proxy failed - read (11: Resource temporarily unavailable) [IP: 127.0.0.1 8082]
W: Some index files failed to download. They have been ignored, or old ones used instead.

Then, I configured qubes.UpdatesProxy file in dom0 to point to sys-net
(note that I prefer not to use Whonix for anything):

## Note that policy parsing stops at the first match,
## so adding anything below "$anyvm $anyvm action" line will have no effect

## Please use a single # to start your custom comments

# Upgrade all TemplateVMs through sys-net. Previous config: sys-whonix.
#$type:TemplateVM $default allow,target=sys-net

# Upgrade Whonix TemplateVMs through sys-whonix. Previous config: sys-whonix.
$tag:whonix-updatevm $default allow,target=sys-net

# Deny Whonix TemplateVMs using UpdatesProxy of any other VM. Previous config: anyvm deny
$tag:whonix-updatevm $anyvm allow,target=sys-net

# Default rule for all TemplateVMs - direct the connection to sys-net
#$type:TemplateVM $default allow,target=sys-net

$anyvm $anyvm deny

Then I configured sys-net VM:
sudo systemctl enable qubes-updates-proxy
As no qubes-updates-service file was created in /var/run/qubes-service (why?), I made an empty one myself, and by mistake, performed an update and upgrade in sys-net - a beginner mistake that beginners do. Yet it worked.

However, I cannot perform the same configuration in the Debian 10 template.
The system does not allow me to create the service file. Thus update fails.

I tried the third path:

In dom0:

sudo qubesctl --show-output --skip-dom0 --templates state.sls update.qubes-vm

For Debian, the console prints, among other things, this:

        ID: update
  Function: pkg.uptodate
    Result: True
   Comment: System is already up-to-date
   Started: 12:36:20.976612
  Duration: 1441.566 ms
   Changes:   ...

What should I do?

Issue 2:
I tried to find a setting that would route all updates over non-torrified internet, to no avail.
For instance, the above procedure in dom0 still tries to update Whonix templates over Whonix, adn these template updates fail just as well.
Is there a chance to everything bypassing Whonix?

Many thanks in advance,
Evol

[ludovic]

Hi @evol ,

welcome to Qubes-OS world.

@evol

Upon entering sudo apt-get update into debian-10 template terminal

This isn’t the way to update, please read the How to update guide.

@evol

I configured qubes.UpdatesProxy file in dom0 to point to sys-net

No, please first read the Getting started guide, the Qube Architecture and Networking guide.

@evol

tried the third path:

In dom0:

sudo qubesctl --show-output --skip-dom0 --templates state.sls update.qubes-vm

This is the right way (not the third).

@evol

GUI updater tells me that the Debian template is up to date. It is not.

Please, explain why you think that the template isn’t up to date.

@evol

Issue 2:

Please, do another topic, one question by topic is easier.

[evol]

Hello, ludovic, thank you for reaching out.

Actually, my first attempt at updating was in fact via Qubes Update graphical tool, as stated in the How to Update guide, but it said that Debian-10 is up to date.

Why do I claim that the template isn’t up to date? I compared versions of Firefox ESR from the sys-net that I managed to update, and from Debian-10 templateVM that I did not update. The Debian template version of ESR was considerably older, while the first was up to date, according to Firefox ESR webpage. Furthermore, my Qubes installation was not used for several months, so it seems highly unlikely that no Debian packages were released during this time for apt to install.

Only as a second resort did I use apt/get commands directly in the template terminal.

Thanks for recommending the articles to read.

[adw]

@evol

GUI updater tells me that the Debian template is up to date. It is not.

@evol

Why do I claim that the template isn’t up to date? I compared versions of Firefox ESR from the sys-net that I managed to update, and from Debian-10 templateVM that I did not update. The Debian template version of ESR was considerably older, while the first was up to date, according to Firefox ESR webpage. Furthermore, my Qubes installation was not used for several months, so it seems highly unlikely that no Debian packages were released during this time for apt to install.

Unfortunately, this is probably due to #6585.

---

@evol

Then, I configured qubes.UpdatesProxy file in dom0 to point to sys-net
(note that I prefer not to use Whonix for anything):

## Note that policy parsing stops at the first match,
## so adding anything below "$anyvm $anyvm action" line will have no effect

## Please use a single # to start your custom comments

# Upgrade all TemplateVMs through sys-net. Previous config: sys-whonix.
#$type:TemplateVM $default allow,target=sys-net

# Upgrade Whonix TemplateVMs through sys-whonix. Previous config: sys-whonix.
$tag:whonix-updatevm $default allow,target=sys-net

# Deny Whonix TemplateVMs using UpdatesProxy of any other VM. Previous config: anyvm deny
$tag:whonix-updatevm $anyvm allow,target=sys-net

# Default rule for all TemplateVMs - direct the connection to sys-net
#$type:TemplateVM $default allow,target=sys-net

$anyvm $anyvm deny

The problem is that you have no uncommented rule for updating non-Whonix templates. To accomplish what you wanted in the default qubes.UpdatesProxy (which the above is not), all you had to do was comment the first rule (all updates through sys-whonix). Just add one # character. That’s it. Clearnet (non-Torified) updates will Just Work™ after that.

However, now you’ve modified your qubes.UpdatesProxy file so that the rules no longer match the default. With the version you posted, you’ll simply want to uncomment the first or fourth rule (which now uselessly duplicate each other).

@evol

Then I configured sys-net VM:
sudo systemctl enable qubes-updates-proxy
As no qubes-updates-service file was created in /var/run/qubes-service (why?), I made an empty one myself, and by mistake, performed an update and upgrade in sys-net - a beginner mistake that beginners do. Yet it worked.

However, I cannot perform the same configuration in the Debian 10 template.
The system does not allow me to create the service file. Thus update fails.

None of this should be necessary and is probably not why the update fails. See above.

TL;DR: Too much tinkering, making things harder than they need to be. Original problem had a simple, one-character solution.

[adw]

@evol

Issue 2:
I tried to find a setting that would route all updates over non-torrified internet, to no avail.
For instance, the above procedure in dom0 still tries to update Whonix templates over Whonix, adn these template updates fail just as well.
Is there a chance to everything bypassing Whonix?

This is actually the same as “Issue 1.”

[evol]

@adw

However, now you’ve modified your qubes.UpdatesProxy file so that the rules no longer match the default. With the version you posted, you’ll simply want to uncomment the first or fourth rule (which now uselessly duplicate each other).

There was a mistake on my part - the first rule I did in fact leave uncommented, the quote I posted was wrong. This is how it is:

## Note that policy parsing stops at the first match,
## so adding anything below "$anyvm $anyvm action" line will have no effect

## Please use a single # to start your custom comments

# Upgrade all TemplateVMs through sys-net. Previous config: sys-whonix.
$type:TemplateVM $default allow,target=sys-net

# Upgrade Whonix TemplateVMs through sys-net. Previous config: sys-whonix.
$tag:whonix-updatevm $default allow,target=sys-net

# Deny Whonix TemplateVMs using UpdatesProxy of any other VM. Previous config: anyvm deny.
$tag:whonix-updatevm $anyvm allow,target=sys-net

# Default rule for all TemplateVMs - direct the connection to sys-net. Previous config: same, but in force.
#$type:TemplateVM $default allow,target=sys-net

$anyvm $anyvm deny

After running update over qubesctl from dom0, I seem to get the fake update success message again.

  Summary for debian-10
  ------------
  Succeeded: 2 (changed=1)
  Failed:    0
  ------------
  Total states run:     2
  Total run time:   3.036 s

Whonix templates update also fails.

whonix-gw-15:
  ----------
            ID: update
      Function: pkg.uptodate
        Result: False
       Comment: WARNING: Execution of /usr/bin/apt-get prevented by /etc/uwt.d/40_qubes.conf because no torified Qubes updates proxy found.
                Please make sure Whonix-Gateway (commonly called sys-whonix) is running.
                
                - If you are using Qubes R3.2: The NetVM of this TemplateVM should be set to Whonix-Gateway (commonly called sys-whonix).
                
                - If you are using Qubes R4 or higher: Check your _dom0_ /etc/qubes-rpc/policy/qubes.UpdatesProxy settings.
                
                _At the very top_ of that file you should have the following:
                
                $tag:whonix-updatevm $default allow,target=sys-whonix
                
                To see if it is fixed, try running in Whonix TemplateVM:
                
                sudo systemctl restart qubes-whonix-torified-updates-proxy-check
                
                Then try to update / use apt-get again.
                
                For more help on this subject see:
                https://www.whonix.org/wiki/Qubes/UpdatesProxy
                
                If this warning message is transient, it can be safely ignored.
       Started: 13:59:45.737615
      Duration: 12.498 ms
       Changes:   
  ----------
            ID: notify-updates
      Function: cmd.run
          Name: /usr/lib/qubes/upgrades-status-notify
        Result: False
       Comment: Command "/usr/lib/qubes/upgrades-status-notify" run
       Started: 13:59:45.753982
      Duration: 17.087 ms
       Changes:   
                ----------
                pid:
                    1049
                retcode:
                    255
                stderr:
                stdout:
  
  Summary for whonix-gw-15
  ------------
  Succeeded: 0 (changed=1)
  Failed:    2
  ------------
  Total states run:     2
  Total run time:  29.585 ms

[evol]

@evol

Whonix templates update also fails.

And it seems to convince me to use a torrified proxy, which I do not want…

[adw]

But that’s the only way to update a Whonix template. Updating a Whonix template over a clearnet connection would be a terrible idea, so it is intentionally prohibited by design. You shouldn’t want to do that. If you don’t want to use Whonix or Tor at all, then delete your Whonix templates.

[deeplow]

(adjusted the title for clarity. If you feel it doesn’t apply exactly to your problem, feel free to change it @evol)

[evol]

@adw

But that’s the only way to update a Whonix template. Updating a Whonix template over a clearnet connection would be a terrible idea, so it is intentionally prohibited by design. You shouldn’t want to do that. If you don’t want to use Whonix or Tor at all, then delete your Whonix templates.

Thanks for suggesting. I might consider doing that, even if it probably won’t solve the Debian issue.
Perhaps my problem is so elementary that it is hard to grasp, and I have to find a solution by myself.

@deeplow

(adjusted the title for clarity. If you feel it doesn’t apply exactly to your problem, feel free to change it @evol)

The templates I am more concerned with are the Debian ones; Whonix is a bit of a side-story

[adw]

@evol

Perhaps my problem is so elementary that it is hard to grasp, and I have to find a solution by myself.

It could be that, or it could be that you’re not expressing it clearly enough for others to understand. If you would like to try rephrasing the question, I’m sure we would be happy to keep trying to help.

@evol

The templates I am more concerned with are the Debian ones; Whonix is a bit of a side-story

Ah, well this explains a bit of the confusion, doesn’t it? Your post certainly made it sound like Whonix was the main (or one of the main) problems.

My XY problem detector is starting to go off. Could you try telling us the original, ultimate goal you hope to achieve rather than asking how to do what you believe to be the means to that goal?

[deeplow]

@evol

The templates I am more concerned with are the Debian ones; Whonix is a bit of a side-story

Ok. Fixed

[bowtiediguana]

Same issue here.

104: connection reset by peer when attempting apt-get install foo in a debian template VM

I do not have Whonix. qubes.updateProxy:
$type:TemplateVM $default allow,target=sys-net

[bowtiediguana]

tinyproxy is running in sys-net

[davemyfree]

I’m getting the same thing all day, any idea how to fix? Is this a known bug?

[bowtiediguana]

I reinstalled Qubes.

[unman]

Did a reinstall fix it?

[bowtiediguana]

Yes.

[unman]

If you update and reconfigure your system as you had it before, and
encounter the same problem, can you post back here with details of the
last steps before it started to fail?

[observinglynx]

I encountered this issue (104 error) after using debian-10-minimal as my sys-net.
The fix is to create a file /etc/apt/apt.conf in your VM that is attempting to run apt commands, add Acquire::http::Proxy "http://SYS-NET-IP-HERE:8082"; and run your apt command again, it will pass. I’m not very well educated on proxy systems so this is a magic band-aid for anyone that is stuck. If anyone more knowledgeable can comment on why this fixes it, would be greatly appreciated.

Edit: I’d like to point out that you should replace sys-net-ip-here with the local ip (10.x.x.x) not the one you get from the router eg. 192.168.x.x.