Re: DNF and broken upgrades

[Matthew Miller]

On Sun, Aug 06, 2017 at 06:16:43PM +0100, Russel Winder wrote:
> > I think `dnf distro-sync` should do it.
> I tried that but can't remember the exact output. It didn't do anything
> positive though. :-(

Maybe with --best and --allow-erasing?


-- 
Matthew Miller

Fedora Project Leader
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org

Re: DNF and broken upgrades

[Russel Winder]

On Sun, 2017-08-06 at 07:49 -0400, Matthew Miller wrote:
> 
[…]
> I think `dnf distro-sync` should do it.

I tried that but can't remember the exact output. It didn't do anything
positive though. :-(

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc
Description: This is a digitally signed message part
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org

Fedora Rawhide-20170806.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Atomic qcow2 x86_64
Workstation live i386
Server boot i386
Atomic raw-xz x86_64
Kde live i386

Failed openQA tests: 27/137 (x86_64), 3/18 (i386), 1/2 (arm)

New failures (same test did not fail in Rawhide-20170805.n.0):

ID: 126817  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/126817
ID: 126818  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/126818
ID: 126837  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/126837
ID: 126847  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/126847
ID: 126895  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/126895

Old failures (same test failed in Rawhide-20170805.n.0):

ID: 126799  Test: x86_64 Server-dvd-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/126799
ID: 126806  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/126806
ID: 126819  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/126819
ID: 126821  Test: x86_64 Workstation-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/126821
ID: 126832  Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/126832
ID: 126833  Test: x86_64 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/126833
ID: 126834  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/126834
ID: 126835  Test: x86_64 Workstation-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/126835
ID: 126836  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/126836
ID: 126838  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/126838
ID: 126849  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/126849
ID: 126851  Test: x86_64 Atomic-dvd_ostree-iso install_default
URL: https://openqa.fedoraproject.org/tests/126851
ID: 126853  Test: x86_64 Workstation-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/126853
ID: 126855  Test: x86_64 Workstation-dvd_ostree-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/126855
ID: 126887  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/126887
ID: 126889  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/126889
ID: 126891  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/126891
ID: 126892  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/126892
ID: 126894  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/126894
ID: 126896  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/126896
ID: 126897  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/126897
ID: 126931  Test: x86_64 universal install_rescue_encrypted
URL: https://openqa.fedoraproject.org/tests/126931
ID: 126932  Test: x86_64 universal install_rescue_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/126932
ID: 126947  Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/126947
ID: 126948  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/126948
ID: 126949  Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/126949

Soft failed openQA tests: 61/137 (x86_64), 14/18 (i386)
(Tests completed, but using a workaround for a known bug)

New soft failures (same test did not soft fail in Rawhide-20170805.n.0):

ID: 126805  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/126805
ID: 126864  Test: x86_64 universal install_blivet_no_swap
URL: https://openqa.fedoraproject.org/tests/126864
ID: 126866  Test: x86_64 universal install_blivet_software_raid
URL: https://openqa.fedoraproject.org/tests/126866
ID: 126945  Test: i386 universal install_blivet_software_raid
URL: https://openqa.fedoraproject.org/tests/126945

Old soft failures (same test soft failed in Rawhide-20170805.n.0):

ID: 126794  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/126794
ID: 126795  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/126795
ID: 126796  Test: x86_64 Server-dvd-iso install_default_upload

Re: DNF and broken upgrades

[Matthew Miller]

On Sun, Aug 06, 2017 at 10:33:49AM +0100, Russel Winder wrote:
> If there are one or two I remove the newest version manually and then
> do the upgrade again. For 835 I am not about to even start this
> process. "dnf remove --duplicates" refused to work because some of the
> duplicates were protected. dnf and systemd in particular. OK so I can
> handle doing those manually using the "--setopt=protected_package="
> options so as to be able to remove the newest version. So dnf and
> systemd fully up to date.

I think this is a bug. The protected-packages thing shouldn't block
dupes from being removed, just make sure there's at least one
functional package (of the primary architecture!).


> I am thinking that "dnf remove --duplicates" isn't actually the right
> way of fixing this sort of problem, that there is a better way of
> handling barfed upgrades.


I think `dnf distro-sync` should do it.



-- 
Matthew Miller

Fedora Project Leader
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org

DNF and broken upgrades

[Russel Winder]

I have just completed the recent Big Rawhide Upgrade on my
laptops/workstations. I will admit to not using the lowest risk way of
upgrading mostly because I don't want to have to work with each machine
physically individually. I generally use an SSH login from another
machine to keep the risk at Bash and Network Manager upgrade problems.
This morning I got lazy (having upgraded the laptops using the normal
approach) and upgraded my workstation from a terminal in an Wayland
session on the workstation itself. Normally this is OK, today it
failed.

Part way through the "dnf upgrade", the terminal crashed, leaving me
with masses of downloaded and installed but not yet upgraded packages.
So I ended up with what dnf said was a fully upgraded machines and yet
there were 835 duplicates, as reported by "dnf check".

If there are one or two I remove the newest version manually and then
do the upgrade again. For 835 I am not about to even start this
process. "dnf remove --duplicates" refused to work because some of the
duplicates were protected. dnf and systemd in particular. OK so I can
handle doing those manually using the "--setopt=protected_package="
options so as to be able to remove the newest version. So dnf and
systemd fully up to date.

Now "dnf remove --duplicates" works – which is good. :-) However,…

The "dnf list --installed" listing shows all the new packages from
@System not from @rawhide. I am hoping this doesn't matter, but it is
annoying. This is not the case for the package removed and re-upgraded
manually, just for the ones 'fixed' using "dnf remove --duplicates".

I am thinking that "dnf remove --duplicates" isn't actually the right
way of fixing this sort of problem, that there is a better way of
handling barfed upgrades.

I also notice that "dnf list --showduplicates" highlights a lot of
entries but there is no clear indication of what the problem is.
 
-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc
Description: This is a digitally signed message part
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org