F34 update experience

[Neal Becker]

Updated F33 -> F34.  Mostly went well, except there is one thing which
could be better.  This is not new to F34 but has been there since the
dnf system-upgrade.

Running on a pretty decent laptop (core i7, 8GB, SSD).  The issue is
that the installation hangs a long time with no evidence of activity.
The hang begins at
dnf running transaction.  It is disconcerting because it hangs for
about 20-30 minutes, and during that time the fan is not running, so
no evidence of cpu usage.  There seems to be no way to switch VT to
try to see what's happening.  I'd hate to see what happens on a less
capable machine.

I wish there was some way to get some better feedback that the update is alive.

-- 
Those who don't understand recursion are doomed to repeat it

[Zbigniew Jędrzejewski-Szmek]

On Tue, Apr 27, 2021 at 10:04:34AM -0400, Neal Becker wrote:
>  Updated F33 -> F34.  Mostly went well, except there is one thing
> which
>  could be better.  This is not new to F34 but has been there since the
>  dnf system-upgrade.
>  
>  Running on a pretty decent laptop (core i7, 8GB, SSD).  The issue is
>  that the installation hangs a long time with no evidence of activity.
>  The hang begins at
>  dnf running transaction.  It is disconcerting because it hangs for
>  about 20-30 minutes, and during that time the fan is not running, so 
20-30 minutes seems unexpected… There is a phase where dnf is solving
the deps, but it's usually much much shorter (*), and it's CPU-bound,
so the fans should be on. I don't know what's going on in your case,
but it sounds like some bug.

Do you have a huge number of packages? Lot's of modules? A very slow disk?

Zbyszek

(*) I was upgrading a rpi3 recently, and I had to wait a few minutes...
But on a beefy machine, anything above a few dozen seconds is suspicious.

[Neal Becker]

As I said, the machine has an ssd.  But it has a very large number of
packages.  It's used for development so has lots of devel pkgs, and a large
selection of the live.

On Tue, Apr 27, 2021, 12:10 PM Zbigniew Jędrzejewski-Szmek <
zbyszek(a)in.waw.pl&gt; wrote:

>  On Tue, Apr 27, 2021 at 10:04:34AM -0400, Neal Becker wrote:
>  > Updated F33 -> F34.  Mostly went well, except there is one thing which
>  > could be better.  This is not new to F34 but has been there since the
>  > dnf system-upgrade.
>  >
>  > Running on a pretty decent laptop (core i7, 8GB, SSD).  The issue is
>  > that the installation hangs a long time with no evidence of activity.
>  > The hang begins at
>  > dnf running transaction.  It is disconcerting because it hangs for
>  > about 20-30 minutes, and during that time the fan is not running, so
>
>  20-30 minutes seems unexpected… There is a phase where dnf is solving
>  the deps, but it's usually much much shorter (*), and it's CPU-bound,
>  so the fans should be on. I don't know what's going on in your case,
>  but it sounds like some bug.
>
>  Do you have a huge number of packages? Lot's of modules? A very slow disk?
>
>  Zbyszek
>
>  (*) I was upgrading a rpi3 recently, and I had to wait a few minutes...
>  But on a beefy machine, anything above a few dozen seconds is suspicious.
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure
>

[Tomasz Torcz]

Dnia Tue, Apr 27, 2021 at 04:08:38PM +0000, Zbigniew Jędrzejewski-Szmek napisał(a):
>  On Tue, Apr 27, 2021 at 10:04:34AM -0400, Neal Becker wrote:
>  > Updated F33 -> F34.  Mostly went well, except there is one thing which
>  > could be better.  This is not new to F34 but has been there since the
>  > dnf system-upgrade.
>  > 
>  > Running on a pretty decent laptop (core i7, 8GB, SSD).  The issue is
>  > that the installation hangs a long time with no evidence of activity.
>  > The hang begins at
>  > dnf running transaction.  It is disconcerting because it hangs for
>  > about 20-30 minutes, and during that time the fan is not running, so
>  
>  20-30 minutes seems unexpected… There is a phase where dnf is solving
>  the deps, but it's usually much much shorter (*), and it's CPU-bound,
>  so the fans should be on. I don't know what's going on in your case,
>  but it sounds like some bug. 
  In 2019 I did some measurements of F31→F32. First step of distribution upgrade
took 16 minutes on a desktop computer. The results are at
https://enotty.pipebreaker.pl/posts/2019/12/time-needed-to-dist-upgrade-f...

