Errors during downloading metadata for repository 'fedora-modular':

46 views
Skip to first unread message

Dave

unread,
May 25, 2020, 6:03:38 PM5/25/20
to qubes-users
platform: Qubes 4.0.3 / Intel 64

attempting to upgrade cloned Fedora-30 templates with user applications to Fedora-31
completed steps 1, 2, & 3 - shutdown, cloning from DOM0
step 3 - "sudo dnf clean all" completed from new Fedora-31 template
then:

[user@fedora-31-work ~]$ sudo dnf --releasever=fedora-31 distro-sync --best --allowerasing
Fedora Modular fedora-31 - x86_64               4.4 kB/s |  63 kB     00:14   
Errors during downloading metadata for repository 'fedora-modular':
  - Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-fedora-31&arch=x86_64 (IP: 127.0.0.1)
Error: Failed to download metadata for repo 'fedora-modular': Cannot prepare internal mirrorlist: Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-fedora-31&arch=x86_64 (IP: 127.0.0.1)

I couldn't reach the mirrors address in a browser either.
Do the mirror addresses in the Qubes repository need updating?

TIA - David

Dave

unread,
May 25, 2020, 7:47:58 PM5/25/20
to qubes-users
Also, I did this:
Installed a new Fedora-31 Template
Cloned the new template to Fedora-31-work

Then tried this:
Opened the old template Fedora-30-work
Using Files: "Copy To Other App VM", tried to copy Home and RW directories to new template Fedora-31-work, but Permission Denied.

Can I and How To copy old template folders Fedora-30-work:~/Home and /RW to new template Fedora-31-work?
Would this be equivalent to DNF Upgrade? Will all my user data run the same in my App VM when switched to the new template?

- David

Sven Semmler

unread,
May 25, 2020, 8:17:04 PM5/25/20
to Dave, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Mon, May 25, 2020 at 04:47:57PM -0700, Dave wrote:
> Using Files: "Copy To Other App VM", tried to copy Home and RW directories
> to new template Fedora-31-work, but Permission Denied.
>
> Can I and How To copy old template folders Fedora-30-work:~/Home and /RW to
> new template Fedora-31-work?

sudo qvm-copy /home/user
sudo qvm-copy /rw

/Sven

- --
public key: https://www.svensemmler.org/0x8F541FB6.asc
fingerprint: D7CA F2DB 658D 89BC 08D6 A7AA DA6E 167B 8F54 1FB6

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE18ry22WNibwI1qeq2m4We49UH7YFAl7MX/kACgkQ2m4We49U
H7YUNxAAhOHBZ9lVre+8DZaMYQFRwVsQj+BSwYmoevqzEBIR9STueGJ6fqxxDhqc
nWxAKhJ29BCfAAMddZb1aFxJb2Shk2yoQqt5JR03RTvyYbvXtAtjmKTorIkD+9Oh
ZWNPhK4beZgHJGPsbEkBHaau9PbeOKSc/IJG0xHUsDr+ePdsbZ7UvqeL7Z/1dLLx
kuZmU3lcbrKM9sJMzk2WQvqxGYChfUakrAzoBTVIRi2E1RlcTsGiV5oysOF4jvw3
3VSv+gKWJYesm4KKksdjRazo1SfDAIQNA6m5Bhgss87PwmD+uJlhyo4LHoE3ZAbM
oovr0+2lm4/+sikeOGiNB3OWnd3qQADfhGv2EWxQyjQ7+wmp4j4lMmQmSBQ3ElZz
Zl14JKj+zwlis/F+sU6TFeAKotTfSTQ5akYMDmt2HAhNugW0pojWZjyF+HKH63bT
dWKaa40VTwSh3bwh8iHtxZV7W4ztTs+1Lb8puGfVVht+PqnYM6ZUUccy3YqYbzEu
Hl2rw1E4kBsp3gQ2fVIVdEctz8G7VNVpBULVpxlSHni8aN0L271lUPt4Sbv5TOvs
pj0qbEOYwVXJ1qnlSwHxgSKu9z2M6dT40RPYnUtSDpiB6vKMHvve74NvMEP/kgxH
M6c9xVO4HCFFttYfWiUv6dm0Kj42rTLOF4vHdIBDaLdLtJYbkeA=
=bUCy
-----END PGP SIGNATURE-----

