Deleting debian-9 template and getting a new one returns an error: "Error: Unable to find a match"

[Sphere]

I was sure I double checked the line of code I used in dom0 terminal to get a new template which was
"sudo qubes-dom0-update qubes-template-debian-9"

Not sure why running this returns with the "Error: Unable to find a match" while just changing 9 to 8 actually works

The same case happens when I try qubes-template-fedora-29, where my fedora-29 template still exists

If this is because of some sort of name conflict issue, how could I download the template/s and have them be named something else?

[Chris Laprise]

The older release with the apt vulnerability may have been removed from
the repository, and the patched version may still be in testing?

Easiest way to resolve that is to add '--enablerepo=qubes*testing'.

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[unman]

On Thu, Feb 28, 2019 at 10:09:38PM -0500, Chris Laprise wrote:
> On 2/28/19 8:30 PM, Sphere wrote:
> > I was sure I double checked the line of code I used in dom0 terminal to get a new template which was
> > "sudo qubes-dom0-update qubes-template-debian-9"
> >
> > Not sure why running this returns with the "Error: Unable to find a match" while just changing 9 to 8 actually works
> >
> > The same case happens when I try qubes-template-fedora-29, where my fedora-29 template still exists
> >
> > If this is because of some sort of name conflict issue, how could I download the template/s and have them be named something else?
> >
>
> The older release with the apt vulnerability may have been removed from the
> repository, and the patched version may still be in testing?
>
> Easiest way to resolve that is to add '--enablerepo=qubes*testing'.
>

I dont believe this is so.
A fixed version (201901281256) is in qubes-templates-itl, and I
*believe* that I grabbed it from there before.
What you need to run is:
sudo qubes-dom0-update --enablerepo=qubes-templates-itl qubes-template-debian-9

@Sphere - do you have a debian-8 installed? If so it may be that yum
remembers which repo it installed from, and so is able to grab the
update. If this isnt the case (and the repo wasnt updated during the
day) then I'm lost for an explanation.

Generally, if you want to do this manually, you can always grab from
https://yum.qubes-os.org/r4.0/templates-itl/rpm.
Download the package.
Manully check the signature using "rpm -K" (You will need to get signing
key and Qubes master)
Transfer to dom0
install using "rpm -i <package>"

Much better to use the native tools, but that option is always
available.

unman

[Sphere]

@unman - Nope I don't have debian-8 installed and that I snagged a fresh copy of debian-9 last year.
What's noteworthy is that I can definitely trigger installation of debian-8 and other templates that I have never installed.
I can trigger qubes-dom0-update just fine tho and have the repositories update.
I'll try snagging the templates from the itl repo and see if that still triggers the problem, many thanks for lending me a hand
hope it solves this problem

[unman]

On Sun, Mar 03, 2019 at 07:46:52PM -0800, Sphere wrote:
> On Friday, March 1, 2019 at 8:38:07 PM UTC+8, unman wrote:
> > On Thu, Feb 28, 2019 at 10:09:38PM -0500, Chris Laprise wrote:
> > > On 2/28/19 8:30 PM, Sphere wrote:
> > > > I was sure I double checked the line of code I used in dom0 terminal to get a new template which was
> > > > "sudo qubes-dom0-update qubes-template-debian-9"
> > > >
> > > > Not sure why running this returns with the "Error: Unable to find a match" while just changing 9 to 8 actually works
> > > >
> > > > The same case happens when I try qubes-template-fedora-29, where my fedora-29 template still exists
> > > >
> > > > If this is because of some sort of name conflict issue, how could I download the template/s and have them be named something else?
> > > >

> @unman - Nope I don't have debian-8 installed and that I snagged a fresh copy of debian-9 last year.
> What's noteworthy is that I can definitely trigger installation of debian-8 and other templates that I have never installed.
> I can trigger qubes-dom0-update just fine tho and have the repositories update.
> I'll try snagging the templates from the itl repo and see if that still triggers the problem, many thanks for lending me a hand
> hope it solves this problem
>

I thought this was a Whonix issue, since I encountered it on one box,and
fixed it to updating over Tor not using Whonix.
But with some testing I'm lost - I can duplicate it on some machines, but
with others with *exactly the same configuration* I get the same error
you report. This suggest to me a problem with the template mirrors -
I've just quickly run though them and 3 of them are down/not available.

Fixing the repo to a specific repo seems to work for me.

I've raised an issue at github - #4858

unman

[Sphere]

Thanks for this unman
I tried the commands you suggested and it still ended up with the very same "Error: Unable to find a match"
I'll track that issue you raised to know when it gets fixed (Y)

[Chris Laprise]

Have you tried "sudo dnf clean all" in dom0?

[unman]

On Mon, Mar 04, 2019 at 11:41:21PM -0500, Chris Laprise wrote:
> On 3/4/19 8:59 PM, Sphere wrote:
> > Thanks for this unman
> > I tried the commands you suggested and it still ended up with the very same "Error: Unable to find a match"
> > I'll track that issue you raised to know when it gets fixed (Y)
> >
>
> Have you tried "sudo dnf clean all" in dom0?
>

That doesnt fix this.
Nor does creating a new updateVM, (so everything is clean).

[cooloutac]

I think this has happened to me before. Think I just had to wait and download at another time, i'm not sure. Have you tried enabling testing repo like Chris suggested? Or disabling it? Think the the only testing repo i enable is the security one.

Maybe change dns?

[Sphere]

I also did what Chris suggested as well as the dnf clean all and the result is all the same.
No problem with my dns for sure because I'm using dnscrypt on a pool of 19 dns servers and I've never had problems resolving everything so far

[cooloutac]

On Wednesday, March 6, 2019 at 12:08:15 AM UTC-5, Sphere wrote:
> I also did what Chris suggested as well as the dnf clean all and the result is all the same.
> No problem with my dns for sure because I'm using dnscrypt on a pool of 19 dns servers and I've never had problems resolving everything so far

I know for sure I had same problem before. Can't remember what fixed it. Thought it was the repo.

Are you using latest Qubes version? To get to 4.0 from 3.2 you have to do a clean install from boot disk.

[Jeff and the Dog]

(From phone plz excuse if accidentally top posts) I ha e had that error and worked around by trying different repos and different syntax or wording sin the post I am reply to does not specify how the attempted replace eme t was approached it is hard to. be more helpful but if you keep tweaking your command line you will get a match. Also the directions I used imied the gemate would be out of testing when I later updatd a different system they were still I. testing v. The recipe is a little confusing on this replacement but if you persist you will find d that eureka moment. It is well worth the trouble as the Debian plates are way cool.

--
You received this message because you are subscribed to the Google Groups "qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users...@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/9fd211f2-6fec-4300-ae2c-2bdf15cfca8e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sphere]

@cooloutac: I'm using Qubes 4.0 right now

@American Qubist 001: I'm sorry but I beg your pardon, could you please be more specific? An example at least of what you mean by using different syntax
Could you also specify which repos you used?