>  Do you have a huge number of packages? Lot's of modules? A very
> slow disk? 
 `rpm -qa` returns 3109. No modules (I think). Storage is btrfs raid1
over 2xHDD (5900 RPM) + bcache with 2x384GiB partitions.

-- 
Tomasz   .. oo o.   oo o. .o   .o o. o. oo o.   ..
Torcz    .. .o .o   .o .o oo   oo .o .. .. oo   oo
o.o.o.   .o .. o.   o. o. o.   o. o. oo .. ..   o.

[Neal Becker]

rpm -qa | wc - reports 5939

On Tue, Apr 27, 2021 at 2:13 PM Tomasz Torcz <tomek(a)pipebreaker.pl&gt; wrote:
>  Dnia Tue, Apr 27, 2021 at 04:08:38PM +0000, Zbigniew Jędrzejewski-Szmek napisał(a):
>  > On Tue, Apr 27, 2021 at 10:04:34AM -0400, Neal Becker wrote:
>  > > Updated F33 -> F34.  Mostly went well, except there is one thing which
>  > > could be better.  This is not new to F34 but has been there since the
>  > > dnf system-upgrade.
>  > >
>  > > Running on a pretty decent laptop (core i7, 8GB, SSD).  The issue is
>  > > that the installation hangs a long time with no evidence of activity.
>  > > The hang begins at
>  > > dnf running transaction.  It is disconcerting because it hangs for
>  > > about 20-30 minutes, and during that time the fan is not running, so
>  >
>  > 20-30 minutes seems unexpected… There is a phase where dnf is solving
>  > the deps, but it's usually much much shorter (*), and it's CPU-bound,
>  > so the fans should be on. I don't know what's going on in your case,
>  > but it sounds like some bug.
>
>    In 2019 I did some measurements of F31→F32. First step of distribution upgrade
>  took 16 minutes on a desktop computer. The results are at
>  https://enotty.pipebreaker.pl/posts/2019/12/time-needed-to-dist-upgrade-f...
>
>  > Do you have a huge number of packages? Lot's of modules? A very slow disk?
>
>   `rpm -qa` returns 3109. No modules (I think). Storage is btrfs raid1
>  over 2xHDD (5900 RPM) + bcache with 2x384GiB partitions.
>
>  --
>  Tomasz   .. oo o.   oo o. .o   .o o. o. oo o.   ..
>  Torcz    .. .o .o   .o .o oo   oo .o .. .. oo   oo
>  o.o.o.   .o .. o.   o. o. o.   o. o. oo .. ..   o.
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure


-- 
Those who don't understand recursion are doomed to repeat it

Another F34 update experience : gtatools-*

[przemek klosowski]

Trying to update F33 -> F34 on a development laptop with about 4700 
packages. I think it started as F30 and did three Fedora system upgrades.

I did the standard

    dnf upgrade --refresh

    dnf system-upgrade --releasever=34 download

I am getting four errors:


  Problem 1: package gtatool-gdal-2.2.3-6.fc33.x86_64 requires 
libgdal.so.27()(64bit), but none of the providers can be installed
   - gdal-libs-3.1.4-2.fc33.x86_64 does not belong to a distupgrade 
repository
   - problem with installed package gtatool-gdal-2.2.3-6.fc33.x86_64
  Problem 2: package gtatool-matlab-2.2.3-6.fc33.x86_64 requires 
libmatio.so.9()(64bit), but none of the providers can be installed
   - matio-1.5.17-4.fc33.x86_64 does not belong to a distupgrade repository
   - problem with installed package gtatool-matlab-2.2.3-6.fc33.x86_64
  Problem 3: rdma-core-34.0-1.fc33.i686 has inferior architecture
   - rdma-core-34.0-1.fc33.x86_64 does not belong to a distupgrade 
repository
   - problem with installed package rdma-core-34.0-1.fc33.i686
  Problem 4: package openexr-libs-2.5.5-1.fc34.x86_64 obsoletes 
OpenEXR-libs < 2.5.3 provided by OpenEXR-libs-2.3.0-8.fc34.x86_64
   - package Field3D-1.7.3-10.fc34.x86_64 requires 
libHalf-2_5.so.25()(64bit), but none of the providers can be installed
   - package Field3D-1.7.3-10.fc34.x86_64 requires 