Dave

unread,
May 25, 2020, 10:18:02 PM5/25/20
to qubes-users


sudo qvm-copy /home/user
sudo qvm-copy /rw

/Sven


That worked; thanks
Now, how about my installed programs? Which directories are inherited by TemplateBasedVM that contain user apps and data?

What about /etc, /lib, /opt, /var, /loc or whatever folders packages are installed in?

From User Documentation, Template VMs I only see:
TemplateBasedVM
Inheritance    /etc/skel to /home, /usr/local.orig to /usr/local    
Persistence    /rw (includes /home, /usr/local and bind-dirs)


unman

unread,
May 26, 2020, 6:36:42 AM5/26/20
to qubes-users
All the directories you mention are *used* by TemplateBasedVMs, but not
*inherited* by them.
Changes you make there in the template will appear in the TemplateBasedVM
when you boot it, but changes you make in the TemplateBasedVM while it
is running will not be persistent. You can use bind-dirs to change this
behaviour.

Dave

unread,
May 26, 2020, 10:45:24 AM5/26/20
to qubes-users
I was trying to find a work around for my original problem upgrading cloned templateVMs from fedora-30 to fedora-31, so that I don't have to reinstall user apps, but this is beyond my level, and I have several cloned templates  to upgrade. I'd like to just use the procedure in the docs, if someone could help me solve the fedora-modular repro mirror problem. Thanks


  - Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-fedora-31&arch=x86_64 (IP: 127.0.0.1)
Error: Failed to download metadata for repo 'fedora-modular': Cannot prepare internal mirrorlist: Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-fedora-31&arch=x86_64 (IP: 127.0.0.1)

Riverborne

