Hi All,
Fedora 30
How do I fix this?
# dnf upgrade --refresh --disablerepo=brave* Fedora Modular 30 - x86_64 2.9 kB/s | 16 kB 00:05 Fedora Modular 30 - x86_64 - Updates 32 kB/s | 14 kB 00:00 Fedora 30 - x86_64 - Updates 34 kB/s | 15 kB 00:00 Fedora 30 - x86_64 60 kB/s | 16 kB 00:00 Bus error (core dumped)
Perplexed, -T
On 2020-04-22 13:45, ToddAndMargo via users wrote:
Hi All,
Fedora 30
How do I fix this?
# dnf upgrade --refresh --disablerepo=brave* Fedora Modular 30 - x86_64 2.9 kB/s | 16 kB 00:05 Fedora Modular 30 - x86_64 - Updates 32 kB/s | 14 kB 00:00 Fedora 30 - x86_64 - Updates 34 kB/s | 15 kB 00:00 Fedora 30 - x86_64 60 kB/s | 16 kB 00:00 Bus error (core dumped)
I've never encountered that error.
First stab, run "rpm --rebuilddb", and try again.
On 2020-04-21 22:55, Ed Greshko wrote:
rpm --rebuilddb
Hi Ed,
I happened after doing a # dnf upgrade and the upgrade froze for an hour on selinux policies
Now I get:
# rpm --rebuilddb
# dnf upgrade --refresh --disablerepo=* --enablerepo=fedora Fedora 30 - x86_64 3.0 kB/s | 16 kB 00:05 Bus error (core dumped)
-T
On 2020-04-22 14:00, ToddAndMargo via users wrote:
On 2020-04-21 22:55, Ed Greshko wrote:
rpm --rebuilddb
Hi Ed,
I happened after doing a # dnf upgrade and the upgrade froze for an hour on selinux policies
What did you do when it "froze"?
Now I get:
# rpm --rebuilddb
# dnf upgrade --refresh --disablerepo=* --enablerepo=fedora Fedora 30 - x86_64 3.0 kB/s | 16 kB 00:05 Bus error (core dumped)
On 2020-04-21 23:05, Ed Greshko wrote:
On 2020-04-22 14:00, ToddAndMargo via users wrote:
On 2020-04-21 22:55, Ed Greshko wrote:
rpm --rebuilddb
Hi Ed,
I happened after doing a # dnf upgrade and the upgrade froze for an hour on selinux policies
What did you do when it "froze"?
I did a ps and kill -9 on three dnf process
I did a reboot later trying to troubleshoot this. No joy.
# rpm -Va --nofiles --nodigest
return about 50 conflicts
This did not work:
# rm /var/lib/rpm/__db* rm: remove regular file '/var/lib/rpm/__db.001'? y rm: remove regular file '/var/lib/rpm/__db.002'? y rm: remove regular file '/var/lib/rpm/__db.003'? y
# dnf clean all 0 files removed (previous calls to this removed a lot of stuff)
# rpm --rebuilddb
# dnf upgrade --refresh --disablerepo=* --enablerepo=fedora Fedora 30 - x86_64 2.3 MB/s | 70 MB 00:30 Last metadata expiration check: 0:00:13 ago on Tue 21 Apr 2020 11:08:11 PM PDT. Bus error (core dumped)
On 2020-04-22 14:11, ToddAndMargo via users wrote:
On 2020-04-21 23:05, Ed Greshko wrote:
On 2020-04-22 14:00, ToddAndMargo via users wrote:
On 2020-04-21 22:55, Ed Greshko wrote:
rpm --rebuilddb
Hi Ed,
I happened after doing a # dnf upgrade and the upgrade froze for an hour on selinux policies
What did you do when it "froze"?
I did a ps and kill -9 on three dnf process
I did a reboot later trying to troubleshoot this. No joy.
Well, hard to say what kind of problems may be caused by killing dnf in the middle of what it may have been doing.
You first, could try
setenforce 0 dnf upgrade....
On 2020-04-21 23:21, Ed Greshko wrote:
On 2020-04-22 14:11, ToddAndMargo via users wrote:
On 2020-04-21 23:05, Ed Greshko wrote:
On 2020-04-22 14:00, ToddAndMargo via users wrote:
On 2020-04-21 22:55, Ed Greshko wrote:
rpm --rebuilddb
Hi Ed,
I happened after doing a # dnf upgrade and the upgrade froze for an hour on selinux policies
What did you do when it "froze"?
I did a ps and kill -9 on three dnf process
I did a reboot later trying to troubleshoot this. No joy.
Well, hard to say what kind of problems may be caused by killing dnf in the middle of what it may have been doing.
You first, could try
setenforce 0 dnf upgrade....
No change.
More info:
# dnf upgrade --refresh --disablerepo=* --enablerepo=fedora Fedora 30 - x86_64 17 kB/s | 16 kB 00:00 Bus error (core dumped)
# tail -f /var/log/messages Apr 21 23:25:30 server audit[2710]: ANOM_ABEND auid=1001 uid=0 gid=0 ses=4 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=2710 comm="dnf" exe="/usr/bin/python3.7" sig=7 res=1
Apr 21 23:25:30 server kernel: traps: dnf[2710] trap stack segment ip:7fe2296e78ed sp:7ffd432ffd20 error:0 in libdnf.so.2[7fe229652000+103000]
Apr 21 23:25:30 server systemd-coredump[2712]: Failed to connect to coredump service: Connection refused Apr 21 23:25:30 server abrt-dump-journal-core[1109]: Failed to obtain all required information from journald
On 2020-04-22 01:10, Ed Greshko wrote:
On 2020-04-22 14:11, ToddAndMargo via users wrote:
# rpm -Va --nofiles --nodigest
return about 50 conflicts
Forgot to ask, what are the errors?
# rpm -Va --nofiles --nodigest Unsatisfied dependencies for kernel-headers-5.5.16-100.fc30.x86_64: kernel-headers < 5.5.16-100.fc30 is obsoleted by (installed) kernel-headers-5.5.16-100.fc30.x86_64 Unsatisfied dependencies for grub2-tools-1:2.02-88.fc30.x86_64: grub2-tools < 1:2.02-88.fc30 is obsoleted by (installed) grub2-tools-1:2.02-88.fc30.x86_64 grub2-tools < 1:2.02-88.fc30 is obsoleted by (installed) grub2-tools-extra-1:2.02-88.fc30.x86_64 grub2-tools < 1:2.02-88.fc30 is obsoleted by (installed) grub2-tools-minimal-1:2.02-88.fc30.x86_64 Unsatisfied dependencies for webkit2gtk3-plugin-process-gtk2-2.24.4-1.fc30.x86_64: webkit2gtk3-plugin-process-gtk2 < 2.28.0-6.fc30 is obsoleted by (installed) webkit2gtk3-2.28.0-6.fc30.x86_64 Unsatisfied dependencies for fedora-release-30-6.noarch: system-release conflicts with (installed) fedora-release-30-6.noarch system-release conflicts with (installed) fedora-release-30-5.noarch Unsatisfied dependencies for libsss_certmap-2.2.3-13.fc30.x86_64: sssd-common < 2.2.3-13.fc30 conflicts with (installed) libsss_certmap-2.2.3-13.fc30.x86_64 Unsatisfied dependencies for pcre2-syntax-10.34-9.fc30.noarch: pcre2-devel < 10.34-8 conflicts with (installed) pcre2-syntax-10.34-9.fc30.noarch Unsatisfied dependencies for pcre2-devel-10.33-14.fc30.x86_64: pcre2-devel < 10.34-8 conflicts with (installed) pcre2-syntax-10.34-9.fc30.noarch Unsatisfied dependencies for fedora-release-30-5.noarch: system-release conflicts with (installed) fedora-release-30-5.noarch system-release conflicts with (installed) fedora-release-30-6.noarch Unsatisfied dependencies for sssd-common-2.2.2-1.fc30.x86_64: sssd-common < 2.2.3-13.fc30 conflicts with (installed) libsss_autofs-2.2.3-13.fc30.x86_64 sssd-common < 2.2.3-13.fc30 conflicts with (installed) sssd-nfs-idmap-2.2.3-13.fc30.x86_64 sssd-common < 2.2.3-13.fc30 conflicts with (installed) libsss_sudo-2.2.3-13.fc30.x86_64 sssd-common < 2.2.3-13.fc30 conflicts with (installed) libsss_certmap-2.2.3-13.fc30.x86_64 Unsatisfied dependencies for libsss_autofs-2.2.3-13.fc30.x86_64: sssd-common < 2.2.3-13.fc30 conflicts with (installed) libsss_autofs-2.2.3-13.fc30.x86_64 Unsatisfied dependencies for libsss_sudo-2.2.3-13.fc30.x86_64: sssd-common < 2.2.3-13.fc30 conflicts with (installed) libsss_sudo-2.2.3-13.fc30.x86_64 Unsatisfied dependencies for kernel-headers-5.3.6-200.fc30.x86_64: kernel-headers < 5.5.16-100.fc30 is obsoleted by (installed) kernel-headers-5.5.16-100.fc30.x86_64 Unsatisfied dependencies for grub2-tools-extra-1:2.02-88.fc30.x86_64: grub2-tools < 1:2.02-88.fc30 is obsoleted by (installed) grub2-tools-extra-1:2.02-88.fc30.x86_64 Unsatisfied dependencies for sssd-common-2.2.3-13.fc30.x86_64: sssd-common < 2.2.3-13.fc30 conflicts with (installed) libsss_autofs-2.2.3-13.fc30.x86_64 sssd-common < 2.2.3-13.fc30 conflicts with (installed) sssd-nfs-idmap-2.2.3-13.fc30.x86_64 sssd-common < 2.2.3-13.fc30 conflicts with (installed) libsss_sudo-2.2.3-13.fc30.x86_64 sssd-common < 2.2.3-13.fc30 conflicts with (installed) libsss_certmap-2.2.3-13.fc30.x86_64 Unsatisfied dependencies for webkit2gtk3-2.28.0-6.fc30.x86_64: webkit2gtk3-plugin-process-gtk2 < 2.28.0-6.fc30 is obsoleted by (installed) webkit2gtk3-2.28.0-6.fc30.x86_64 Unsatisfied dependencies for grub2-tools-1:2.02-83.fc30.x86_64: grub2-tools < 1:2.02-88.fc30 is obsoleted by (installed) grub2-tools-extra-1:2.02-88.fc30.x86_64 grub2-tools < 1:2.02-88.fc30 is obsoleted by (installed) grub2-tools-minimal-1:2.02-88.fc30.x86_64 grub2-tools < 1:2.02-88.fc30 is obsoleted by (installed) grub2-tools-1:2.02-88.fc30.x86_64 Unsatisfied dependencies for sssd-nfs-idmap-2.2.3-13.fc30.x86_64: sssd-common < 2.2.3-13.fc30 conflicts with (installed) sssd-nfs-idmap-2.2.3-13.fc30.x86_64 Unsatisfied dependencies for grub2-tools-minimal-1:2.02-88.fc30.x86_64: grub2-tools < 1:2.02-88.fc30 is obsoleted by (installed) grub2-tools-minimal-1:2.02-88.fc30.x86_64
On 4/21/20 11:11 PM, ToddAndMargo via users wrote:
On 2020-04-21 23:05, Ed Greshko wrote:
On 2020-04-22 14:00, ToddAndMargo via users wrote:
On 2020-04-21 22:55, Ed Greshko wrote:
rpm --rebuilddb
Hi Ed,
I happened after doing a # dnf upgrade and the upgrade froze for an hour on selinux policies
What did you do when it "froze"?
I did a ps and kill -9 on three dnf process
So you likely have some sort of library conflict or corruption. One thing you can try is booting a live image, mount the installed filesystem, and run "dnf --installroot=/path/to/root distro-sync".
I am picking an rpm at random, try this command: rpm -qa | grep libsss_sudo (and any other rpm with conflicts).
On Wed, Apr 22, 2020 at 1:11 PM Samuel Sieb samuel@sieb.net wrote:
On 4/21/20 11:11 PM, ToddAndMargo via users wrote:
On 2020-04-21 23:05, Ed Greshko wrote:
On 2020-04-22 14:00, ToddAndMargo via users wrote:
On 2020-04-21 22:55, Ed Greshko wrote:
rpm --rebuilddb
Hi Ed,
I happened after doing a # dnf upgrade and the upgrade froze for an hour on selinux policies
What did you do when it "froze"?
I did a ps and kill -9 on three dnf process
So you likely have some sort of library conflict or corruption. One thing you can try is booting a live image, mount the installed filesystem, and run "dnf --installroot=/path/to/root distro-sync". _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@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/users@lists.fedoraproject.org
On Tue, 21 Apr 2020 22:45:02 -0700 ToddAndMargo via users users@lists.fedoraproject.org wrote:
Hi All,
Fedora 30
How do I fix this?
# dnf upgrade --refresh --disablerepo=brave* Fedora Modular 30 - x86_64 2.9 kB/s | 16 kB 00:05 Fedora Modular 30 - x86_64 - Updates 32 kB/s | 14 kB 00:00 Fedora 30 - x86_64 - Updates 34 kB/s | 15 kB 00:00 Fedora 30 - x86_64 60 kB/s | 16 kB 00:00 Bus error (core dumped)
Three things to try.
1. From the error messages, there is something seriously wrong in the integrity of the dnf databases. Try dnf clean all Does the update run correctly now?
2. Run the command dnf module reset '*' before the update to reset modules in case they are causing the problem. Does the update run correctly now?
3. If that fails, go to https://koji.fedoraproject.org/koji/buildinfo?buildID=1487421 and https://koji.fedoraproject.org/koji/buildinfo?buildID=1487494 and download all the dnf and libdnf rpms that you have installed. Then, in the directory where they are, run dnf -C update dnf libdnf Once that completes, run the regular update again. If it doesn't complete, force the install of the packages using rpm. rpm -Uvh [package name(s)] See man rpm for complete details.
If the regular update still doesn't work, post further details.
On 2020-04-22 07:34, stan via users wrote:
On Tue, 21 Apr 2020 22:45:02 -0700 ToddAndMargo via users users@lists.fedoraproject.org wrote:
Hi All,
Fedora 30
How do I fix this?
# dnf upgrade --refresh --disablerepo=brave* Fedora Modular 30 - x86_64 2.9 kB/s | 16 kB 00:05 Fedora Modular 30 - x86_64 - Updates 32 kB/s | 14 kB 00:00 Fedora 30 - x86_64 - Updates 34 kB/s | 15 kB 00:00 Fedora 30 - x86_64 60 kB/s | 16 kB 00:00 Bus error (core dumped)
Three things to try.
- From the error messages, there is something seriously wrong in the
integrity of the dnf databases. Try dnf clean all Does the update run correctly now?
- Run the command
dnf module reset '*' before the update to reset modules in case they are causing the problem. Does the update run correctly now?
# dnf clean all 40 files removed
# dnf module reset '*' created by dnf config-manager from https://brav 14 kB/s | 8.5 kB 00:00 Fedora Modular 30 - x86_64 1.7 MB/s | 2.7 MB 00:01 Fedora Modular 30 - x86_64 - Updates 223 kB/s | 4.1 MB 00:18 Fedora 30 - x86_64 - Updates 2.4 MB/s | 24 MB 00:10 Fedora 30 - x86_64 3.6 MB/s | 70 MB 00:19 Bus error (core dumped)
badwordbadwordbadword (not an admission that I cuss)
- If that fails, go to
https://koji.fedoraproject.org/koji/buildinfo?buildID=1487421 and https://koji.fedoraproject.org/koji/buildinfo?buildID=1487494 and download all the dnf and libdnf rpms that you have installed. Then, in the directory where they are, run dnf -C update dnf libdnf Once that completes, run the regular update again. If it doesn't complete, force the install of the packages using rpm. rpm -Uvh [package name(s)] See man rpm for complete details.
If the regular update still doesn't work, post further details.
# cd Documents/rpms/dnf/
[root@server dnf]# ls dnf-4.2.21-1.fc31.noarch.rpm dnf-automatic-4.2.21-1.fc31.noarch.rpm dnf-data-4.2.21-1.fc31.noarch.rpm libdnf-0.47.0-1.fc31.x86_64.rpm libdnf-debuginfo-0.47.0-1.fc31.x86_64.rpm libdnf-debugsource-0.47.0-1.fc31.x86_64.rpm libdnf-devel-0.47.0-1.fc31.x86_64.rpm python3-dnf-4.2.21-1.fc31.noarch.rpm python3-hawkey-0.47.0-1.fc31.x86_64.rpm python3-hawkey-debuginfo-0.47.0-1.fc31.x86_64.rpm python3-libdnf-0.47.0-1.fc31.x86_64.rpm python3-libdnf-debuginfo-0.47.0-1.fc31.x86_64.rpm yum-4.2.21-1.fc31.noarch.rpm
[root@server dnf]# rpm -Uvf *.rpm error: Failed dependencies: python3-dnf-plugins-core < 4.0.12 conflicts with dnf-4.2.21-1.fc31.noarch librepo(x86-64) >= 1.11.3 is needed by libdnf-0.47.0-1.fc31.x86_64 librpm.so.9()(64bit) is needed by libdnf-0.47.0-1.fc31.x86_64 librpmio.so.9()(64bit) is needed by libdnf-0.47.0-1.fc31.x86_64 libsolv-devel(x86-64) >= 0.7.7 is needed by libdnf-devel-0.47.0-1.fc31.x86_64 pkgconfig(glib-2.0) is needed by libdnf-devel-0.47.0-1.fc31.x86_64 pkgconfig(librepo) is needed by libdnf-devel-0.47.0-1.fc31.x86_64 pkgconfig(libsolv) is needed by libdnf-devel-0.47.0-1.fc31.x86_64 pkgconfig(libsolvext) is needed by libdnf-devel-0.47.0-1.fc31.x86_64 pkgconfig(rpm) is needed by libdnf-devel-0.47.0-1.fc31.x86_64 pkgconfig(sqlite3) is needed by libdnf-devel-0.47.0-1.fc31.x86_64
What next, force remove the offenders and then do an "ivh"?
Thank you for the help!
-T
On 4/22/20 12:46 PM, ToddAndMargo via users wrote:
[root@server dnf]# ls dnf-4.2.21-1.fc31.noarch.rpm dnf-automatic-4.2.21-1.fc31.noarch.rpm dnf-data-4.2.21-1.fc31.noarch.rpm libdnf-0.47.0-1.fc31.x86_64.rpm libdnf-debuginfo-0.47.0-1.fc31.x86_64.rpm libdnf-debugsource-0.47.0-1.fc31.x86_64.rpm libdnf-devel-0.47.0-1.fc31.x86_64.rpm python3-dnf-4.2.21-1.fc31.noarch.rpm python3-hawkey-0.47.0-1.fc31.x86_64.rpm python3-hawkey-debuginfo-0.47.0-1.fc31.x86_64.rpm python3-libdnf-0.47.0-1.fc31.x86_64.rpm python3-libdnf-debuginfo-0.47.0-1.fc31.x86_64.rpm yum-4.2.21-1.fc31.noarch.rpm
[root@server dnf]# rpm -Uvf *.rpm error: Failed dependencies: python3-dnf-plugins-core < 4.0.12 conflicts with dnf-4.2.21-1.fc31.noarch librepo(x86-64) >= 1.11.3 is needed by libdnf-0.47.0-1.fc31.x86_64 librpm.so.9()(64bit) is needed by libdnf-0.47.0-1.fc31.x86_64 librpmio.so.9()(64bit) is needed by libdnf-0.47.0-1.fc31.x86_64 libsolv-devel(x86-64) >= 0.7.7 is needed by libdnf-devel-0.47.0-1.fc31.x86_64 pkgconfig(glib-2.0) is needed by libdnf-devel-0.47.0-1.fc31.x86_64 pkgconfig(librepo) is needed by libdnf-devel-0.47.0-1.fc31.x86_64 pkgconfig(libsolv) is needed by libdnf-devel-0.47.0-1.fc31.x86_64 pkgconfig(libsolvext) is needed by libdnf-devel-0.47.0-1.fc31.x86_64 pkgconfig(rpm) is needed by libdnf-devel-0.47.0-1.fc31.x86_64 pkgconfig(sqlite3) is needed by libdnf-devel-0.47.0-1.fc31.x86_64
What next, force remove the offenders and then do an "ivh"?
Some of those might go away when you have the right release, but otherwise you might need to download the other dependencies or dependent packages.
I am guessing when it hung and you ctrl-c'ed it that some packages were installed but the cleanup's were not done yet (all installs are done and then cleanups and other stuff). Some weird things happen when dnf gets aborted the wrong time.
This command would remove the dups (assuming you can get any of them to run). dnf remove --duplicates this would show them: dnf repoquery --duplicate and this will show other dependency issue: dnf repoquery --unsatisfied
On Wed, Apr 22, 2020 at 3:22 PM ToddAndMargo via users users@lists.fedoraproject.org wrote:
On 2020-04-22 12:59, Samuel Sieb wrote:
Some of those might go away when you have the right release, but otherwise you might need to download the other dependencies or dependent packages.
I made another post with the right release.
I think a few went away, but not many _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@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/users@lists.fedoraproject.org
On 2020-04-22 13:32, Roger Heflin wrote:
I am guessing when it hung and you ctrl-c'ed
It did nto responce to numerous Ctrl-C's. I had to ps and kill.
it that some packages were installed but the cleanup's were not done yet (all installs are done and then cleanups and other stuff). Some weird things happen when dnf gets aborted the wrong time.
This command would remove the dups (assuming you can get any of them to run). dnf remove --duplicates
# dnf remove --duplicates created by dnf config-manager from https://brav 14 kB/s | 3.3 kB 00:00 Fedora Modular 30 - x86_64 34 kB/s | 16 kB 00:00 Fedora Modular 30 - x86_64 - Updates 2.5 kB/s | 14 kB 00:05 Fedora 30 - x86_64 - Updates 31 kB/s | 15 kB 00:00 Fedora 30 - x86_64 37 kB/s | 17 kB 00:00 Bus error (core dumped)
this would show them: dnf repoquery --duplicate
you forgot the "s" at the end
It gave me a YUGE list, but no core dump
and this will show other dependency issue: dnf repoquery --unsatisfied
Another YUGE list. Her is the first part of it:
# dnf repoquery --unsatisfied Last metadata expiration check: 0:01:25 ago on Wed 22 Apr 2020 01:56:58 PM PDT.
Problem 1: cannot install both ImageMagick-libs-1:6.9.10.75-1.fc30.x86_64 and ImageMagick-libs-1:6.9.10.67-1.fc30.x86_64 - package ImageMagick-1:6.9.10.67-1.fc30.x86_64 requires ImageMagick-libs(x86-64) = 1:6.9.10.67-1.fc30, but none of the providers can be installed - problem with installed package ImageMagick-libs-1:6.9.10.75-1.fc30.x86_64 - problem with installed package ImageMagick-1:6.9.10.67-1.fc30.x86_64 Problem 2: package PackageKit-gtk3-module-1.1.12-5.fc30.x86_64 requires PackageKit-glib(x86-64) = 1.1.12-5.fc30, but none of the providers can be installed - cannot install both PackageKit-glib-1.1.12-5.fc30.x86_64 and PackageKit-glib-1.1.12-8.fc30.x86_64 - problem with installed package PackageKit-gtk3-module-1.1.12-5.fc30.x86_64 - problem with installed package PackageKit-glib-1.1.12-8.fc30.x86_64 Problem 3: cannot install both abrt-gui-libs-2.12.2-1.fc30.x86_64 and abrt-gui-libs-2.14.0-1.fc30.x86_64
Thank you for the help with this! -T
On 2020-04-22 07:34, stan via users wrote:
- If that fails, go to
https://koji.fedoraproject.org/koji/buildinfo?buildID=1487421 and https://koji.fedoraproject.org/koji/buildinfo?buildID=1487494
Just noticed these were for Fedora 31.
Do you have these for Fedora 30?
On 2020-04-22 12:47, ToddAndMargo via users wrote:
On 2020-04-22 07:34, stan via users wrote:
3. If that fails, go to https://koji.fedoraproject.org/koji/buildinfo?buildID=1487421 and https://koji.fedoraproject.org/koji/buildinfo?buildID=1487494
Just noticed these were for Fedora 31.
Do you have these for Fedora 30?
Found them:
Fedora 30: https://koji.fedoraproject.org/koji/buildinfo?buildID=1477118
https://koji.fedoraproject.org/koji/buildinfo?buildID=1429431
On 2020-04-22 07:34, stan via users wrote:
- If that fails, go to
https://koji.fedoraproject.org/koji/buildinfo?buildID=1487421 and https://koji.fedoraproject.org/koji/buildinfo?buildID=1487494 and download all the dnf and libdnf rpms that you have installed. Then, in the directory where they are, run dnf -C update dnf libdnf Once that completes, run the regular update again. If it doesn't complete, force the install of the packages using rpm. rpm -Uvh [package name(s)] See man rpm for complete details.
If the regular update still doesn't work, post further details.
Okay, this time with FC30 (not 31) rpms:
[root@server dnf]# ls dnf-4.2.18-1.fc30.noarch.rpm dnf-automatic-4.2.18-1.fc30.noarch.rpm dnf-data-4.2.18-1.fc30.noarch.rpm dnf-yum-4.2.18-1.fc30.noarch.rpm libdnf-0.43.1-5.fc30.x86_64.rpm libdnf-debuginfo-0.43.1-5.fc30.x86_64.rpm libdnf-debugsource-0.43.1-5.fc30.x86_64.rpm libdnf-devel-0.43.1-5.fc30.x86_64.rpm python3-dnf-4.2.18-1.fc30.noarch.rpm python3-hawkey-0.43.1-5.fc30.x86_64.rpm python3-hawkey-debuginfo-0.43.1-5.fc30.x86_64.rpm python3-libdnf-0.43.1-5.fc30.x86_64.rpm python3-libdnf-debuginfo-0.43.1-5.fc30.x86_64.rpm
[root@server dnf]# rpm -Uvf *.rpm error: Failed dependencies: python3-dnf-plugins-core < 4.0.12 conflicts with dnf-4.2.18-1.fc30.noarch libsolv-devel(x86-64) >= 0.7.7 is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(glib-2.0) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(librepo) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(libsolv) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(libsolvext) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(rpm) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(sqlite3) is needed by libdnf-devel-0.43.1-5.fc30.x86_64
What next, force remove the offenders and then do an "ivh"?
Thank you for the help!
-T
On Wed, 22 Apr 2020 12:58:06 -0700 ToddAndMargo via users users@lists.fedoraproject.org wrote:
[root@server dnf]# rpm -Uvf *.rpm error: Failed dependencies: python3-dnf-plugins-core < 4.0.12 conflicts with dnf-4.2.18-1.fc30.noarch libsolv-devel(x86-64) >= 0.7.7 is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(glib-2.0) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(librepo) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(libsolv) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(libsolvext) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(rpm) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(sqlite3) is needed by libdnf-devel-0.43.1-5.fc30.x86_64
What next, force remove the offenders and then do an "ivh"?
I don't think you need libdnf-devel, as that is for people who are working on dnf, not for people who are using it. So, just remove it.
dnf remove libdnf-devel
And the plugins conflict occurs because you don't have the dnf-plugins matching the other packages in your update.
https://koji.fedoraproject.org/koji/buildinfo?buildID=1429433
This time I got the f30 right. I just went on autopilot to the f31 packages even though I knew you needed f30.
On Wed, 22 Apr 2020 13:42:46 -0700 stan via users users@lists.fedoraproject.org wrote:
On Wed, 22 Apr 2020 12:58:06 -0700 ToddAndMargo via users users@lists.fedoraproject.org wrote:
[root@server dnf]# rpm -Uvf *.rpm error: Failed dependencies: python3-dnf-plugins-core < 4.0.12 conflicts with dnf-4.2.18-1.fc30.noarch libsolv-devel(x86-64) >= 0.7.7 is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(glib-2.0) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(librepo) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(libsolv) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(libsolvext) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(rpm) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(sqlite3) is needed by libdnf-devel-0.43.1-5.fc30.x86_64
What next, force remove the offenders and then do an "ivh"?
I don't think you need libdnf-devel, as that is for people who are working on dnf, not for people who are using it. So, just remove it.
dnf remove libdnf-devel
And the plugins conflict occurs because you don't have the dnf-plugins matching the other packages in your update.
https://koji.fedoraproject.org/koji/buildinfo?buildID=1429433
This time I got the f30 right. I just went on autopilot to the f31 packages even though I knew you needed f30.
PS If it doesn't work after these fixes, please post the output of rpm -qa | grep dnf That will show all the packages related to dnf that are installed, in case there is something else missing.
On 2020-04-22 13:51, stan via users wrote:
On Wed, 22 Apr 2020 13:42:46 -0700 stan via users users@lists.fedoraproject.org wrote:
On Wed, 22 Apr 2020 12:58:06 -0700 ToddAndMargo via users users@lists.fedoraproject.org wrote:
[root@server dnf]# rpm -Uvf *.rpm error: Failed dependencies: python3-dnf-plugins-core < 4.0.12 conflicts with dnf-4.2.18-1.fc30.noarch libsolv-devel(x86-64) >= 0.7.7 is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(glib-2.0) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(librepo) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(libsolv) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(libsolvext) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(rpm) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(sqlite3) is needed by libdnf-devel-0.43.1-5.fc30.x86_64
What next, force remove the offenders and then do an "ivh"?
I don't think you need libdnf-devel, as that is for people who are working on dnf, not for people who are using it. So, just remove it.
dnf remove libdnf-devel
And the plugins conflict occurs because you don't have the dnf-plugins matching the other packages in your update.
https://koji.fedoraproject.org/koji/buildinfo?buildID=1429433
This time I got the f30 right. I just went on autopilot to the f31 packages even though I knew you needed f30.
PS If it doesn't work after these fixes, please post the output of rpm -qa | grep dnf That will show all the packages related to dnf that are installed, in case there is something else missing.
# rpm -qa | grep dnf python3-dnf-4.2.11-2.fc30.noarch dnfdragora-updater-1.1.1-2.fc30.noarch dnf-data-4.2.11-2.fc30.noarch dnfdragora-1.1.1-2.fc30.noarch dnf-plugins-core-4.0.10-1.fc30.noarch python3-libdnf-0.35.5-2.fc30.x86_64 libdnf-0.35.5-2.fc30.x86_64 dnf-data-4.2.18-1.fc30.noarch dnf-yum-4.2.11-2.fc30.noarch python3-dnfdaemon-0.3.19-6.fc30.noarch dnf-4.2.11-2.fc30.noarch python3-dnf-plugins-core-4.0.10-1.fc30.noarch libdnf-0.43.1-5.fc30.x86_64 dnfdaemon-selinux-0.3.19-6.fc30.noarch dnfdaemon-0.3.19-6.fc30.noarch python3-dnf-plugins-extras-common-4.0.4-1.fc30.noarch python3-dnf-plugin-system-upgrade-4.0.4-1.fc30.noarch
On 2020-04-22 13:42, stan via users wrote:
On Wed, 22 Apr 2020 12:58:06 -0700 ToddAndMargo via users users@lists.fedoraproject.org wrote:
[root@server dnf]# rpm -Uvf *.rpm error: Failed dependencies: python3-dnf-plugins-core < 4.0.12 conflicts with dnf-4.2.18-1.fc30.noarch libsolv-devel(x86-64) >= 0.7.7 is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(glib-2.0) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(librepo) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(libsolv) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(libsolvext) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(rpm) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(sqlite3) is needed by libdnf-devel-0.43.1-5.fc30.x86_64
What next, force remove the offenders and then do an "ivh"?
I don't think you need libdnf-devel, as that is for people who are working on dnf, not for people who are using it. So, just remove it.
dnf remove libdnf-devel
And the plugins conflict occurs because you don't have the dnf-plugins matching the other packages in your update.
https://koji.fedoraproject.org/koji/buildinfo?buildID=1429433
This time I got the f30 right. I just went on autopilot to the f31 packages even though I knew you needed f30.
Well, fewer conflicts this time:
# ls dnf-4.2.18-1.fc30.noarch.rpm dnf-automatic-4.2.18-1.fc30.noarch.rpm dnf-data-4.2.18-1.fc30.noarch.rpm dnf-plugins-core-4.0.13-1.fc30.noarch.rpm dnf-utils-4.0.13-1.fc30.noarch.rpm dnf-yum-4.2.18-1.fc30.noarch.rpm libdnf-0.43.1-5.fc30.x86_64.rpm libdnf-debuginfo-0.43.1-5.fc30.x86_64.rpm libdnf-debugsource-0.43.1-5.fc30.x86_64.rpm libdnf-devel-0.43.1-5.fc30.x86_64.rpm python3-dnf-4.2.18-1.fc30.noarch.rpm python3-dnf-plugin-leaves-4.0.13-1.fc30.noarch.rpm python3-dnf-plugin-local-4.0.13-1.fc30.noarch.rpm python3-dnf-plugin-post-transaction-actions-4.0.13-1.fc30.noarch.rpm python3-dnf-plugins-core-4.0.13-1.fc30.noarch.rpm python3-dnf-plugin-show-leaves-4.0.13-1.fc30.noarch.rpm python3-dnf-plugin-versionlock-4.0.13-1.fc30.noarch.rpm python3-hawkey-0.43.1-5.fc30.x86_64.rpm python3-hawkey-debuginfo-0.43.1-5.fc30.x86_64.rpm python3-libdnf-0.43.1-5.fc30.x86_64.rpm python3-libdnf-debuginfo-0.43.1-5.fc30.x86_64.rpm
# rpm -Uvf *.rpm error: Failed dependencies: yum-utils < 1.1.31-530 conflicts with dnf-utils-4.0.13-1.fc30.noarch libsolv-devel(x86-64) >= 0.7.7 is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(glib-2.0) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(librepo) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(libsolv) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(libsolvext) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(rpm) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(sqlite3) is needed by libdnf-devel-0.43.1-5.fc30.x86_64
Did you see my earlier suggestion about using distro-sync from a live boot? If it worked, it would be a lot easier than trying to track down a consistent set of rpms which might not even be the right ones. I noticed pcre2 in the list of possible problems from your verification check. If you really want to do it via rpms, I would suggest starting with that one.
On 2020-04-22 14:18, Samuel Sieb wrote:
Did you see my earlier suggestion about using distro-sync from a live boot? If it worked, it would be a lot easier than trying to track down a consistent set of rpms which might not even be the right ones. I noticed pcre2 in the list of possible problems from your verification check. If you really want to do it via rpms, I would suggest starting with that one.
Sorry missed it or did not realize what it was. I can be thick as a board at times.
On 2020-04-22 14:22, ToddAndMargo via users wrote:
On 2020-04-22 14:18, Samuel Sieb wrote:
Did you see my earlier suggestion about using distro-sync from a live boot? If it worked, it would be a lot easier than trying to track down a consistent set of rpms which might not even be the right ones. I noticed pcre2 in the list of possible problems from your verification check. If you really want to do it via rpms, I would suggest starting with that one.
Sorry missed it or did not realize what it was. I can be thick as a board at times.
Oh I remember now. It core dumped
On 4/22/20 2:25 PM, ToddAndMargo via users wrote:
On 2020-04-22 14:22, ToddAndMargo via users wrote:
On 2020-04-22 14:18, Samuel Sieb wrote:
Did you see my earlier suggestion about using distro-sync from a live boot? If it worked, it would be a lot easier than trying to track down a consistent set of rpms which might not even be the right ones. I noticed pcre2 in the list of possible problems from your verification check. If you really want to do it via rpms, I would suggest starting with that one.
Sorry missed it or did not realize what it was. I can be thick as a board at times.
Oh I remember now. It core dumped
dnf on the live image core dumped? Or were you using "chroot"?
On 2020-04-22 14:28, Samuel Sieb wrote:
On 4/22/20 2:25 PM, ToddAndMargo via users wrote:
On 2020-04-22 14:22, ToddAndMargo via users wrote:
On 2020-04-22 14:18, Samuel Sieb wrote:
Did you see my earlier suggestion about using distro-sync from a live boot? If it worked, it would be a lot easier than trying to track down a consistent set of rpms which might not even be the right ones. I noticed pcre2 in the list of possible problems from your verification check. If you really want to do it via rpms, I would suggest starting with that one.
Sorry missed it or did not realize what it was. I can be thick as a board at times.
Oh I remember now. It core dumped
dnf on the live image core dumped? Or were you using "chroot"?
Oh no, sorry, I was thinking of something else. I am not at the server's location. I am logged in with both ssh and xrdp
On 2020-04-22 14:03, ToddAndMargo via users wrote:
On 2020-04-22 13:42, stan via users wrote:
On Wed, 22 Apr 2020 12:58:06 -0700 ToddAndMargo via users users@lists.fedoraproject.org wrote:
[root@server dnf]# rpm -Uvf *.rpm error: Failed dependencies: python3-dnf-plugins-core < 4.0.12 conflicts with dnf-4.2.18-1.fc30.noarch libsolv-devel(x86-64) >= 0.7.7 is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(glib-2.0) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(librepo) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(libsolv) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(libsolvext) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(rpm) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(sqlite3) is needed by libdnf-devel-0.43.1-5.fc30.x86_64
What next, force remove the offenders and then do an "ivh"?
I don't think you need libdnf-devel, as that is for people who are working on dnf, not for people who are using it. So, just remove it.
dnf remove libdnf-devel
And the plugins conflict occurs because you don't have the dnf-plugins matching the other packages in your update.
https://koji.fedoraproject.org/koji/buildinfo?buildID=1429433
This time I got the f30 right. I just went on autopilot to the f31 packages even though I knew you needed f30.
Well, fewer conflicts this time:
# ls dnf-4.2.18-1.fc30.noarch.rpm dnf-automatic-4.2.18-1.fc30.noarch.rpm dnf-data-4.2.18-1.fc30.noarch.rpm dnf-plugins-core-4.0.13-1.fc30.noarch.rpm dnf-utils-4.0.13-1.fc30.noarch.rpm dnf-yum-4.2.18-1.fc30.noarch.rpm libdnf-0.43.1-5.fc30.x86_64.rpm libdnf-debuginfo-0.43.1-5.fc30.x86_64.rpm libdnf-debugsource-0.43.1-5.fc30.x86_64.rpm libdnf-devel-0.43.1-5.fc30.x86_64.rpm python3-dnf-4.2.18-1.fc30.noarch.rpm python3-dnf-plugin-leaves-4.0.13-1.fc30.noarch.rpm python3-dnf-plugin-local-4.0.13-1.fc30.noarch.rpm python3-dnf-plugin-post-transaction-actions-4.0.13-1.fc30.noarch.rpm python3-dnf-plugins-core-4.0.13-1.fc30.noarch.rpm python3-dnf-plugin-show-leaves-4.0.13-1.fc30.noarch.rpm python3-dnf-plugin-versionlock-4.0.13-1.fc30.noarch.rpm python3-hawkey-0.43.1-5.fc30.x86_64.rpm python3-hawkey-debuginfo-0.43.1-5.fc30.x86_64.rpm python3-libdnf-0.43.1-5.fc30.x86_64.rpm python3-libdnf-debuginfo-0.43.1-5.fc30.x86_64.rpm
# rpm -Uvf *.rpm error: Failed dependencies: yum-utils < 1.1.31-530 conflicts with dnf-utils-4.0.13-1.fc30.noarch libsolv-devel(x86-64) >= 0.7.7 is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(glib-2.0) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(librepo) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(libsolv) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(libsolvext) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(rpm) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(sqlite3) is needed by libdnf-devel-0.43.1-5.fc30.x86_64
# gls devel libdnf-devel-0.43.1-5.fc30.x86_64.rpm
# mv libdnf-devel-0.43.1-5.fc30.x86_64.rpm libdnf-devel-0.43.1-5.fc30.x86_64.rpm.000
# rpm -Uvf *.rpm error: Failed dependencies: yum-utils < 1.1.31-530 conflicts with dnf-utils-4.0.13-1.fc30.noarch
# gls yum dnf-yum-4.2.18-1.fc30.noarch.rpm
# rpm -e yum-utils <successful return>
# rpm -Uvf *.rpm Verifying packages... Preparing packages... package libdnf-0.43.1-5.fc30.x86_64 is already installed package dnf-data-4.2.18-1.fc30.noarch is already installed
# mv libdnf-0.43.1-5.fc30.x86_64.rpm libdnf-0.43.1-5.fc30.x86_64.rpm.000
# mv dnf-data-4.2.18-1.fc30.noarch.rpm dnf-data-4.2.18-1.fc30.noarch.rpm.000
# rpm -Uvf *.rpm Verifying packages... Preparing packages... libdnf-debugsource-0.43.1-5.fc30.x86_64 libdnf-debuginfo-0.43.1-5.fc30.x86_64 python3-libdnf-0.43.1-5.fc30.x86_64 python3-hawkey-0.43.1-5.fc30.x86_64 python3-dnf-4.2.18-1.fc30.noarch python3-dnf-plugins-core-4.0.13-1.fc30.noarch dnf-4.2.18-1.fc30.noarch dnf-plugins-core-4.0.13-1.fc30.noarch python3-dnf-plugin-leaves-4.0.13-1.fc30.noarch python3-dnf-plugin-show-leaves-4.0.13-1.fc30.noarch dnf-utils-4.0.13-1.fc30.noarch dnf-automatic-4.2.18-1.fc30.noarch dnf-yum-4.2.18-1.fc30.noarch python3-dnf-plugin-local-4.0.13-1.fc30.noarch python3-dnf-plugin-post-transaction-actions-4.0.13-1.fc30.noarch python3-dnf-plugin-versionlock-4.0.13-1.fc30.noarch python3-hawkey-debuginfo-0.43.1-5.fc30.x86_64 python3-libdnf-debuginfo-0.43.1-5.fc30.x86_64 dnf-yum-4.2.11-2.fc30.noarch dnf-4.2.11-2.fc30.noarch dnf-plugins-core-4.0.10-1.fc30.noarch python3-dnf-plugins-core-4.0.10-1.fc30.noarch python3-dnf-4.2.11-2.fc30.noarch python3-hawkey-0.35.5-2.fc30.x86_64 python3-libdnf-0.35.5-2.fc30.x86_64
# dnf upgrade is doing its thing now. I will get back with the results.
:-)
On 2020-04-22 14:21, ToddAndMargo via users wrote:
On 2020-04-22 14:03, ToddAndMargo via users wrote:
On 2020-04-22 13:42, stan via users wrote:
On Wed, 22 Apr 2020 12:58:06 -0700 ToddAndMargo via users users@lists.fedoraproject.org wrote:
[root@server dnf]# rpm -Uvf *.rpm error: Failed dependencies: python3-dnf-plugins-core < 4.0.12 conflicts with dnf-4.2.18-1.fc30.noarch libsolv-devel(x86-64) >= 0.7.7 is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(glib-2.0) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(librepo) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(libsolv) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(libsolvext) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(rpm) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(sqlite3) is needed by libdnf-devel-0.43.1-5.fc30.x86_64
What next, force remove the offenders and then do an "ivh"?
I don't think you need libdnf-devel, as that is for people who are working on dnf, not for people who are using it. So, just remove it.
dnf remove libdnf-devel
And the plugins conflict occurs because you don't have the dnf-plugins matching the other packages in your update.
https://koji.fedoraproject.org/koji/buildinfo?buildID=1429433
This time I got the f30 right. I just went on autopilot to the f31 packages even though I knew you needed f30.
Well, fewer conflicts this time:
# ls dnf-4.2.18-1.fc30.noarch.rpm dnf-automatic-4.2.18-1.fc30.noarch.rpm dnf-data-4.2.18-1.fc30.noarch.rpm dnf-plugins-core-4.0.13-1.fc30.noarch.rpm dnf-utils-4.0.13-1.fc30.noarch.rpm dnf-yum-4.2.18-1.fc30.noarch.rpm libdnf-0.43.1-5.fc30.x86_64.rpm libdnf-debuginfo-0.43.1-5.fc30.x86_64.rpm libdnf-debugsource-0.43.1-5.fc30.x86_64.rpm libdnf-devel-0.43.1-5.fc30.x86_64.rpm python3-dnf-4.2.18-1.fc30.noarch.rpm python3-dnf-plugin-leaves-4.0.13-1.fc30.noarch.rpm python3-dnf-plugin-local-4.0.13-1.fc30.noarch.rpm python3-dnf-plugin-post-transaction-actions-4.0.13-1.fc30.noarch.rpm python3-dnf-plugins-core-4.0.13-1.fc30.noarch.rpm python3-dnf-plugin-show-leaves-4.0.13-1.fc30.noarch.rpm python3-dnf-plugin-versionlock-4.0.13-1.fc30.noarch.rpm python3-hawkey-0.43.1-5.fc30.x86_64.rpm python3-hawkey-debuginfo-0.43.1-5.fc30.x86_64.rpm python3-libdnf-0.43.1-5.fc30.x86_64.rpm python3-libdnf-debuginfo-0.43.1-5.fc30.x86_64.rpm
# rpm -Uvf *.rpm error: Failed dependencies: yum-utils < 1.1.31-530 conflicts with dnf-utils-4.0.13-1.fc30.noarch libsolv-devel(x86-64) >= 0.7.7 is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(glib-2.0) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(librepo) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(libsolv) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(libsolvext) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(rpm) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(sqlite3) is needed by libdnf-devel-0.43.1-5.fc30.x86_64
# gls devel libdnf-devel-0.43.1-5.fc30.x86_64.rpm
# mv libdnf-devel-0.43.1-5.fc30.x86_64.rpm libdnf-devel-0.43.1-5.fc30.x86_64.rpm.000
# rpm -Uvf *.rpm error: Failed dependencies: yum-utils < 1.1.31-530 conflicts with dnf-utils-4.0.13-1.fc30.noarch
# gls yum dnf-yum-4.2.18-1.fc30.noarch.rpm
# rpm -e yum-utils
<successful return>
# rpm -Uvf *.rpm Verifying packages... Preparing packages... package libdnf-0.43.1-5.fc30.x86_64 is already installed package dnf-data-4.2.18-1.fc30.noarch is already installed
# mv libdnf-0.43.1-5.fc30.x86_64.rpm libdnf-0.43.1-5.fc30.x86_64.rpm.000
# mv dnf-data-4.2.18-1.fc30.noarch.rpm dnf-data-4.2.18-1.fc30.noarch.rpm.000
# rpm -Uvf *.rpm Verifying packages... Preparing packages... libdnf-debugsource-0.43.1-5.fc30.x86_64 libdnf-debuginfo-0.43.1-5.fc30.x86_64 python3-libdnf-0.43.1-5.fc30.x86_64 python3-hawkey-0.43.1-5.fc30.x86_64 python3-dnf-4.2.18-1.fc30.noarch python3-dnf-plugins-core-4.0.13-1.fc30.noarch dnf-4.2.18-1.fc30.noarch dnf-plugins-core-4.0.13-1.fc30.noarch python3-dnf-plugin-leaves-4.0.13-1.fc30.noarch python3-dnf-plugin-show-leaves-4.0.13-1.fc30.noarch dnf-utils-4.0.13-1.fc30.noarch dnf-automatic-4.2.18-1.fc30.noarch dnf-yum-4.2.18-1.fc30.noarch python3-dnf-plugin-local-4.0.13-1.fc30.noarch python3-dnf-plugin-post-transaction-actions-4.0.13-1.fc30.noarch python3-dnf-plugin-versionlock-4.0.13-1.fc30.noarch python3-hawkey-debuginfo-0.43.1-5.fc30.x86_64 python3-libdnf-debuginfo-0.43.1-5.fc30.x86_64 dnf-yum-4.2.11-2.fc30.noarch dnf-4.2.11-2.fc30.noarch dnf-plugins-core-4.0.10-1.fc30.noarch python3-dnf-plugins-core-4.0.10-1.fc30.noarch python3-dnf-4.2.11-2.fc30.noarch python3-hawkey-0.35.5-2.fc30.x86_64 python3-libdnf-0.35.5-2.fc30.x86_64
# dnf upgrade is doing its thing now. I will get back with the results.
:-)
Burped on a bunch of duplicates.
I am running #dnf remove --duplicates right now. It has 523 to do
On 2020-04-22 14:24, ToddAndMargo via users wrote:
On 2020-04-22 14:21, ToddAndMargo via users wrote:
On 2020-04-22 14:03, ToddAndMargo via users wrote:
On 2020-04-22 13:42, stan via users wrote:
On Wed, 22 Apr 2020 12:58:06 -0700 ToddAndMargo via users users@lists.fedoraproject.org wrote:
[root@server dnf]# rpm -Uvf *.rpm error: Failed dependencies: python3-dnf-plugins-core < 4.0.12 conflicts with dnf-4.2.18-1.fc30.noarch libsolv-devel(x86-64) >= 0.7.7 is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(glib-2.0) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(librepo) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(libsolv) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(libsolvext) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(rpm) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(sqlite3) is needed by libdnf-devel-0.43.1-5.fc30.x86_64
What next, force remove the offenders and then do an "ivh"?
I don't think you need libdnf-devel, as that is for people who are working on dnf, not for people who are using it. So, just remove it.
dnf remove libdnf-devel
And the plugins conflict occurs because you don't have the dnf-plugins matching the other packages in your update.
https://koji.fedoraproject.org/koji/buildinfo?buildID=1429433
This time I got the f30 right. I just went on autopilot to the f31 packages even though I knew you needed f30.
Well, fewer conflicts this time:
# ls dnf-4.2.18-1.fc30.noarch.rpm dnf-automatic-4.2.18-1.fc30.noarch.rpm dnf-data-4.2.18-1.fc30.noarch.rpm dnf-plugins-core-4.0.13-1.fc30.noarch.rpm dnf-utils-4.0.13-1.fc30.noarch.rpm dnf-yum-4.2.18-1.fc30.noarch.rpm libdnf-0.43.1-5.fc30.x86_64.rpm libdnf-debuginfo-0.43.1-5.fc30.x86_64.rpm libdnf-debugsource-0.43.1-5.fc30.x86_64.rpm libdnf-devel-0.43.1-5.fc30.x86_64.rpm python3-dnf-4.2.18-1.fc30.noarch.rpm python3-dnf-plugin-leaves-4.0.13-1.fc30.noarch.rpm python3-dnf-plugin-local-4.0.13-1.fc30.noarch.rpm python3-dnf-plugin-post-transaction-actions-4.0.13-1.fc30.noarch.rpm python3-dnf-plugins-core-4.0.13-1.fc30.noarch.rpm python3-dnf-plugin-show-leaves-4.0.13-1.fc30.noarch.rpm python3-dnf-plugin-versionlock-4.0.13-1.fc30.noarch.rpm python3-hawkey-0.43.1-5.fc30.x86_64.rpm python3-hawkey-debuginfo-0.43.1-5.fc30.x86_64.rpm python3-libdnf-0.43.1-5.fc30.x86_64.rpm python3-libdnf-debuginfo-0.43.1-5.fc30.x86_64.rpm
# rpm -Uvf *.rpm error: Failed dependencies: yum-utils < 1.1.31-530 conflicts with dnf-utils-4.0.13-1.fc30.noarch libsolv-devel(x86-64) >= 0.7.7 is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(glib-2.0) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(librepo) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(libsolv) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(libsolvext) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(rpm) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(sqlite3) is needed by libdnf-devel-0.43.1-5.fc30.x86_64
# gls devel libdnf-devel-0.43.1-5.fc30.x86_64.rpm
# mv libdnf-devel-0.43.1-5.fc30.x86_64.rpm libdnf-devel-0.43.1-5.fc30.x86_64.rpm.000
# rpm -Uvf *.rpm error: Failed dependencies: yum-utils < 1.1.31-530 conflicts with dnf-utils-4.0.13-1.fc30.noarch
# gls yum dnf-yum-4.2.18-1.fc30.noarch.rpm
# rpm -e yum-utils
<successful return>
# rpm -Uvf *.rpm Verifying packages... Preparing packages... package libdnf-0.43.1-5.fc30.x86_64 is already installed package dnf-data-4.2.18-1.fc30.noarch is already installed
# mv libdnf-0.43.1-5.fc30.x86_64.rpm libdnf-0.43.1-5.fc30.x86_64.rpm.000
# mv dnf-data-4.2.18-1.fc30.noarch.rpm dnf-data-4.2.18-1.fc30.noarch.rpm.000
# rpm -Uvf *.rpm Verifying packages... Preparing packages... libdnf-debugsource-0.43.1-5.fc30.x86_64 libdnf-debuginfo-0.43.1-5.fc30.x86_64 python3-libdnf-0.43.1-5.fc30.x86_64 python3-hawkey-0.43.1-5.fc30.x86_64 python3-dnf-4.2.18-1.fc30.noarch python3-dnf-plugins-core-4.0.13-1.fc30.noarch dnf-4.2.18-1.fc30.noarch dnf-plugins-core-4.0.13-1.fc30.noarch python3-dnf-plugin-leaves-4.0.13-1.fc30.noarch python3-dnf-plugin-show-leaves-4.0.13-1.fc30.noarch dnf-utils-4.0.13-1.fc30.noarch dnf-automatic-4.2.18-1.fc30.noarch dnf-yum-4.2.18-1.fc30.noarch python3-dnf-plugin-local-4.0.13-1.fc30.noarch python3-dnf-plugin-post-transaction-actions-4.0.13-1.fc30.noarch python3-dnf-plugin-versionlock-4.0.13-1.fc30.noarch python3-hawkey-debuginfo-0.43.1-5.fc30.x86_64 python3-libdnf-debuginfo-0.43.1-5.fc30.x86_64 dnf-yum-4.2.11-2.fc30.noarch dnf-4.2.11-2.fc30.noarch dnf-plugins-core-4.0.10-1.fc30.noarch python3-dnf-plugins-core-4.0.10-1.fc30.noarch python3-dnf-4.2.11-2.fc30.noarch python3-hawkey-0.35.5-2.fc30.x86_64 python3-libdnf-0.35.5-2.fc30.x86_64
# dnf upgrade is doing its thing now. I will get back with the results.
:-)
Burped on a bunch of duplicates.
I am running #dnf remove --duplicates right now. It has 523 to do
And it is now reinstalling 1470 items. It will be a while. BUT NO CORE DUMPS!!!!
On 2020-04-22 14:26, ToddAndMargo via users wrote:
On 2020-04-22 14:24, ToddAndMargo via users wrote:
On 2020-04-22 14:21, ToddAndMargo via users wrote:
On 2020-04-22 14:03, ToddAndMargo via users wrote:
On 2020-04-22 13:42, stan via users wrote:
On Wed, 22 Apr 2020 12:58:06 -0700 ToddAndMargo via users users@lists.fedoraproject.org wrote:
[root@server dnf]# rpm -Uvf *.rpm error: Failed dependencies: python3-dnf-plugins-core < 4.0.12 conflicts with dnf-4.2.18-1.fc30.noarch libsolv-devel(x86-64) >= 0.7.7 is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(glib-2.0) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(librepo) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(libsolv) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(libsolvext) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(rpm) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(sqlite3) is needed by libdnf-devel-0.43.1-5.fc30.x86_64
What next, force remove the offenders and then do an "ivh"?
I don't think you need libdnf-devel, as that is for people who are working on dnf, not for people who are using it. So, just remove it.
dnf remove libdnf-devel
And the plugins conflict occurs because you don't have the dnf-plugins matching the other packages in your update.
https://koji.fedoraproject.org/koji/buildinfo?buildID=1429433
This time I got the f30 right. I just went on autopilot to the f31 packages even though I knew you needed f30.
Well, fewer conflicts this time:
# ls dnf-4.2.18-1.fc30.noarch.rpm dnf-automatic-4.2.18-1.fc30.noarch.rpm dnf-data-4.2.18-1.fc30.noarch.rpm dnf-plugins-core-4.0.13-1.fc30.noarch.rpm dnf-utils-4.0.13-1.fc30.noarch.rpm dnf-yum-4.2.18-1.fc30.noarch.rpm libdnf-0.43.1-5.fc30.x86_64.rpm libdnf-debuginfo-0.43.1-5.fc30.x86_64.rpm libdnf-debugsource-0.43.1-5.fc30.x86_64.rpm libdnf-devel-0.43.1-5.fc30.x86_64.rpm python3-dnf-4.2.18-1.fc30.noarch.rpm python3-dnf-plugin-leaves-4.0.13-1.fc30.noarch.rpm python3-dnf-plugin-local-4.0.13-1.fc30.noarch.rpm python3-dnf-plugin-post-transaction-actions-4.0.13-1.fc30.noarch.rpm python3-dnf-plugins-core-4.0.13-1.fc30.noarch.rpm python3-dnf-plugin-show-leaves-4.0.13-1.fc30.noarch.rpm python3-dnf-plugin-versionlock-4.0.13-1.fc30.noarch.rpm python3-hawkey-0.43.1-5.fc30.x86_64.rpm python3-hawkey-debuginfo-0.43.1-5.fc30.x86_64.rpm python3-libdnf-0.43.1-5.fc30.x86_64.rpm python3-libdnf-debuginfo-0.43.1-5.fc30.x86_64.rpm
# rpm -Uvf *.rpm error: Failed dependencies: yum-utils < 1.1.31-530 conflicts with dnf-utils-4.0.13-1.fc30.noarch libsolv-devel(x86-64) >= 0.7.7 is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(glib-2.0) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(librepo) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(libsolv) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(libsolvext) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(rpm) is needed by libdnf-devel-0.43.1-5.fc30.x86_64 pkgconfig(sqlite3) is needed by libdnf-devel-0.43.1-5.fc30.x86_64
# gls devel libdnf-devel-0.43.1-5.fc30.x86_64.rpm
# mv libdnf-devel-0.43.1-5.fc30.x86_64.rpm libdnf-devel-0.43.1-5.fc30.x86_64.rpm.000
# rpm -Uvf *.rpm error: Failed dependencies: yum-utils < 1.1.31-530 conflicts with dnf-utils-4.0.13-1.fc30.noarch
# gls yum dnf-yum-4.2.18-1.fc30.noarch.rpm
# rpm -e yum-utils
<successful return>
# rpm -Uvf *.rpm Verifying packages... Preparing packages... package libdnf-0.43.1-5.fc30.x86_64 is already installed package dnf-data-4.2.18-1.fc30.noarch is already installed
# mv libdnf-0.43.1-5.fc30.x86_64.rpm libdnf-0.43.1-5.fc30.x86_64.rpm.000
# mv dnf-data-4.2.18-1.fc30.noarch.rpm dnf-data-4.2.18-1.fc30.noarch.rpm.000
# rpm -Uvf *.rpm Verifying packages... Preparing packages... libdnf-debugsource-0.43.1-5.fc30.x86_64 libdnf-debuginfo-0.43.1-5.fc30.x86_64 python3-libdnf-0.43.1-5.fc30.x86_64 python3-hawkey-0.43.1-5.fc30.x86_64 python3-dnf-4.2.18-1.fc30.noarch python3-dnf-plugins-core-4.0.13-1.fc30.noarch dnf-4.2.18-1.fc30.noarch dnf-plugins-core-4.0.13-1.fc30.noarch python3-dnf-plugin-leaves-4.0.13-1.fc30.noarch python3-dnf-plugin-show-leaves-4.0.13-1.fc30.noarch dnf-utils-4.0.13-1.fc30.noarch dnf-automatic-4.2.18-1.fc30.noarch dnf-yum-4.2.18-1.fc30.noarch python3-dnf-plugin-local-4.0.13-1.fc30.noarch python3-dnf-plugin-post-transaction-actions-4.0.13-1.fc30.noarch python3-dnf-plugin-versionlock-4.0.13-1.fc30.noarch python3-hawkey-debuginfo-0.43.1-5.fc30.x86_64 python3-libdnf-debuginfo-0.43.1-5.fc30.x86_64 dnf-yum-4.2.11-2.fc30.noarch dnf-4.2.11-2.fc30.noarch dnf-plugins-core-4.0.10-1.fc30.noarch python3-dnf-plugins-core-4.0.10-1.fc30.noarch python3-dnf-4.2.11-2.fc30.noarch python3-hawkey-0.35.5-2.fc30.x86_64 python3-libdnf-0.35.5-2.fc30.x86_64
# dnf upgrade is doing its thing now. I will get back with the results.
:-)
Burped on a bunch of duplicates.
I am running #dnf remove --duplicates right now. It has 523 to do
And it is now reinstalling 1470 items. It will be a while. BUT NO CORE DUMPS!!!!
Jammed at the same point that started this all:
Upgrading : gimp-2:2.10.14-1.module_f30+6995+c35e2138.x86_ 434/1470
Running scriptlet: selinux-policy-targeted-3.14.3-57.fc30.noarch 435/1470
Reinstalling : selinux-policy-targeted-3.14.3-57.fc30.noarch 435/1470
Running scriptlet: selinux-policy-targeted-3.14.3-57.fc30.noarch 435/1470
I will let it run for an hour before panicking.
On 4/22/20 2:40 PM, ToddAndMargo via users wrote:
Jammed at the same point that started this all:
Upgrading : gimp-2:2.10.14-1.module_f30+6995+c35e2138.x86_ 434/1470
Running scriptlet: selinux-policy-targeted-3.14.3-57.fc30.noarch 435/1470
Reinstalling : selinux-policy-targeted-3.14.3-57.fc30.noarch 435/1470
Running scriptlet: selinux-policy-targeted-3.14.3-57.fc30.noarch 435/1470
I will let it run for an hour before panicking.
"ps -elf" will let you search by parent process. Try finding out what the script is doing that is getting stuck.
On 2020-04-22 14:43, Samuel Sieb wrote:
On 4/22/20 2:40 PM, ToddAndMargo via users wrote:
Jammed at the same point that started this all:
Upgrading : gimp-2:2.10.14-1.module_f30+6995+c35e2138.x86_ 434/1470
Running scriptlet: selinux-policy-targeted-3.14.3-57.fc30.noarch 435/1470
Reinstalling : selinux-policy-targeted-3.14.3-57.fc30.noarch 435/1470
Running scriptlet: selinux-policy-targeted-3.14.3-57.fc30.noarch 435/1470
I will let it run for an hour before panicking.
"ps -elf" will let you search by parent process. Try finding out what the script is doing that is getting stuck.
Still jammed
# ps -elf | grep -i [d]nf 4 S root 8553 5032 7 80 0 - 167759 - 14:22 pts/0 00:02:44 /usr/bin/python3 /usr/bin/dnf remove --duplicates
# ps -elf | grep -i [s]elinux <nothing>
Oh poop! I finally when past selinux. Oh please, oh please!
On 4/22/20 3:00 PM, ToddAndMargo via users wrote:
On 2020-04-22 14:43, Samuel Sieb wrote:
"ps -elf" will let you search by parent process. Try finding out what the script is doing that is getting stuck.
Still jammed
# ps -elf | grep -i [d]nf 4 S root 8553 5032 7 80 0 - 167759 - 14:22 pts/0 00:02:44 /usr/bin/python3 /usr/bin/dnf remove --duplicates
The next command after this would have been "ps -elf | grep 8553". "pstree -a" is also fun and could work. (Don't pipe it to anything for best results.)
On 2020-04-22 15:24, Samuel Sieb wrote:
On 4/22/20 3:00 PM, ToddAndMargo via users wrote:
On 2020-04-22 14:43, Samuel Sieb wrote:
"ps -elf" will let you search by parent process. Try finding out what the script is doing that is getting stuck.
Still jammed
# ps -elf | grep -i [d]nf 4 S root 8553 5032 7 80 0 - 167759 - 14:22 pts/0 00:02:44 /usr/bin/python3 /usr/bin/dnf remove --duplicates
The next command after this would have been "ps -elf | grep 8553". "pstree -a" is also fun and could work. (Don't pipe it to anything for best results.)
Hi Sam,
It FINALLY went past that point and completed. Yippee!!
And # dnf upgrade went perfectly
And it even installed, wait for it, wait for it, Brave Browser
Thank you all for the help!
-T
One question, it your os install on a spinning disk or on a ssd? depending on how much a given rpm is touching it could take a long time for some installs on spinning disks. I gave up and just about all of the machines I have have a 64gb ssd or larger just so the upgrades are nice and fast.
On Wed, Apr 22, 2020 at 6:12 PM ToddAndMargo via users users@lists.fedoraproject.org wrote:
On 2020-04-22 15:24, Samuel Sieb wrote:
On 4/22/20 3:00 PM, ToddAndMargo via users wrote:
On 2020-04-22 14:43, Samuel Sieb wrote:
"ps -elf" will let you search by parent process. Try finding out what the script is doing that is getting stuck.
Still jammed
# ps -elf | grep -i [d]nf 4 S root 8553 5032 7 80 0 - 167759 - 14:22 pts/0 00:02:44 /usr/bin/python3 /usr/bin/dnf remove --duplicates
The next command after this would have been "ps -elf | grep 8553". "pstree -a" is also fun and could work. (Don't pipe it to anything for best results.)
Hi Sam,
It FINALLY went past that point and completed. Yippee!!
And # dnf upgrade went perfectly
And it even installed, wait for it, wait for it, Brave Browser
Thank you all for the help!
-T _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@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/users@lists.fedoraproject.org
On 2020-04-22 16:24, Roger Heflin wrote:
One question, it your os install on a spinning disk or on a ssd? depending on how much a given rpm is touching it could take a long time for some installs on spinning disks. I gave up and just about all of the machines I have have a 64gb ssd or larger just so the upgrades are nice and fast.
Hi Roger,
Disclaimer, I now only sell Samsung SSD drives. Been burned too many times by cheaper ones. Had to give away too much free labor and free parts. Now all my customers are on Samsung and I no longer have that economic drain to worry about.
This particular server uses two 2GB mechanical drives in a RSTe (e for enterprise) RAID 1 configuration on an Intel C236 chipset
At the time I designed the server, larger SATA SSD's had not reached my desired reliability in RSTe RAID 1 (Samsung have great ones for that now) and NVMe were small and terribly expensive.
I have asked the customer to let me remove the mechanical drives as they are getting close to the end of their lifespan and replace then with a single Samsung NVMe. Samsung's NVMe drives are now super reliable and the server is no longer mission critical, but only "necessary". And they are assiduous about backing up (dump/restore script by me).
Has the server remained mission critical, I would have recommended Samsung's SATA SSD that are meant for RAID.
When I do installs from a USB3 flash drive, I am still tickled over the 10 minute installs. Then again, Fedora to be my all time favorite operating system.
-T
I have only bought Samsung or Crucial(micron) (prior to samsung really being serious about ssd's), for home. Work buys from a large enterprise vendor, who sources things from various ssd makers.
I have been putting a small unmirrored ssd in for OS and then whatever else for the other one if you need larger size and cheaper, but can tolerate slower, at home that is.
Some of the rpm installs were taking way too long on spinning disks for me to even like at home.
On Wed, Apr 22, 2020 at 6:57 PM ToddAndMargo via users users@lists.fedoraproject.org wrote:
On 2020-04-22 16:24, Roger Heflin wrote:
One question, it your os install on a spinning disk or on a ssd? depending on how much a given rpm is touching it could take a long time for some installs on spinning disks. I gave up and just about all of the machines I have have a 64gb ssd or larger just so the upgrades are nice and fast.
Hi Roger,
Disclaimer, I now only sell Samsung SSD drives. Been burned too many times by cheaper ones. Had to give away too much free labor and free parts. Now all my customers are on Samsung and I no longer have that economic drain to worry about.
This particular server uses two 2GB mechanical drives in a RSTe (e for enterprise) RAID 1 configuration on an Intel C236 chipset
At the time I designed the server, larger SATA SSD's had not reached my desired reliability in RSTe RAID 1 (Samsung have great ones for that now) and NVMe were small and terribly expensive.
I have asked the customer to let me remove the mechanical drives as they are getting close to the end of their lifespan and replace then with a single Samsung NVMe. Samsung's NVMe drives are now super reliable and the server is no longer mission critical, but only "necessary". And they are assiduous about backing up (dump/restore script by me).
Has the server remained mission critical, I would have recommended Samsung's SATA SSD that are meant for RAID.
When I do installs from a USB3 flash drive, I am still tickled over the 10 minute installs. Then again, Fedora to be my all time favorite operating system.
-T _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@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/users@lists.fedoraproject.org
On Wed, Apr 22, 2020 at 6:57 PM ToddAndMargo via users users@lists.fedoraproject.org wrote:
On 2020-04-22 16:24, Roger Heflin wrote:
One question, it your os install on a spinning disk or on a ssd? depending on how much a given rpm is touching it could take a long time for some installs on spinning disks. I gave up and just about all of the machines I have have a 64gb ssd or larger just so the upgrades are nice and fast.
Hi Roger,
Disclaimer, I now only sell Samsung SSD drives. Been burned too many times by cheaper ones. Had to give away too much free labor and free parts. Now all my customers are on Samsung and I no longer have that economic drain to worry about.
This particular server uses two 2GB mechanical drives in a RSTe (e for enterprise) RAID 1 configuration on an Intel C236 chipset
At the time I designed the server, larger SATA SSD's had not reached my desired reliability in RSTe RAID 1 (Samsung have great ones for that now) and NVMe were small and terribly expensive.
I have asked the customer to let me remove the mechanical drives as they are getting close to the end of their lifespan and replace then with a single Samsung NVMe. Samsung's NVMe drives are now super reliable and the server is no longer mission critical, but only "necessary". And they are assiduous about backing up (dump/restore script by me).
Has the server remained mission critical, I would have recommended Samsung's SATA SSD that are meant for RAID.
When I do installs from a USB3 flash drive, I am still tickled over the 10 minute installs. Then again, Fedora to be my all time favorite operating system.
-T
On 2020-04-22 17:49, Roger Heflin wrote:
I have only bought Samsung or Crucial(micron) (prior to samsung really being serious about ssd's), for home. Work buys from a large enterprise vendor, who sources things from various ssd makers.
You can really have quality issues doing that.
I have been putting a small unmirrored ssd in for OS and then whatever else for the other one if you need larger size and cheaper, but can tolerate slower, at home that is.
Some of the rpm installs were taking way too long on spinning disks for me to even like at home.
That works in theory, but I have only found one customer that it worked out for, As a rule I put everything on the same drive. Windows serves are especially a pain when they do a C: and a D: partition.
My customer and I have lost all interest in mechanical drives. I have not had a bad Samsung drive yet.
On Wed, 22 Apr 2020 16:11:56 -0700 ToddAndMargo via users users@lists.fedoraproject.org wrote:
It FINALLY went past that point and completed. Yippee!!
And # dnf upgrade went perfectly
And it even installed, wait for it, wait for it, Brave Browser
Thank you all for the help!
Great feeling when the issue is resolved successfully, isn't it? :-)
On 2020-04-22 17:11, stan via users wrote:
On Wed, 22 Apr 2020 16:11:56 -0700 ToddAndMargo via users users@lists.fedoraproject.org wrote:
It FINALLY went past that point and completed. Yippee!!
And # dnf upgrade went perfectly
And it even installed, wait for it, wait for it, Brave Browser
Thank you all for the help!
Great feeling when the issue is resolved successfully, isn't it? :-)
Especially since I thought I was going to have to wipe and reinstall !!!
You any good at shutdown problems?
On 2020-04-23 08:31, ToddAndMargo via users wrote:
You any good at shutdown problems?
Probably a good idea to start a new post on that subject if you're having issues.
On 2020-04-22 21:47, Ed Greshko wrote:
On 2020-04-23 08:31, ToddAndMargo via users wrote:
You any good at shutdown problems?
Probably a good idea to start a new post on that subject if you're having issues.
Just did: Slow down in operation and shutdown issue
-
Ed Greshko -
Roger Heflin -
Samuel Sieb -
stan -
ToddAndMargo