libImath-2_5.so.25()(64bit), but none of the providers can be installed
   - package gtatool-hdr-2.2.3-6.fc33.x86_64 requires 
libIlmImf-2_3.so.24()(64bit), but none of the providers can be installed
   - problem with installed package Field3D-1.7.3-5.fc33.x86_64
   - OpenEXR-libs-2.3.0-6.fc33.x86_64 does not belong to a distupgrade 
repository
   - Field3D-1.7.3-5.fc33.x86_64 does not belong to a distupgrade repository
   - problem with installed package gtatool-hdr-2.2.3-6.fc33.x86_64

The first three can be solved by erasing gtatool-gdal, gtatool-matlab 
and rdma-core-34.0-1.fc33.i686. The first two are relatively painless, 
but rdma-core forces the removal of the entire Wine installation--I did 
it and plan/hope to reinstall Wine after the upgrade.

The fourth problem looks like requiring removal of OpenEXR-libs, but 
that forces removal of 121 packages including ImageMagick, gimp, 
blender, lyx and texlive, which seemed harsh.

It turns out that it can be solved by removing gtatool-hdr, though! This 
wasn't obvious to me at first sight---I only tried it because of the 
other gtatool-* packages causing problems, prejudicing me slightly.

I haven't reported it in Bugzilla yet---what package should I report it 
against? OpenEXR-libs? gtatool-hdr?

Another F34 update experience : gtatools-*

[Adam Williamson]

On Wed, 2021-04-28 at 17:42 -0400, przemek klosowski via devel wrote:
>  Trying to update F33 -> F34 on a development laptop with about
> 4700 
>  packages. I think it started as F30 and did three Fedora system upgrades.
>  
>  I did the standard
>  
>      dnf upgrade --refresh
>  
>      dnf system-upgrade --releasever=34 download
>  
>  I am getting four errors:
>  
>  
>    Problem 1: package gtatool-gdal-2.2.3-6.fc33.x86_64 requires 
>  libgdal.so.27()(64bit), but none of the providers can be installed
>     - gdal-libs-3.1.4-2.fc33.x86_64 does not belong to a distupgrade 
>  repository
>     - problem with installed package gtatool-gdal-2.2.3-6.fc33.x86_64
>    Problem 2: package gtatool-matlab-2.2.3-6.fc33.x86_64 requires 
>  libmatio.so.9()(64bit), but none of the providers can be installed
>     - matio-1.5.17-4.fc33.x86_64 does not belong to a distupgrade repository
>     - problem with installed package gtatool-matlab-2.2.3-6.fc33.x86_64
>    Problem 3: rdma-core-34.0-1.fc33.i686 has inferior architecture
>     - rdma-core-34.0-1.fc33.x86_64 does not belong to a distupgrade 
>  repository
>     - problem with installed package rdma-core-34.0-1.fc33.i686
>    Problem 4: package openexr-libs-2.5.5-1.fc34.x86_64 obsoletes 
>  OpenEXR-libs < 2.5.3 provided by OpenEXR-libs-2.3.0-8.fc34.x86_64
>     - package Field3D-1.7.3-10.fc34.x86_64 requires 
>  libHalf-2_5.so.25()(64bit), but none of the providers can be installed
>     - package Field3D-1.7.3-10.fc34.x86_64 requires 
>  libImath-2_5.so.25()(64bit), but none of the providers can be installed
>     - package gtatool-hdr-2.2.3-6.fc33.x86_64 requires 
>  libIlmImf-2_3.so.24()(64bit), but none of the providers can be installed
>     - problem with installed package Field3D-1.7.3-5.fc33.x86_64
>     - OpenEXR-libs-2.3.0-6.fc33.x86_64 does not belong to a distupgrade 
>  repository
>     - Field3D-1.7.3-5.fc33.x86_64 does not belong to a distupgrade repository
>     - problem with installed package gtatool-hdr-2.2.3-6.fc33.x86_64
>  
>  The first three can be solved by erasing gtatool-gdal, gtatool-matlab 
>  and rdma-core-34.0-1.fc33.i686. The first two are relatively painless, 
>  but rdma-core forces the removal of the entire Wine installation--I did 
>  it and plan/hope to reinstall Wine after the upgrade. 
It's worth trying the upgrade with --allowerasing instead of rolling
your own erasures. It may be able to come up with a strategy that
involves removing less stuff.