unread,
May 26, 2020, 1:00:29 PM5/26/20
to Sven Semmler, qubes...@googlegroups.com
Thank you for your time and expertise; This time it connected, but failed again.
In accordance with instructions to Upgrade Template In Place at https://www.qubes-os.org/doc/template/fedora/upgrade/ ...
I created a new clone from Fedora-30-work (which has all the programs and data I'd like to keep) called Fedora-31-work and set netVM to sys-firewall.
In the new template Fedora-31-work terminal I ran step 3, but this time returned Curl error (35)
Apparently, it connected, but timed out on mirrors.fedoraproject.org. May I again ask your advise? It shouldn't be because of my internet connection, which is pretty good (fiber to the curb). Thanks again for your help.
Terminal transcript:

[user@fedora-31-work ~]$ sudo dnf clean all
53 files removed
[user@fedora-31-work ~]$ sudo dnf --releasever=31 distro-sync --best --allowerasing
Fedora Modular 31 - x86_64                      0.0  B/s |   0  B     03:18    

Errors during downloading metadata for repository 'fedora-modular':
  - Curl error (35): SSL connect error for https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-31&arch=x86_64 [OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to mirrors.fedoraproject.org:443 ]
  - Curl error (28): Timeout was reached for https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-31&arch=x86_64 [Operation timed out after 30000 milliseconds with 0 out of 0 bytes received]
  - Curl error (28): Timeout was reached for https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-31&arch=x86_64 [Operation timed out after 30001 milliseconds with 0 out of 0 bytes received]
Error: Failed to download metadata for repo 'fedora-modular': Cannot prepare internal mirrorlist: Curl error (28): Timeout was reached for https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-31&arch=x86_64 [Operation timed out after 30000 milliseconds with 0 out of 0 bytes received]
[user@fedora-31-work ~]$

On Tue, May 26, 2020 at 3:45 PM Sven Semmler <sv...@svensemmler.org> wrote:

The purist idea is:

        - templates are never connected to a netvm
        - you never run any programs in a template (except dnf)

Your actual issue above can be solved by temporarily giving your template
sys-firewall as a netvm for update process. My reading is that the
upgrade process needs to accress mirrors.fedoraproject.org and can't do
so through the UpdateProxy.

This is maybe a security risk, but a rather small one from my
perspective. But I don't know you thread model, nor which attacks this
would enable.

If you go this way, don't forget to remove the netvm access again after
the upgrade.

/Sven

Sven Semmler

unread,
May 26, 2020, 6:41:13 PM5/26/20
to Riverborne, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Tue, May 26, 2020 at 04:59:51PM +0000, Riverborne wrote:
> Apparently, it connected, but timed out on mirrors.fedoraproject.org. May I
> again ask your advise? It shouldn't be because of my internet connection,
> which is pretty good (fiber to the curb). Thanks again for your help.
> Terminal transcript:
>
> [user@fedora-31-work ~]$ sudo dnf clean all
> > 53 files removed
> > [user@fedora-31-work ~]$ sudo dnf --releasever=31 distro-sync --best
> > --allowerasing
> > Fedora Modular 31 - x86_64 0.0 B/s | 0 B
> > 03:18
> > Errors during downloading metadata for repository 'fedora-modular':
> > - Curl error (35): SSL connect error for
> > https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-31&arch=x86_64
> > [OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to
> > mirrors.fedoraproject.org:443 ]
> > - Curl error (28): Timeout was reached for

Can you try 'curl -v
https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-31&arch=x86_64'
and report what it says?

/Sven


- --
public key: https://www.svensemmler.org/0x8F541FB6.asc
fingerprint: D7CA F2DB 658D 89BC 08D6 A7AA DA6E 167B 8F54 1FB6

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE18ry22WNibwI1qeq2m4We49UH7YFAl7Nmv8ACgkQ2m4We49U
H7ZOjRAA2lg/c/OhFoXgYBP9zdk0bhzIyQ0FUNQGSL5dmTSPoQVgJskF/Gp2KmQj
IW9iEeF7mW+hpHoxfuwQK4U6LLZR6S5LWui8rD9HCIq6jNgX1Rpy7PRUF6VTcEDQ
uDL2YK8LReog2+fhKN8H5nGR6/gAoSYZGoeppLmZHn2qDUl3DWg4soPWvFBULEFJ
NGTuvnzEltVmHcCWlb+Y83jVq0xs8RlqdbCUQj0YdxEVy+c4jAgCUrCG4GsMjQ3p
R8jz6Yd6038gHyLdj25rE3dnWiJW0Ba4gzge910tJ6hj47Qbn6FIEE74iFOgio6p
OmQ45nwmqo63lmbQzSGNh+VZQ9rd+c6gaKhMaRbgOVWDlSo6nRxU+abQiE8GYQed
l8DafwFONmIFU52dogg/wucPlARpbiTdyExeAz0SVyFWhoJiCh6nAuwkU+wp/6zT
BQ6ZP2mv4n4CiTZkaJw//eODLhQxwsYqf2tOAj5PZK7X8lNB9+XukSsGr+j3e/6s
acqNi8ooqrvUYGZDzbV2EK0TqQPOrD+wvhtih6EMBoCY7Y9GzhN66UGXSxmNlbBh
RziuRHx4i9uzO6ou3VJhvV3yCWjf/BSUGRm7iKP04YgryLJ0yGk7Da+3bKsZ+HGc
fkrO8bCUBe9Ai9SNngIhF9nq5jxTCnHRSrbrW6mMeNgGWult9fA=
=J9Rd
-----END PGP SIGNATURE-----

Riverborne

unread,
May 26, 2020, 7:55:33 PM5/26/20
to qubes...@googlegroups.com, sv...@svensemmler.org
Looks like a connection; didn't return to my prompt, so I suppose it's still connected waiting for another instruction? I left the connection as is until I hear back from you.

[user@fedora-31-work ~]$ curl -v https://mirrors.fedoraproject.org/metalink?repo-fedora-modular-31&arch=x86_64
[1] 1548
[user@fedora-31-work ~]$ *   Trying 67.219.144.68:443...
* TCP_NODELAY set
* Connected to mirrors.fedoraproject.org (67.219.144.68) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=North Carolina; L=Raleigh; O=Red Hat, Inc.; CN=*.fedoraproject.org
*  start date: Feb 27 00:00:00 2020 GMT
*  expire date: Mar  2 12:00:00 2022 GMT
*  subjectAltName: host "mirrors.fedoraproject.org" matched cert's "*.fedoraproject.org"
*  issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 High Assurance Server CA
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x644318f877f0)
> GET /metalink?repo-fedora-modular-31 HTTP/2
> Host: mirrors.fedoraproject.org
> User-Agent: curl/7.65.3
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 200
< date: Tue, 26 May 2020 23:41:56 GMT
< server: Apache
< x-frame-options: SAMEORIGIN
< x-xss-protection: 1; mode=block
< x-content-type-options: nosniff
< referrer-policy: same-origin
< content-type: application/metalink+xml
< content-length: 304
< apptime: D=1515
< x-fedora-proxyserver: proxy11.fedoraproject.org
< x-fedora-requestid: Xs2pRCegdQq1j1wKFOa7dQAAAAE
<
<?xml version="1.0" encoding="utf-8"?>
<metalink version="3.0" xmlns="http://www.metalinker.org/" type="dynamic" pubdate="Tue, 26 May 2020 23:41:56 GMT" generator="mirrormanager" xmlns:mm0="http://fedorahosted.org/mirrormanager">
<!-- # either path=, or repo= and arch= must be specified
-->
</metalink>
* Connection #0 to host mirrors.fedoraproject.org left intact

