On Fri, Nov 10, 2017 at 11:41 PM, Chris Murphy lists@colorremedies.com wrote:
$ sudo dnf system-upgrade download --refresh --releasever=27
Error: Problem: package grub2-efi-modules-1:2.02-0.40.fc26.x86_64 requires grub2-tools = 1:2.02-0.40.fc26, but none of the providers can be installed
- grub2-tools-1:2.02-0.40.fc26.x86_64 does not belong to a
distupgrade repository
- problem with installed package grub2-efi-modules-1:2.02-0.40.fc26.x86_64
Looks like a bug with grub2 package:
The system with the problem has these packages: grub2-tools-2.02-0.40.fc26.x86_64 grub2-2.02-0.40.fc26.x86_64 grub2-efi-2.02-0.40.fc26.x86_64 grub2-efi-modules-2.02-0.40.fc26.x86_64
The system without the problem has these packages: grub2-efi-2.02-0.40.fc26.x86_64 grub2-tools-2.02-0.40.fc26.x86_64
But in order to get dnf system-upgrade to proceed, I had to remote both grub2 and grub2-efi-modules packages.
See also:
https://bugzilla.redhat.com/show_bug.cgi?id=1502312 https://bugzilla.redhat.com/show_bug.cgi?id=1491624 https://bugzilla.redhat.com/show_bug.cgi?id=1506704
On Sat, Nov 11, 2017 at 12:35 PM, Chris Murphy lists@colorremedies.com wrote:
But in order to get dnf system-upgrade to proceed, I had to remote both grub2 and grub2-efi-modules packages.
s/remote/remove
Chris Murphy composed on 2017-11-11 12:35 (UTC-0700):
Chris Murphy wrote:
$ sudo dnf system-upgrade download --refresh --releasever=27
Error: Problem: package grub2-efi-modules-1:2.02-0.40.fc26.x86_64 requires grub2-tools = 1:2.02-0.40.fc26, but none of the providers can be installed
- grub2-tools-1:2.02-0.40.fc26.x86_64 does not belong to a
distupgrade repository
- problem with installed package grub2-efi-modules-1:2.02-0.40.fc26.x86_64
Looks like a bug with grub2 package:
The system with the problem has these packages: grub2-tools-2.02-0.40.fc26.x86_64 grub2-2.02-0.40.fc26.x86_64 grub2-efi-2.02-0.40.fc26.x86_64 grub2-efi-modules-2.02-0.40.fc26.x86_64
The system without the problem has these packages: grub2-efi-2.02-0.40.fc26.x86_64 grub2-tools-2.02-0.40.fc26.x86_64
But in order to get dnf system-upgrade to proceed, I had to remove both grub2 and grub2-efi-modules packages.
Must be more than one problem with grub dependencies. Every one of my (BIOS/MBR-only) F26 to F27 upgrades added grub packages, without any complaints, even though no F26 grub* rpms were installed, needed or wanted. :-(
See also:
https://bugzilla.redhat.com/show_bug.cgi?id=1502312 https://bugzilla.redhat.com/show_bug.cgi?id=1491624 https://bugzilla.redhat.com/show_bug.cgi?id=1506704-
"Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
On Sat, Nov 11, 2017 at 12:59 PM, Felix Miata mrmazda@earthlink.net wrote:
Chris Murphy composed on 2017-11-11 12:35 (UTC-0700):
Chris Murphy wrote:
$ sudo dnf system-upgrade download --refresh --releasever=27
Error: Problem: package grub2-efi-modules-1:2.02-0.40.fc26.x86_64 requires grub2-tools = 1:2.02-0.40.fc26, but none of the providers can be installed
- grub2-tools-1:2.02-0.40.fc26.x86_64 does not belong to a
distupgrade repository
- problem with installed package grub2-efi-modules-1:2.02-0.40.fc26.x86_64
Looks like a bug with grub2 package:
The system with the problem has these packages: grub2-tools-2.02-0.40.fc26.x86_64 grub2-2.02-0.40.fc26.x86_64 grub2-efi-2.02-0.40.fc26.x86_64 grub2-efi-modules-2.02-0.40.fc26.x86_64
The system without the problem has these packages: grub2-efi-2.02-0.40.fc26.x86_64 grub2-tools-2.02-0.40.fc26.x86_64
But in order to get dnf system-upgrade to proceed, I had to remove both grub2 and grub2-efi-modules packages.
Must be more than one problem with grub dependencies. Every one of my (BIOS/MBR-only) F26 to F27 upgrades added grub packages, without any complaints, even though no F26 grub* rpms were installed, needed or wanted. :-(
That is expected because grub2 is one of the packages found in the Fedora Workstation group, and a system upgrade is does distrosync by default. One of the upgrade requirements for the various "products" in Fedora is that the upgraded system is the same as an installation of Fedora Workstation.
Chris Murphy composed on 2017-11-11 13:39 (UTC-0700):
Felix Miata wrote:
Must be more than one problem with grub dependencies. Every one of my (BIOS/MBR-only) F26 to F27 upgrades added grub packages, without any complaints, even though no F26 grub* rpms were installed, needed or wanted. :-(
That is expected because grub2 is one of the packages found in the Fedora Workstation group, and a system upgrade is does distrosync by default. One of the upgrade requirements for the various "products" in Fedora is that the upgraded system is the same as an installation of Fedora Workstation.
Sounds even more broken, as all I did in both is:
dnf upgrade --releasever=27
That was after attempted versionlocking, but apparently there's no way to lock out unwanted packages with dnf anything like there is in Debian or Mageia (unintuitive, manually edited configfile) and openSUSE (simple: zypper al <packagename>).
On Sat, Nov 11, 2017 at 2:08 PM, Felix Miata mrmazda@earthlink.net wrote:
Chris Murphy composed on 2017-11-11 13:39 (UTC-0700):
Felix Miata wrote:
Must be more than one problem with grub dependencies. Every one of my (BIOS/MBR-only) F26 to F27 upgrades added grub packages, without any complaints, even though no F26 grub* rpms were installed, needed or wanted. :-(
That is expected because grub2 is one of the packages found in the Fedora Workstation group, and a system upgrade is does distrosync by default. One of the upgrade requirements for the various "products" in Fedora is that the upgraded system is the same as an installation of Fedora Workstation.
Sounds even more broken, as all I did in both is:
dnf upgrade --releasever=27
I do not grok that command, for upgrades (F26 -> F27) you use something like this:
$ sudo dnf system-upgrade download --refresh --releasever 27
And by default this includes --distro-sync option per documentation: https://github.com/rpm-software-management/dnf-plugins-extras/blob/master/do...
That was after attempted versionlocking, but apparently there's no way to lock out unwanted packages with dnf anything like there is in Debian or Mageia (unintuitive, manually edited configfile) and openSUSE (simple: zypper al <packagename>).
I think what you want is to switch repos and then just distrosync to change (upgrade) the versions of packages that you have, rather than switching to a new version of the *product*. If you want Fedora Workstation upgraded via system-upgrade or Software Update, I'm pretty sure the design is you get everything you would have gotten had you clean installed that version *plus* any extras you've previously installed yourself.
Chris Murphy composed on 2017-11-11 14:17 (UTC-0700):
Felix Miata wrote:
dnf upgrade --releasever=27
I do not grok that command, for upgrades (F26 -> F27) you use something like this:
$ sudo dnf system-upgrade download --refresh --releasever 27
And by default this includes --distro-sync option per documentation: https://github.com/rpm-software-management/dnf-plugins-extras/blob/master/do...
That was after attempted versionlocking, but apparently there's no way to lock out unwanted packages with dnf anything like there is in Debian or Mageia (unintuitive, manually edited configfile) and openSUSE (simple: zypper al <packagename>).
I think what you want is to switch repos and then just distrosync to change (upgrade) the versions of packages that you have, rather than switching to a new version of the *product*. If you want Fedora Workstation upgraded via system-upgrade or Software Update, I'm pretty sure the design is you get everything you would have gotten had you clean installed that version *plus* any extras you've previously installed yourself.
It was late and I was tired. The above command I wrote was a considerable over-simplification of what I actually did, on a host last updated around 4 months ago. Here's the relevant .bash_history excerpt:
dnf remove kernel-core-4.11.0 dnf versionlock add mc dnf clean all df / man dnf dnf update --releasever=27 dnf* rpm* system* libsol* hawke* fedor* glibc* dnf update --releasever=27 --allowerasing kd* kf* q* plas* x* gl* y* z* dnf update --releasever=27 --allowerasing m* n* o* r* s* t* u* v* w* dnf update a* b* c* d* e* f* g* h* i* j* rpmqa grub dnf remove grubby dnf versionlock add grub2-common dnf update a* b* c* d* e* f* g* h* i* j* dnf versionlock add grub2-tools-minimal rpmqa prober dnf remove os-prober dnf update a* b* c* d* e* f* g* h* i* j* dnf versionlock add grubby dnf versionlock --help dnf update a* b* c* d* e* f* g* h* i* j* dnf update p* dnf update rpmqa grub* dnf remove grub2-common grub2-tools-minimal grubby os-prober
I've yet to *find* a simple way to upgrade Fedora that doesn't hit https://bugzilla.redhat.com/show_bug.cgi?id=1032541 (fill / with rpms and refuse to continue for lack of room).
That in conjunction with: https://bugzilla.redhat.com/show_bug.cgi?id=1420743 "@>96DPI Gecko browsers no longer utilize KDE's desktop font configuration since built with GTK3"
and https://www.linuxquestions.org/questions/linux-general-1/grub-legacy-delay-o... "Grub Legacy: delay of more than 2 minutes loading initrd from EXT4 filesystem" (latest F25, F26 and F27 kernels, and Tumbleweed's, on last night's testing host big41, suffer this)
and having been hit by Hurricanes Hermine and Irma and consequent lack of free time, has considerably reduced incentive and ability to contribute.
[1] rpmqa is a generic alias for 'rpm -qa | sort | grep '
On Sat, 2017-11-11 at 16:08 -0500, Felix Miata wrote:
Chris Murphy composed on 2017-11-11 13:39 (UTC-0700):
Felix Miata wrote:
Must be more than one problem with grub dependencies. Every one of my (BIOS/MBR-only) F26 to F27 upgrades added grub packages, without any complaints, even though no F26 grub* rpms were installed, needed or wanted. :-(
That is expected because grub2 is one of the packages found in the Fedora Workstation group, and a system upgrade is does distrosync by default. One of the upgrade requirements for the various "products" in Fedora is that the upgraded system is the same as an installation of Fedora Workstation.
Sounds even more broken, as all I did in both is:
dnf upgrade --releasever=27
That was after attempted versionlocking, but apparently there's no way to lock out unwanted packages with dnf anything like there is in Debian or Mageia (unintuitive, manually edited configfile) and openSUSE (simple: zypper al <packagename>).
lmgtfy:
https://unix.stackexchange.com/questions/403181/how-to-pin-a-package-in-dnf-...