In general, if the problem is basically "package X wasn't rebuilt for a
library soname bump", the appropriate step is to file a bug against
package X. For the gtatool stuff, though, it looks to me like it got
orphaned and retired, but has not been specifically obsoleted; we may
need to put it in fedora-obsolete-packages. There were several attempts
to rebuild it between July and November, but they all apparently failed
(well, the last seems to have succeeded but was never tagged and has
been garbage-collected), and now it's been orphaned.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

Another F34 update experience : gtatools-*

[przemek klosowski]

On 4/28/21 6:01 PM, Adam Williamson wrote:

>  On Wed, 2021-04-28 at 17:42 -0400, przemek klosowski via devel
> wrote:
> > Trying to update F33 -> F34 on a development laptop with about 4700
> > packages. I think it started as F30 and did three Fedora system upgrades.
> > ...
> >
> > I am getting four errors:
> > ...
> > The first three can be solved by erasing gtatool-gdal, gtatool-matlab
> > and rdma-core-34.0-1.fc33.i686. The first two are relatively painless,
> > but rdma-core forces the removal of the entire Wine installation--I did
> > it and plan/hope to reinstall Wine after the upgrade.
>  It's worth trying the upgrade with --allowerasing instead of rolling
>  your own erasures. It may be able to come up with a strategy that
>  involves removing less stuff. 
In my defense I am a little apprehensive about --allowerasing because I 
have a hole in my pants from being bitten by it years ago and having to 
rescue-install hundreds of packages including RPM :).  Of course I know 
that I don't have to worry about it any more because of protected 
packages---in fact one of my 'rolled-own' erasure pulled systemd and 
triggered the protected package fuse, so I know it works!

However, in this case, --best --allowerasing  trips up the following 
errors, while plain upgrade just skips packages with conflicts ( 
iptables-libs ) and broken dependencies (gst and gwe ).

  Problem 1: problem with installed package gst-0.7.4-2.fc33.noarch
   - cannot install the best update candidate for package 
gst-0.7.4-2.fc33.noarch
   - gst-0.7.4-2.fc33.noarch does not belong to a distupgrade repository
   - nothing provides python3-pyxdg >= 0.27 needed by 
gst-0.7.5-2.fc34.noarch
  Problem 2: problem with installed package gwe-0.15.2-1.fc33.noarch
   - cannot install the best update candidate for package 
gwe-0.15.2-1.fc33.noarch
   - gwe-0.15.2-1.fc33.noarch does not belong to a distupgrade repository
   - nothing provides python3-pyxdg >= 0.27 needed by 
gwe-0.15.3-1.fc34.noarch
  Problem 3: cannot install the best update candidate for package 
iptables-1.8.5-6.fc33.x86_64
   - problem with installed package iptables-1.8.5-6.fc33.x86_64
   - package iptables-1.8.7-3.fc34.x86_64 requires iptables-libs(x86-64) 
= 1.8.7-3.fc34, but none of the providers can be installed
   - cannot install the best update candidate for package 
iptables-libs-1.8.5-6.fc33.x86_64
   - cannot install both iptables-libs-1.8.7-3.fc34.x86_64 and 
iptables-libs-1.8.7-6.fc34.x86_64
   - iptables-1.8.5-6.fc33.x86_64 does not belong to a distupgrade 
repository
(try to add '--skip-broken' to skip uninstallable packages)

Indeed adding --best --allowerasing --skip-broken skips those three 
packages again, i.e. behaves like a plain system-upgrade with no options.

>  In general, if the problem is basically "package X wasn't
> rebuilt for a
>  library soname bump", the appropriate step is to file a bug against
>  package X. For the gtatool stuff, though, it looks to me like it got
>  orphaned and retired, but has not been specifically obsoleted; we may
>  need to put it in fedora-obsolete-packages. There were several attempts
>  to rebuild it between July and November, but they all apparently failed
>  (well, the last seems to have succeeded but was never tagged and has
>  been garbage-collected), and now it's been orphaned. 
So if they did succeed, wouldn't it make sense to include them? I am a 
reasonably heavy Octave user, and although I actually didn't have to 
load Matlab files recently, I think it is a useful feature. Maybe Orion 
has an opinion about this?

Another F34 update experience : gtatools-*

[Adam Williamson]