Sven Semmler

unread,
May 26, 2020, 9:45:37 PM5/26/20
to Riverborne, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Tue, May 26, 2020 at 11:54:57PM +0000, Riverborne wrote:
> Looks like a connection; didn't return to my prompt, so I suppose it's
> still connected waiting for another instruction? I left the connection as
> is until I hear back from you.

Yeah, that looks OK. So it must be something with the UpdateProxy.

- - when you just check for updates in your fedora-30-work template ...
what happens? does it work normally?

- - please compare 'qvm-features fedora-30-work' with 'qvm-features
fedora-31-work'

- - if you have the time / space it would be a cool experiment to clone
your fedora-31-work into a standalone VM (these are not connected to
the UpdateProxy by default) and repeat the upgrade attempt.

Reason: if it works in the standalone VM then we know it's the
UpdateProxy

qvm-clone --class StandaloneVM fedora-31-work
fedora-31-work-test

/Sven

- --
public key: https://www.svensemmler.org/0x8F541FB6.asc
fingerprint: D7CA F2DB 658D 89BC 08D6 A7AA DA6E 167B 8F54 1FB6

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE18ry22WNibwI1qeq2m4We49UH7YFAl7NxjkACgkQ2m4We49U
H7YrFRAAigRVjQYB947LGzb4ra/O32SjymEnGYjiWtCglfKJmVi9MtngaG4d0DuY
S4D0J1kEnFVvPmAsJjS8Y2GaZGUoMav/BeJ17ZCW5dSzQxZOqw2QB1Gy4n0LWxCz
lvtDNDLAENG7aJXFKOpp2PTMo8jG4rA8Rho+Cv3iNenfuUDICV2fUvKdPEJXaXLT
3FfqUzw7rmUgGRY5UNOTmWy96wXYV7wAIX1KyU9IO/I1XgkMoHYJqm140QG37r5I
OAUKnZW289U0ZZf7qyz/Ihq6qJ9/mkRByeVCqnIvJFxW70dJ/CMSsradfvdlFOVN
DS9gyC3I9Kq0wWmoI8UBHJBLqgtglCbNSKDXtPVkcTTelEuBeOeZZjkC2ZzADR1C
10bHJ2dhtx2Ym4+sJVZNg4UkgfcdIvPTs/4cUIlPlJujDQjo5XNiSVzHdhS2Homc
PkVgFgLuy4r9kNPe8nfcnValQ27yuGga4ulCDymhDCMzfHoQor5ncOma+tw06vnD
0QaLQWOtl/HuXUXTGmOTYwpyBXrJ+WCt4+kZK6zcya5Q+di2YlzIlt4Ne2gUMb9r
w8YCLftd8iHpLKnLsu716K5Rs+beVNvTR2mL/a+DkanXmCdB/UINhQi6gMA111B2
lgqDAAys50PYh929Oz0iOD9AV4BM+tMgQWZNh3CW76tc+3sT3oM=
=l+Gk
-----END PGP SIGNATURE-----

Frédéric Pierret

unread,
May 27, 2020, 3:04:51 AM5/27/20
to Dave, qubes-users
> --
> 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 <mailto:qubes-users...@googlegroups.com>.
> To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/c617677a-28b8-4ab1-ba22-e9b9b193cad4%40googlegroups.com <https://groups.google.com/d/msgid/qubes-users/c617677a-28b8-4ab1-ba22-e9b9b193cad4%40googlegroups.com?utm_medium=email&utm_source=footer>.

Unless you have specific needs for modular itself, we disable them by default in builds because we don't need them. So if you don't, simply disable them. Unfortunately, this is a recurrent problem with modular repos which are subject to very unstable behavior.

Best,
Frédéric

signature.asc

Dave

unread,
May 27, 2020, 8:17:28 AM5/27/20
to qubes-users


- - when you just check for updates in your fedora-30-work template ...
  what happens? does it work normally?

Yes; Qubes Manager Updater manages all my templates normally; Fedora templates get updated nearly once a day - sometimes more
 
- - please compare 'qvm-features fedora-30-work' with 'qvm-features
  fedora-31-work'
 
QVM features are equivalent:

[David@dom0 ~]$ qvm-features fedora-30-work
supported-service.network-manager      1
qrexec                                 1
supported-service.clocksync            1
os                                     Linux
qubes-firewall                         1
gui                                    1
supported-service.qubes-firewall       1
supported-service.qubes-updates-proxy  1
supported-service.modem-manager        1
supported-service.qubes-update-check   1
supported-service.cups                 1
supported-service.meminfo-writer       1
supported-service.updates-proxy-setup  1
supported-service.qubes-network        1
updates-available                      1

[David@dom0 ~]$ qvm-features fedora-31-work
supported-service.network-manager      1
qrexec                                 1
supported-service.clocksync            1
os                                     Linux
supported-service.modem-manager        1
gui                                    1
supported-service.qubes-firewall       1
supported-service.qubes-updates-proxy  1
supported-service.qubes-update-check   1
qubes-firewall                         1
supported-service.cups                 1
supported-service.meminfo-writer       1
supported-service.updates-proxy-setup  1
supported-service.qubes-network        1
updates-available     

Will create Standalone Fedora-31-work-test after I "create" some coffee haha - breakfast creation can wait :-p  - David

Dave

unread,
May 27, 2020, 10:30:30 AM5/27/20
to qubes-users
Sven,
The upgrade process for Standalone Fedora-31-work-test worked up until the end when it complained about disk space.
If necessary, I can add disk space and rerun it, but does this prove your suspicion regarding UpgradeProxy?
What about Frédéric's comment to "disable modular"? Wouldn't it be written into the command script:
dnf --releasever=<new> distro-sync --best --allowerasing
* terminal transcript attached

Keeping you busy, huh? Always good to learn something. Thanks a heap for taking this on.
Upgrade Standalone Fedora-30->31