On Wed, 2021-04-28 at 18:43 -0400, przemek klosowski wrote:
>  On 4/28/21 6:01 PM, Adam Williamson wrote:
>  
>  > On Wed, 2021-04-28 at 17:42 -0400, przemek klosowski via devel wrote:
>  > > Trying to update F33 -> F34 on a development laptop with about 4700
>  > > packages. I think it started as F30 and did three Fedora system upgrades.
>  > > ...
>  > > 
>  > > I am getting four errors:
>  > > ...
>  > > The first three can be solved by erasing gtatool-gdal, gtatool-matlab
>  > > and rdma-core-34.0-1.fc33.i686. The first two are relatively painless,
>  > > but rdma-core forces the removal of the entire Wine installation--I did
>  > > it and plan/hope to reinstall Wine after the upgrade.
>  > It's worth trying the upgrade with --allowerasing instead of rolling
>  > your own erasures. It may be able to come up with a strategy that
>  > involves removing less stuff.
>  
>  In my defense I am a little apprehensive about --allowerasing because I 
>  have a hole in my pants from being bitten by it years ago and having to 
>  rescue-install hundreds of packages including RPM :).  Of course I know 
>  that I don't have to worry about it any more because of protected 
>  packages---in fact one of my 'rolled-own' erasure pulled systemd and 
>  triggered the protected package fuse, so I know it works! 
Also with system-upgrade there's always a confirmation step, so you can
just run it and see what it would do, and cancel if it wants to blow up
your system...

>  However, in this case, --best --allowerasing  trips up the following
>
>  errors, while plain upgrade just skips packages with conflicts ( 
>  iptables-libs ) and broken dependencies (gst and gwe ).
>  
>    Problem 1: problem with installed package gst-0.7.4-2.fc33.noarch
>     - cannot install the best update candidate for package 
>  gst-0.7.4-2.fc33.noarch
>     - gst-0.7.4-2.fc33.noarch does not belong to a distupgrade repository
>     - nothing provides python3-pyxdg >= 0.27 needed by 
>  gst-0.7.5-2.fc34.noarch
>    Problem 2: problem with installed package gwe-0.15.2-1.fc33.noarch
>     - cannot install the best update candidate for package 
>  gwe-0.15.2-1.fc33.noarch
>     - gwe-0.15.2-1.fc33.noarch does not belong to a distupgrade repository
>     - nothing provides python3-pyxdg >= 0.27 needed by 
>  gwe-0.15.3-1.fc34.noarch
>    Problem 3: cannot install the best update candidate for package 
>  iptables-1.8.5-6.fc33.x86_64
>     - problem with installed package iptables-1.8.5-6.fc33.x86_64
>     - package iptables-1.8.7-3.fc34.x86_64 requires iptables-libs(x86-64) 
>  = 1.8.7-3.fc34, but none of the providers can be installed
>     - cannot install the best update candidate for package 
>  iptables-libs-1.8.5-6.fc33.x86_64
>     - cannot install both iptables-libs-1.8.7-3.fc34.x86_64 and 
>  iptables-libs-1.8.7-6.fc34.x86_64
>     - iptables-1.8.5-6.fc33.x86_64 does not belong to a distupgrade 
>  repository
>  (try to add '--skip-broken' to skip uninstallable packages)
>  
>  Indeed adding --best --allowerasing --skip-broken skips those three 
>  packages again, i.e. behaves like a plain system-upgrade with no options. 
The iptables issue is known, see
https://bugzilla.redhat.com/show_bug.cgi?id=1953178 . Try without --
best - just with --allowerasing, or --allowerasing --skip-broken .

>  > In general, if the problem is basically "package X
> wasn't rebuilt for a
>  > library soname bump", the appropriate step is to file a bug against
>  > package X. For the gtatool stuff, though, it looks to me like it got
>  > orphaned and retired, but has not been specifically obsoleted; we may
>  > need to put it in fedora-obsolete-packages. There were several attempts
>  > to rebuild it between July and November, but they all apparently failed
>  > (well, the last seems to have succeeded but was never tagged and has
>  > been garbage-collected), and now it's been orphaned.
>  
>  So if they did succeed, wouldn't it make sense to include them? I am a 
>  reasonably heavy Octave user, and although I actually didn't have to 
>  load Matlab files recently, I think it is a useful feature. Maybe Orion 
>  has an opinion about this? 
Well, I can't really say. All I can see is what happened in Koji:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1641421
succeeded, but doesn't seem to have been tagged at all, and that's the
last time anyone touched the package. After that, it got orphaned and
auto-retired due to being orphaned for a set period of time.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net