dhorf-hfre...@hashmail.org

unread,
May 27, 2020, 11:06:53 AM5/27/20
to Dave, qubes-users
On Wed, May 27, 2020 at 07:30:29AM -0700, Dave wrote:
> The upgrade process for Standalone Fedora-31-work-test worked up until the
> end when it complained about disk space.

> *dnf --releasever=<new> distro-sync --best* --allowerasing

uh, since you do not seem to follow the fedora upgrade guide regarding
space management, this result is rather ... unsurprising.

to make extra space available for the update, you can use
mkfs.ext4 /dev/xvdc3
mount /dev/xvdc3 /mnt/removable
and add "--setopt=cachedir=/mnt/removable" to the dnf call.
(thats a lot less steps than in the official docs and will cleanup
itself too)



Sven Semmler

unread,
May 27, 2020, 11:24:43 AM5/27/20
to Dave, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Wed, May 27, 2020 at 07:30:29AM -0700, Dave wrote:
> The upgrade process for Standalone Fedora-31-work-test worked up until the
> end when it complained about disk space.
> If necessary, I can add disk space and rerun it, but does this prove your
> suspicion regarding UpgradeProxy?

It does. It also shows us a workaround. Just like you created the
Standalone VM by qvm-clone --class StandaloneVM you can do the same
after a successful upgrade...

qvm-remove fedora-31-work
qvm-clone --class TemplateVM fedora-31-work-test fedora-31-work
qvm-remove fedora-31-work-test

> What about Frédéric's comment to "disable modular"? Wouldn't it be written
> into the command script:
> *dnf --releasever=<new> distro-sync --best* --allowerasing
> * terminal transcript attached

I have no idea, but he is one of the core developers and from his
comment I gather this is a rather routine issue.

I imagine something like 'dnf config-manager --set-disabled
fedora-modular' should do it?

> Keeping you busy, huh? Always good to learn something. Thanks a heap for
> taking this on.

I am actually figuring this out together with you. It's a learning thing
for me too. ;-)

/Sven

- --
public key: https://www.svensemmler.org/0x8F541FB6.asc
fingerprint: D7CA F2DB 658D 89BC 08D6 A7AA DA6E 167B 8F54 1FB6

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE18ry22WNibwI1qeq2m4We49UH7YFAl7OhjAACgkQ2m4We49U
H7ZBnBAAxyt2eUlQ7uGwcNfDKsQyQD1lAgln3mUb947Y9oNCGBgfxozuzdWhfI64
NRvBy7VctHVvxJ27zi+b4CEzgS/eB17BtPXLvzIvULSoyO2CvCjyHgNLfa6f72TZ
Hq3YsTg1VIOVVyJnfPcGkNFKiwY1uVrXpIaonmqBdF/nYWZENWQe25fRy073FPb/
HlSIrb6UK6gJXcIlkHyaHu4ychOFoPd0NC6htG4cPq/8DcH1qqTdIl08X/XPLta8
KR5V1042w1/QOe5kzqllFV3CNcOC4SX6g6lA+CAcpeI1Ac9wxXk0FjoeW9pNBZZE
6pJwIDzS7S9uNeGKbZB8XWBqUVRHa9Zia6YC//E9av9S/k2ijwphSiYe6Z72Mi+L
gqDuYYBMWf0fXEqy4ah68F0S4oXMTZNU7PcazaOu5B/n9gfR51V0uRSwH1E8mKML
sGpiGa08nK//BqgCoVkcjkgZ4SWVbQBj9xFAv7+rHg6wrXF12TZEJt4CEBErIt89
QWU+WcPoqiDHmP3161BUQlquPuTALSAvNcxTlAYvmKPobDfwEuLdrsHNCiOa2tb2
VchwxxzhyhHHHxxpx/9xdcomLIT+MbQcDcgk4cjZW8xtP+E7kJf6glJjFqEOOnaH
PP7OWw9nBoW4nUO4VP+kyBowBq7N8CT7wmO2QgGGIHutWD+H3Qw=
=fCw5
-----END PGP SIGNATURE-----

Frédéric Pierret

unread,
May 27, 2020, 11:27:29 AM5/27/20
to Dave, qubes-users


On 2020-05-27 17:24, Sven Semmler wrote:
> On Wed, May 27, 2020 at 07:30:29AM -0700, Dave wrote:
>> The upgrade process for Standalone Fedora-31-work-test worked up until the
>> end when it complained about disk space.
>> If necessary, I can add disk space and rerun it, but does this prove your
>> suspicion regarding UpgradeProxy?
>
> It does. It also shows us a workaround. Just like you created the
> Standalone VM by qvm-clone --class StandaloneVM you can do the same
> after a successful upgrade...
>
> qvm-remove fedora-31-work
> qvm-clone --class TemplateVM fedora-31-work-test fedora-31-work
> qvm-remove fedora-31-work-test
>
>> What about Frédéric's comment to "disable modular"? Wouldn't it be written
>> into the command script:
>> *dnf --releasever=<new> distro-sync --best* --allowerasing
>> * terminal transcript attached
>
> I have no idea, but he is one of the core developers and from his
> comment I gather this is a rather routine issue.
>
> I imagine something like 'dnf config-manager --set-disabled
> fedora-modular' should do it?

CLI way: simply set 'enabled=0' in /etc/yum.repos.d/fedora-modular.repo (TemplateVM :) )

>> Keeping you busy, huh? Always good to learn something. Thanks a heap for
>> taking this on.
>
> I am actually figuring this out together with you. It's a learning thing
> for me too. ;-)
>
> /Sven
>
>

Best,
Frédéric

signature.asc

Dave

unread,
May 30, 2020, 11:25:21 AM5/30/20
to qubes-users
On Wednesday, May 27, 2020 at 3:27:29 PM UTC, Frédéric Pierret wrote:

CLI way: simply set 'enabled=0' in /etc/yum.repos.d/fedora-modular.repo (TemplateVM :) )

On Wednesday, May 27, 2020 at 7:04:51 AM UTC, Frédéric Pierret wrote:

Unless you have specific needs for modular itself, we disable them by default in builds because we don't need them. So if you don't, simply disable them. Unfortunately, this is a recurrent problem with modular repos which are subject to very unstable behavior.


Frédéric,

With the editor, I opened  /etc/yum.repos.d/fedora-modular.repo and found 1 of the 3 classes, or whatever they are, is enabled, but since this is the first I've touched it, not sure how it came to be, if "we disable them by default in builds". I changed it to "0" and will check the other templates. Thanks for your help. - David

name=Fedora Modular $releasever - $basearch
#baseurl=http://download.example/pub/fedora/linux/releases/$releasever/Modular/$basearch/os/
metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-$releasever&arch=$basearch
enabled=1
#metadata_expire=7d
repo_gpgcheck=0
type=rpm
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
skip_if_unavailable=False

[fedora-modular-debuginfo]
name=Fedora Modular $releasever - $basearch - Debug
#baseurl=http://download.example/pub/fedora/linux/releases/$releasever/Modular/$basearch/debug/tree/
metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-debug-$releasever&arch=$basearch
enabled=0
metadata_expire=7d
repo_gpgcheck=0
type=rpm
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
skip_if_unavailable=False

[fedora-modular-source]
name=Fedora Modular $releasever - Source
#baseurl=http://download.example/pub/fedora/linux/releases/$releasever/Modular/source/tree/
metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-source-$releasever&arch=$basearch
enabled=0
metadata_expire=7d
repo_gpgcheck=0
type=rpm
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
skip_if_unavailable=False

Dave

unread,
May 30, 2020, 11:33:56 AM5/30/20
to qubes-users
Sven, Unman, Frédéric, dhorf -

We're done; thanks everyone!
Reply all
Reply to author
Forward
0 new messages