From the file /var/log/dnf.log shows a python exception.  Maybe that could give a clue.


2023-10-13T18:52:16+0200 DEBUG --> Finished dependency resolution
2023-10-13T18:52:16+0200 DDEBUG timer: depsolve: 90 ms
2023-10-13T18:52:16+0200 SUBDEBUG
Traceback (most recent call last):
  File "/usr/lib/python3.11/site-packages/dnf/cli/main.py", line 130, in cli_run
    ret = resolving(cli, base)
          ^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/dnf/cli/main.py", line 166, in resolving
    base.resolve(cli.demands.allow_erasing)
  File "/usr/lib/python3.11/site-packages/dnf/base.py", line 929, in resolve
    raise exc
dnf.exceptions.DepsolveError:
 Problem: conflicting requests
  - package sdubby-1.0-4.fc40.noarch from fedora conflicts with grubby provided by grubby-8.40-72.fc40.x86_64 from updates
  - package sdubby-1.0-4.fc40.noarch from updates conflicts with grubby provided by grubby-8.40-72.fc40.x86_64 from updates
  - problem with installed package grubby-8.40-69.fc38.x86_64
  - package sdubby-1.0-4.fc40.noarch from fedora conflicts with grubby provided by grubby-8.40-72.fc40.x86_64 from fedora
  - package sdubby-1.0-4.fc40.noarch from updates conflicts with grubby provided by grubby-8.40-72.fc40.x86_64 from fedora
  - grubby-8.40-69.fc38.x86_64 from @System  does not belong to a distupgrade repository
2023-10-13T18:52:16+0200 CRITICAL Error:
 Problem: conflicting requests

Created attachment 1993779 [details]
dnf.log (sudo dnf system-upgrade download --releasever=rawhide)

I stashed `/var/log/dnf.log` and then ran `sudo dnf system-upgrade download --releasever=rawhide`

(In reply to Villy Kruse from comment #1)
> From the file /var/log/dnf.log shows a python exception.  Maybe that could
> give a clue.
> 
> 
> 2023-10-13T18:52:16+0200 DEBUG --> Finished dependency resolution
> 2023-10-13T18:52:16+0200 DDEBUG timer: depsolve: 90 ms
> 2023-10-13T18:52:16+0200 SUBDEBUG
> Traceback (most recent call last):
>   File "/usr/lib/python3.11/site-packages/dnf/cli/main.py", line 130, in
> cli_run
>     ret = resolving(cli, base)
>           ^^^^^^^^^^^^^^^^^^^^
>   File "/usr/lib/python3.11/site-packages/dnf/cli/main.py", line 166, in
> resolving
>     base.resolve(cli.demands.allow_erasing)
>   File "/usr/lib/python3.11/site-packages/dnf/base.py", line 929, in resolve
>     raise exc
> dnf.exceptions.DepsolveError:
>  Problem: conflicting requests
>   - package sdubby-1.0-4.fc40.noarch from fedora conflicts with grubby
> provided by grubby-8.40-72.fc40.x86_64 from updates
>   - package sdubby-1.0-4.fc40.noarch from updates conflicts with grubby
> provided by grubby-8.40-72.fc40.x86_64 from updates
>   - problem with installed package grubby-8.40-69.fc38.x86_64
>   - package sdubby-1.0-4.fc40.noarch from fedora conflicts with grubby
> provided by grubby-8.40-72.fc40.x86_64 from fedora
>   - package sdubby-1.0-4.fc40.noarch from updates conflicts with grubby
> provided by grubby-8.40-72.fc40.x86_64 from fedora
>   - grubby-8.40-69.fc38.x86_64 from @System  does not belong to a
> distupgrade repository
> 2023-10-13T18:52:16+0200 CRITICAL Error:
>  Problem: conflicting requests

Yes, I get the same thing in my dnf.log, just attached. I'm curious, since I haven't attached the file until now, did you get the log by running the command on your end?

> From the file /var/log/dnf.log shows a python exception.  Maybe that could give a clue.

The exception is dnf.exceptions.DepsolveError and it describes the dependency error that we see.

--

I can't reproduce this in an F38 podman container. I installed (in separate steps)
grubby, kexec-tools, and crypto-policies-scripts (kexec-tools and crypto-policies-scripts
Recommend sdubby in rawhide). All combinations seem to work fine. I guess I'm missing
something, but I don't know what.

# rpm -q dnf grubby kexec-tools crypto-policies-scripts
dnf-4.17.0-6.fc38.noarch
grubby-8.40-69.fc38.x86_64
kexec-tools-2.0.26-3.fc38.x86_64
crypto-policies-scripts-20230301-1.gita12f7b2.fc38.noarch

Oh, OK. Sdubby is part of @anaconda-tools group. After installing that, I get the error:
  - package sdubby-1.0-4.fc40.noarch from updates-modular conflicts with grubby provided by grubby-8.40-72.fc40.x86_64 from fedora

So I don't think this has anything to do with the requirement in systemd. The problem
is with listing of the package as mandatory in the group.

https://pagure.io/fedora-comps/pull-request/904 for discussion.

This is the confusion around the comment in the anaconda-tools group, which isn't AFAIK intended to be an installable group other than for the install images where anaconda is running.

Although, I also been confused why any of those items are marked mandatory, since the idea is to allow anaconda to pick which ones its going to add to the install. So in theory any number of them won't be actually installed depending on the system configuration. This hasn't been a problem until stubby showed up and its being used as a systemd-boot vs grub gate.

@Osama Albahrani, how was your machine installed? AKA was it a live/workstation, or did you install the anaconda-tools group yourself?

(In reply to Jeremy Linton from comment #8)
> @Osama Albahrani, how was your machine installed? AKA was it a
> live/workstation, or did you install the anaconda-tools group yourself?

XFCE live install, maybe 5 releases ago.

(In reply to Jeremy Linton from comment #8)
> @Osama Albahrani, how was your machine installed? AKA was it a
> live/workstation, or did you install the anaconda-tools group yourself?

It is Fedora Linux 38 (Workstation Edition) x86_64, using the iso downloaded by Fedora Media Writer.

No, I did not manually install anaconda-tools. And I don't think I have the group installed.
```console
[nebula@fedora ~]$ sudo dnf groupinstall anaconda-tools
Last metadata expiration check: 0:58:55 ago on Fri 13 Oct 2023 01:57:55 PM EDT.
Dependencies resolved.
============================================================================================================================================
 Package                                  Architecture            Version                                    Repository                Size
============================================================================================================================================
Installing group/module packages:
 device-mapper-multipath                  x86_64                  0.9.4-2.fc38                               fedora                   166 k
 fcoe-utils                               x86_64                  1.0.34-4.gitb233050.fc38                   updates                  125 k
 gfs2-utils                               x86_64                  3.4.1-6.fc38                               fedora                   320 k
Installing dependencies:
 libconfig                                x86_64                  1.7.3-5.fc38                               fedora                    71 k
 lldpad                                   x86_64                  1.1.0-7.git85e5583.fc38                    fedora                   286 k
Installing Groups:
 Anaconda tools                                                                                                                            

Transaction Summary
============================================================================================================================================
Install  5 Packages

Total download size: 967 k
Installed size: 2.3 M
Is this ok [y/N]: ^COperation aborted.
```

(In reply to Osama Albahrani from comment #10)
> (In reply to Jeremy Linton from comment #8)
> > @Osama Albahrani, how was your machine installed? AKA was it a
> > live/workstation, or did you install the anaconda-tools group yourself?
> 
> It is Fedora Linux 38 (Workstation Edition) x86_64, using the iso downloaded
> by Fedora Media Writer.
> 
> No, I did not manually install anaconda-tools. And I don't think I have the
> group installed.
> ```console
> [nebula@fedora ~]$ sudo dnf groupinstall anaconda-tools
> Last metadata expiration check: 0:58:55 ago on Fri 13 Oct 2023 01:57:55 PM
> EDT.
> Dependencies resolved.
> =============================================================================
> ===============================================================
>  Package                                  Architecture            Version   
> Repository                Size
> =============================================================================
> ===============================================================
> Installing group/module packages:
>  device-mapper-multipath                  x86_64                 
> 0.9.4-2.fc38                               fedora                   166 k
>  fcoe-utils                               x86_64                 
> 1.0.34-4.gitb233050.fc38                   updates                  125 k
>  gfs2-utils                               x86_64                 
> 3.4.1-6.fc38                               fedora                   320 k
> Installing dependencies:
>  libconfig                                x86_64                 
> 1.7.3-5.fc38                               fedora                    71 k
>  lldpad                                   x86_64                 
> 1.1.0-7.git85e5583.fc38                    fedora                   286 k
> Installing Groups:
>  Anaconda tools                                                             
> 
> 
> Transaction Summary
> =============================================================================
> ===============================================================
> Install  5 Packages
> 
> Total download size: 967 k
> Installed size: 2.3 M
> Is this ok [y/N]: ^COperation aborted.
> ```

Some more dump, if it might be helpful:
```console
[nebula@fedora ~]$ fastfetch
             .',;::::;,'.                 nebula@fedora
         .';:cccccccccccc:;,.             -------------
      .;cccccccccccccccccccccc;.          OS: Fedora Linux 38 (Workstation Edition) x86_64
    .:cccccccccccccccccccccccccc:.        Host: MacBookPro14,1 (1.0)
  .;ccccccccccccc;.:dddl:.;ccccccc;.      Kernel: 6.5.6-200.fc38.x86_64
 .:ccccccccccccc;OWMKOOXMWd;ccccccc:.     Uptime: 8 mins
.:ccccccccccccc;KMMc;cc;xMMc;ccccccc:.    Packages: 1883 (rpm), 2 (flatpak)
,cccccccccccccc;MMM.;cc;;WW:;cccccccc,    Shell: bash 5.2.15
:cccccccccccccc;MMM.;cccccccccccccccc:    Display: 2560x1600 @ 60Hz (as 1280x800)
:ccccccc;oxOOOo;MMM000k.;cccccccccccc:    DE: Gnome 44.5
cccccc;0MMKxdd:;MMMkddc.;cccccccccccc;    WM: Mutter (Wayland)
ccccc;XMO';cccc;MMM.;cccccccccccccccc'    WM Theme: Adwaita
ccccc;MMo;ccccc;MMW.;ccccccccccccccc;     Theme: Adwaita [GTK2/3/4]
ccccc;0MNc.ccc.xMMd;ccccccccccccccc;      Icons: Adwaita [GTK2/3/4]
cccccc;dNMWXXXWM0:;cccccccccccccc:,       Font: Cantarell (11pt) [GTK2/3/4]
cccccccc;.:odl:.;cccccccccccccc:,.        Cursor: Adwaita (24px)
ccccccccccccccccccccccccccccc:'.          Terminal: gnome-terminal 3.48.1
:ccccccccccccccccccccccc:;,..             Terminal Font: Source Code Pro (10pt)
 ':cccccccccccccccc::;,.                  CPU: Intel(R) Core(TM) i5-7360U (4) @ 3.6 GHz
                                          GPU: Intel Iris Plus Graphics 640
                                          Memory: 2.53 GiB / 7.61 GiB (33%)
                                          Disk (/): 10.29 GiB / 35.65 GiB (28%)
                                          Battery: 22% [Discharging]
                                          Locale: en_US.UTF-8

                                          ████████████████████████
                                          ████████████████████████
```

Right, that's what I was guessing. It is because the live images actually are installing rather than providing that group. Does `dnf system-upgrade download --releasever=rawhide --exclude=sdubby` work? 

Its a good thing that dnf is catching this, you don't really want sdubby installed on machines not configured for systemd-boot.

(In reply to Jeremy Linton from comment #12)
> Right, that's what I was guessing. It is because the live images actually
> are installing rather than providing that group. Does `dnf system-upgrade
> download --releasever=rawhide --exclude=sdubby` work? 
> 

I did try that and that removed the sdubby conflict.  I notice that both grubby and sdubby were mandatory, so I wonder what would have been included in the Live iso images,

(In reply to Jeremy Linton from comment #12)
> Right, that's what I was guessing. It is because the live images actually
> are installing rather than providing that group.

I don't know, I just tried to individually install the packages in that group and I don't think I have them installed.

```console
[nebula@fedora ~]$ sudo dnf install device-mapper-multipath
Last metadata expiration check: 0:05:59 ago on Fri 13 Oct 2023 03:15:07 PM EDT.
Dependencies resolved.
================================================================================
 Package                      Arch        Version             Repository   Size
================================================================================
Installing:
 device-mapper-multipath      x86_64      0.9.4-2.fc38        fedora      166 k

Transaction Summary
================================================================================
Install  1 Package

Total download size: 166 k
Installed size: 384 k
Is this ok [y/N]: n
Operation aborted.
[nebula@fedora ~]$ sudo dnf install fcoe-utils
Last metadata expiration check: 0:06:12 ago on Fri 13 Oct 2023 03:15:07 PM EDT.
Dependencies resolved.
================================================================================
 Package                   Arch     Version                     Repo       Size
================================================================================
Installing:
 fcoe-utils                x86_64   1.0.34-4.gitb233050.fc38    updates   125 k
Installing dependencies:
 device-mapper-multipath   x86_64   0.9.4-2.fc38                fedora    166 k
 libconfig                 x86_64   1.7.3-5.fc38                fedora     71 k
 lldpad                    x86_64   1.1.0-7.git85e5583.fc38     fedora    286 k

Transaction Summary
================================================================================
Install  4 Packages

Total download size: 647 k
Installed size: 1.5 M
Is this ok [y/N]: n
Operation aborted.
[nebula@fedora ~]$ sudo dnf install gfs2-utils
Last metadata expiration check: 0:06:23 ago on Fri 13 Oct 2023 03:15:07 PM EDT.
Dependencies resolved.
================================================================================
 Package            Architecture   Version                 Repository      Size
================================================================================
Installing:
 gfs2-utils         x86_64         3.4.1-6.fc38            fedora         320 k

Transaction Summary
================================================================================
Install  1 Package

Total download size: 320 k
Installed size: 812 k
Is this ok [y/N]: n
Operation aborted.
```

> Does `dnf system-upgrade
> download --releasever=rawhide --exclude=sdubby` work? 

It didn't, but it seems to fail for a different reason now. Is needing to add --exclude usual, or is this workaround?

```console
[nebula@fedora ~]$ sudo dnf system-upgrade download --releasever=rawhide --exclude=sdubby
Before you continue ensure that your system is fully upgraded by running "dnf --refresh upgrade". Do you want to continue [y/N]: y
Copr repo for PyCharm owned by phracek          4.4 kB/s | 2.1 kB     00:00    
Fedora rawhide - x86_64                          65 kB/s |  16 kB     00:00    
Fedora rawhide openh264 (From Cisco) - x86_64   8.9 kB/s | 989  B     00:00    
Fedora Modular rawhide - x86_64                 135 kB/s |  16 kB     00:00    
Fedora rawhide - x86_64 - Updates                41 kB/s |  16 kB     00:00    
Fedora Modular rawhide - x86_64 - Updates        41 kB/s |  16 kB     00:00    
google-chrome                                   7.5 kB/s | 1.3 kB     00:00    
RPM Fusion for Fedora rawhide - Free            401 kB/s | 639 kB     00:01    
RPM Fusion for Fedora rawhide - Free - Updates  698 kB/s | 639 kB     00:00    
RPM Fusion for Fedora rawhide - Nonfree         277 kB/s | 265 kB     00:00    
RPM Fusion for Fedora rawhide - Nonfree - NVIDI  18 kB/s | 6.3 kB     00:00    
RPM Fusion for Fedora rawhide - Nonfree - Steam  17 kB/s | 6.1 kB     00:00    
RPM Fusion for Fedora rawhide - Nonfree - Updat 333 kB/s | 265 kB     00:00    
Visual Studio Code                              4.9 MB/s | 3.7 MB     00:00    
No match for group package "gimp-heif-plugin"
No match for group package "sdubby"
No match for group package "gstreamer1-plugin-openh264"
No match for group package "python3-dnf-plugin-system-upgrade"
No match for group package "thai-scalable-purisa-fonts"
No match for group package "iwl4965-firmware"
No match for group package "thai-scalable-loma-fonts"
No match for group package "eosrei-emojione-fonts"
No match for group package "thai-scalable-waree-fonts"
No match for group package "thai-scalable-laksaman-fonts"
No match for group package "lohit-malayalam-fonts"
No match for group package "libertas-usb8388-firmware"
No match for group package "thai-scalable-garuda-fonts"
No match for group package "iwl6050-firmware"
No match for group package "iwl2000-firmware"
No match for group package "cdac-sakal-marathi-fonts"
No match for group package "thai-scalable-tlwgtypewriter-fonts"
No match for group package "thai-scalable-tlwgmono-fonts"
No match for group package "lohit-nepali-fonts"
No match for group package "iwl6000g2a-firmware"
No match for group package "samyak-tamil-fonts"
No match for group package "iwl3945-firmware"
No match for group package "nafees-tehreer-naskh-fonts"
No match for group package "nafees-pakistani-naskh-fonts"
No match for group package "nafees-web-naskh-fonts"
No match for group package "thai-scalable-kinnari-fonts"
No match for group package "baekmuk-ttf-gulim-fonts"
No match for group package "samyak-malayalam-fonts"
No match for group package "nafees-pakistani-web-naskh-fonts"
No match for group package "iwl135-firmware"
No match for group package "paktype-ajrak-fonts"
No match for group package "iwl5000-firmware"
No match for group package "baekmuk-ttf-hline-fonts"
No match for group package "thai-scalable-sawasdee-fonts"
No match for group package "iwlax2xx-firmware"
No match for group package "iwl105-firmware"
No match for group package "iwl6000-firmware"
No match for group package "iwl5150-firmware"
No match for group package "iwl2030-firmware"
No match for group package "thai-scalable-tlwgtypist-fonts"
No match for group package "thai-scalable-norasi-fonts"
No match for group package "kalapi-fonts"
No match for group package "fontawesome-fonts"
No match for group package "iwl3160-firmware"
No match for group package "thai-scalable-umpush-fonts"
No match for group package "nafees-naskh-fonts"
No match for group package "multican"
No match for group package "iwl6000g2b-firmware"
No match for group package "samyak-gujarati-fonts"
No match for group package "thai-scalable-tlwgtypo-fonts"
No match for group package "lohit-tamil-classical-fonts"
No match for group package "baekmuk-ttf-dotum-fonts"
No match for group package "samyak-odia-fonts"
No match for group package "iwl100-firmware"
No match for group package "nafees-riqa-fonts"
No match for group package "baekmuk-ttf-batang-fonts"
No match for group package "samyak-devanagari-fonts"
No match for group package "iwl1000-firmware"
No match for group package "nafees-nastaleeq-fonts"
No match for group package "iwl7260-firmware"
Error: 
 Problem 1: problem with installed package libavcodec-free-6.0-4.fc38.x86_64
  - conflicting requests
  - libavcodec-free-6.0-4.fc38.x86_64 from @System  does not belong to a distupgrade repository
  - nothing provides libopenh264.so.7()(64bit) needed by libavcodec-freeworld-6.0-18.fc40.x86_64 from rpmfusion-free
  - nothing provides libopenh264.so.7()(64bit) needed by libavcodec-freeworld-6.0-18.fc40.x86_64 from rpmfusion-free-updates
 Problem 2: conflicting requests
  - package ffmpeg-6.0-18.fc40.x86_64 from rpmfusion-free requires ffmpeg-libs(x86-64) = 6.0-18.fc40, but none of the providers can be installed
  - package ffmpeg-6.0-18.fc40.x86_64 from rpmfusion-free-updates requires ffmpeg-libs(x86-64) = 6.0-18.fc40, but none of the providers can be installed
  - nothing provides libopenh264.so.7()(64bit) needed by ffmpeg-libs-6.0-18.fc40.x86_64 from rpmfusion-free
  - nothing provides libopenh264.so.7()(64bit) needed by ffmpeg-libs-6.0-18.fc40.x86_64 from rpmfusion-free-updates
 Problem 3: problem with installed package firefox-118.0.2-1.fc38.x86_64
  - conflicting requests
  - ffmpeg-libs-6.0-18.fc40.i686 from rpmfusion-free-updates  does not belong to a distupgrade repository
  - ffmpeg-libs-6.0-18.fc40.i686 from rpmfusion-free  does not belong to a distupgrade repository
  - firefox-118.0.2-1.fc38.x86_64 from @System  does not belong to a distupgrade repository
  - nothing provides libopenh264.so.7()(64bit) needed by ffmpeg-libs-6.0-18.fc40.x86_64 from rpmfusion-free
  - nothing provides libopenh264.so.7()(64bit) needed by ffmpeg-libs-6.0-18.fc40.x86_64 from rpmfusion-free-updates
(try to add '--skip-broken' to skip uninstallable packages)
[nebula@fedora ~]$ sudo dnf system-upgrade download --releasever=rawhide --exclude=sdubby
Before you continue ensure that your system is fully upgraded by running "dnf --refresh upgrade". Do you want to continue [y/N]: y
Copr repo for PyCharm owned by phracek           12 kB/s | 2.1 kB     00:00    
Fedora rawhide - x86_64                          50 kB/s |  16 kB     00:00    
Fedora rawhide openh264 (From Cisco) - x86_64   9.8 kB/s | 989  B     00:00    
Fedora Modular rawhide - x86_64                 186 kB/s |  16 kB     00:00    
Fedora rawhide - x86_64 - Updates               240 kB/s |  16 kB     00:00    
Fedora Modular rawhide - x86_64 - Updates       116 kB/s |  16 kB     00:00    
google-chrome                                   8.7 kB/s | 1.3 kB     00:00    
RPM Fusion for Fedora rawhide - Free             10 kB/s | 4.1 kB     00:00    
RPM Fusion for Fedora rawhide - Free - Updates   11 kB/s | 4.1 kB     00:00    
RPM Fusion for Fedora rawhide - Nonfree          39 kB/s | 7.5 kB     00:00    
RPM Fusion for Fedora rawhide - Nonfree - NVIDI  49 kB/s | 6.3 kB     00:00    
RPM Fusion for Fedora rawhide - Nonfree - Steam  17 kB/s | 6.1 kB     00:00    
RPM Fusion for Fedora rawhide - Nonfree - Updat  58 kB/s | 7.5 kB     00:00    
Visual Studio Code                              7.7 kB/s | 1.5 kB     00:00    
No match for group package "sdubby"
No match for group package "gimp-heif-plugin"
No match for group package "python3-dnf-plugin-system-upgrade"
No match for group package "gstreamer1-plugin-openh264"
No match for group package "baekmuk-ttf-hline-fonts"
No match for group package "samyak-gujarati-fonts"
No match for group package "iwl105-firmware"
No match for group package "iwl7260-firmware"
No match for group package "nafees-tehreer-naskh-fonts"
No match for group package "iwl135-firmware"
No match for group package "lohit-tamil-classical-fonts"
No match for group package "kalapi-fonts"
No match for group package "thai-scalable-umpush-fonts"
No match for group package "nafees-nastaleeq-fonts"
No match for group package "iwl3160-firmware"
No match for group package "baekmuk-ttf-batang-fonts"
No match for group package "samyak-tamil-fonts"
No match for group package "fontawesome-fonts"
No match for group package "iwlax2xx-firmware"
No match for group package "iwl6000g2b-firmware"
No match for group package "lohit-malayalam-fonts"
No match for group package "libertas-usb8388-firmware"
No match for group package "baekmuk-ttf-gulim-fonts"
No match for group package "cdac-sakal-marathi-fonts"
No match for group package "thai-scalable-tlwgtypo-fonts"
No match for group package "nafees-riqa-fonts"
No match for group package "paktype-ajrak-fonts"
No match for group package "thai-scalable-tlwgmono-fonts"
No match for group package "thai-scalable-loma-fonts"
No match for group package "iwl100-firmware"
No match for group package "thai-scalable-sawasdee-fonts"
No match for group package "baekmuk-ttf-dotum-fonts"
No match for group package "iwl5000-firmware"
No match for group package "samyak-devanagari-fonts"
No match for group package "iwl3945-firmware"
No match for group package "nafees-pakistani-naskh-fonts"
No match for group package "multican"
No match for group package "iwl4965-firmware"
No match for group package "thai-scalable-kinnari-fonts"
No match for group package "nafees-pakistani-web-naskh-fonts"
No match for group package "nafees-naskh-fonts"
No match for group package "samyak-malayalam-fonts"
No match for group package "iwl6050-firmware"
No match for group package "thai-scalable-tlwgtypewriter-fonts"
No match for group package "iwl6000-firmware"
No match for group package "thai-scalable-purisa-fonts"
No match for group package "iwl5150-firmware"
No match for group package "lohit-nepali-fonts"
No match for group package "thai-scalable-garuda-fonts"
No match for group package "iwl2030-firmware"
No match for group package "thai-scalable-laksaman-fonts"
No match for group package "thai-scalable-norasi-fonts"
No match for group package "iwl1000-firmware"
No match for group package "nafees-web-naskh-fonts"
No match for group package "thai-scalable-tlwgtypist-fonts"
No match for group package "samyak-odia-fonts"
No match for group package "eosrei-emojione-fonts"
No match for group package "iwl2000-firmware"
No match for group package "thai-scalable-waree-fonts"
No match for group package "iwl6000g2a-firmware"
Error: 
 Problem 1: problem with installed package libavcodec-free-6.0-4.fc38.x86_64
  - conflicting requests
  - libavcodec-free-6.0-4.fc38.x86_64 from @System  does not belong to a distupgrade repository
  - nothing provides libopenh264.so.7()(64bit) needed by libavcodec-freeworld-6.0-18.fc40.x86_64 from rpmfusion-free
  - nothing provides libopenh264.so.7()(64bit) needed by libavcodec-freeworld-6.0-18.fc40.x86_64 from rpmfusion-free-updates
 Problem 2: conflicting requests
  - package ffmpeg-6.0-18.fc40.x86_64 from rpmfusion-free requires ffmpeg-libs(x86-64) = 6.0-18.fc40, but none of the providers can be installed
  - package ffmpeg-6.0-18.fc40.x86_64 from rpmfusion-free-updates requires ffmpeg-libs(x86-64) = 6.0-18.fc40, but none of the providers can be installed
  - nothing provides libopenh264.so.7()(64bit) needed by ffmpeg-libs-6.0-18.fc40.x86_64 from rpmfusion-free
  - nothing provides libopenh264.so.7()(64bit) needed by ffmpeg-libs-6.0-18.fc40.x86_64 from rpmfusion-free-updates
 Problem 3: problem with installed package firefox-118.0.2-1.fc38.x86_64
  - conflicting requests
  - ffmpeg-libs-6.0-18.fc40.i686 from rpmfusion-free-updates  does not belong to a distupgrade repository
  - ffmpeg-libs-6.0-18.fc40.i686 from rpmfusion-free  does not belong to a distupgrade repository
  - firefox-118.0.2-1.fc38.x86_64 from @System  does not belong to a distupgrade repository
  - nothing provides libopenh264.so.7()(64bit) needed by ffmpeg-libs-6.0-18.fc40.x86_64 from rpmfusion-free
  - nothing provides libopenh264.so.7()(64bit) needed by ffmpeg-libs-6.0-18.fc40.x86_64 from rpmfusion-free-updates
(try to add '--skip-broken' to skip uninstallable packages)
[nebula@fedora ~]$ sudo dnf system-upgrade download --releasever=rawhide --exclude=sdubby --skip-broken
Before you continue ensure that your system is fully upgraded by running "dnf --refresh upgrade". Do you want to continue [y/N]: y
Copr repo for PyCharm owned by phracek           29 kB/s | 2.1 kB     00:00    
Fedora rawhide - x86_64                         130 kB/s |  16 kB     00:00    
Fedora rawhide openh264 (From Cisco) - x86_64    12 kB/s | 989  B     00:00    
Fedora Modular rawhide - x86_64                 121 kB/s |  16 kB     00:00    
Fedora rawhide - x86_64 - Updates               243 kB/s |  16 kB     00:00    
Fedora Modular rawhide - x86_64 - Updates        72 kB/s |  16 kB     00:00    
google-chrome                                    10 kB/s | 1.3 kB     00:00    
RPM Fusion for Fedora rawhide - Free             11 kB/s | 4.1 kB     00:00    
RPM Fusion for Fedora rawhide - Free - Updates   31 kB/s | 4.1 kB     00:00    
RPM Fusion for Fedora rawhide - Nonfree          67 kB/s | 7.5 kB     00:00    
RPM Fusion for Fedora rawhide - Nonfree - NVIDI  18 kB/s | 6.3 kB     00:00    
RPM Fusion for Fedora rawhide - Nonfree - Steam  46 kB/s | 6.1 kB     00:00    
RPM Fusion for Fedora rawhide - Nonfree - Updat  55 kB/s | 7.5 kB     00:00    
Visual Studio Code                              8.9 kB/s | 1.5 kB     00:00    
No match for group package "sdubby"
No match for group package "gimp-heif-plugin"
No match for group package "python3-dnf-plugin-system-upgrade"
No match for group package "gstreamer1-plugin-openh264"
No match for group package "iwl1000-firmware"
No match for group package "nafees-pakistani-naskh-fonts"
No match for group package "cdac-sakal-marathi-fonts"
No match for group package "nafees-naskh-fonts"
No match for group package "libertas-usb8388-firmware"
No match for group package "nafees-web-naskh-fonts"
No match for group package "iwl4965-firmware"
No match for group package "thai-scalable-tlwgtypist-fonts"
No match for group package "fontawesome-fonts"
No match for group package "iwl7260-firmware"
No match for group package "thai-scalable-norasi-fonts"
No match for group package "thai-scalable-waree-fonts"
No match for group package "iwl3945-firmware"
No match for group package "lohit-tamil-classical-fonts"
No match for group package "thai-scalable-tlwgtypo-fonts"
No match for group package "baekmuk-ttf-batang-fonts"
No match for group package "iwl5000-firmware"
No match for group package "iwl105-firmware"
No match for group package "thai-scalable-garuda-fonts"
No match for group package "samyak-malayalam-fonts"
No match for group package "samyak-tamil-fonts"
No match for group package "iwl2000-firmware"
No match for group package "samyak-gujarati-fonts"
No match for group package "iwl100-firmware"
No match for group package "iwl3160-firmware"
No match for group package "kalapi-fonts"
No match for group package "baekmuk-ttf-gulim-fonts"
No match for group package "samyak-devanagari-fonts"
No match for group package "multican"
No match for group package "nafees-tehreer-naskh-fonts"
No match for group package "nafees-nastaleeq-fonts"
No match for group package "thai-scalable-sawasdee-fonts"
No match for group package "thai-scalable-kinnari-fonts"
No match for group package "iwl6000-firmware"
No match for group package "thai-scalable-purisa-fonts"
No match for group package "thai-scalable-umpush-fonts"
No match for group package "paktype-ajrak-fonts"
No match for group package "thai-scalable-tlwgtypewriter-fonts"
No match for group package "nafees-pakistani-web-naskh-fonts"
No match for group package "thai-scalable-loma-fonts"
No match for group package "iwlax2xx-firmware"
No match for group package "lohit-nepali-fonts"
No match for group package "iwl135-firmware"
No match for group package "eosrei-emojione-fonts"
No match for group package "baekmuk-ttf-dotum-fonts"
No match for group package "nafees-riqa-fonts"
No match for group package "iwl6050-firmware"
No match for group package "lohit-malayalam-fonts"
No match for group package "iwl6000g2b-firmware"
No match for group package "baekmuk-ttf-hline-fonts"
No match for group package "iwl5150-firmware"
No match for group package "iwl2030-firmware"
No match for group package "iwl6000g2a-firmware"
No match for group package "thai-scalable-tlwgmono-fonts"
No match for group package "thai-scalable-laksaman-fonts"
No match for group package "samyak-odia-fonts"
Error: 
 Problem 1: problem with installed package libavcodec-free-6.0-4.fc38.x86_64
  - conflicting requests
  - libavcodec-free-6.0-4.fc38.x86_64 from @System  does not belong to a distupgrade repository
  - nothing provides libopenh264.so.7()(64bit) needed by libavcodec-freeworld-6.0-18.fc40.x86_64 from rpmfusion-free
  - nothing provides libopenh264.so.7()(64bit) needed by libavcodec-freeworld-6.0-18.fc40.x86_64 from rpmfusion-free-updates
 Problem 2: conflicting requests
  - package ffmpeg-6.0-18.fc40.x86_64 from rpmfusion-free requires ffmpeg-libs(x86-64) = 6.0-18.fc40, but none of the providers can be installed
  - package ffmpeg-6.0-18.fc40.x86_64 from rpmfusion-free-updates requires ffmpeg-libs(x86-64) = 6.0-18.fc40, but none of the providers can be installed
  - nothing provides libopenh264.so.7()(64bit) needed by ffmpeg-libs-6.0-18.fc40.x86_64 from rpmfusion-free
  - nothing provides libopenh264.so.7()(64bit) needed by ffmpeg-libs-6.0-18.fc40.x86_64 from rpmfusion-free-updates
 Problem 3: problem with installed package firefox-118.0.2-1.fc38.x86_64
  - conflicting requests
  - ffmpeg-libs-6.0-18.fc40.i686 from rpmfusion-free-updates  does not belong to a distupgrade repository
  - ffmpeg-libs-6.0-18.fc40.i686 from rpmfusion-free  does not belong to a distupgrade repository
  - firefox-118.0.2-1.fc38.x86_64 from @System  does not belong to a distupgrade repository
  - nothing provides libopenh264.so.7()(64bit) needed by ffmpeg-libs-6.0-18.fc40.x86_64 from rpmfusion-free
  - nothing provides libopenh264.so.7()(64bit) needed by ffmpeg-libs-6.0-18.fc40.x86_64 from rpmfusion-free-updates
```

> Its a good thing that dnf is catching this, you don't really want sdubby
> installed on machines not configured for systemd-boot.

How/why did it attempt to install sdbubby, though?

(In reply to Osama Albahrani from comment #14)

> 
> I don't know, I just tried to individually install the packages in that
> group and I don't think I have them installed.
> 

anaconda-tools is a hidden group so try "dnf group list installed --hidden".  Checking the Workstation Live image, it does have the group installed, and whatever is installed on the live image you get when you move it to your hard disk.

Right, and the live image builder is explicitly excluding a number of the mandatory packages in the group. Its not ideal.

(In reply to Zbigniew Jędrzejewski-Szmek from comment #5)
> Oh, OK. Sdubby is part of @anaconda-tools group. After installing that, I
> get the error:
>   - package sdubby-1.0-4.fc40.noarch from updates-modular conflicts with
> grubby provided by grubby-8.40-72.fc40.x86_64 from fedora
> 
> So I don't think this has anything to do with the requirement in systemd.
> The problem
> is with listing of the package as mandatory in the group.
> 
> https://pagure.io/fedora-comps/pull-request/904 for discussion.

I was able to replicate this in a `fedora:rawhide` container:
```console
[root@5da96c5cfcc6 /]# dnf groupinstall anaconda-tools
Fedora rawhide openh264 (From Cisco) - x86_64   387  B/s | 257  B     00:00    
Fedora - Rawhide - Developmental packages for t 4.9 MB/s |  73 MB     00:14    
Error: 
 Problem: package sdubby-1.0-4.fc40.noarch from rawhide conflicts with grubby provided by grubby-8.40-72.fc40.x86_64 from rawhide
  - conflicting requests
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages)
```

This error does not happen in the other container images (37-49).

> This error does not happen in the other container images (37-49).

37-39*

Yes, you don't really want to install that group, there is a reason its hidden. The fact that its installed at all on the live image, is a bit sketchy IMHO if the purpose is to provide a pick list of possible installed system dependencies. I've got a somewhat functional systemd-workstation-live image I created a week or so back, and it should be suffering from the same issues, only in reverse as I excluded all the grub dependencies when creating it. 

So whatever is done for systemd-boot (aka make it type=optional in the group) should probably be done for the grub stuff as well, then assure that the install image picks up all the optional packages, while the live image has to explicitly pick the dependencies.

(In reply to Jeremy Linton from comment #12)
> Right, that's what I was guessing. It is because the live images actually
> are installing rather than providing that group. Does `dnf system-upgrade
> download --releasever=rawhide --exclude=sdubby` work? 
> 
> Its a good thing that dnf is catching this, you don't really want sdubby
> installed on machines not configured for systemd-boot.

Ok, I reinstalled Fedora 38, upgrade, reboot. Now `dnf system-upgrade download --releasever=rawhide --exclude=sdubby` passes the dependency resolution.

Thx everyone for the investigation and help!


Is the long-term solution making sure that `dnf groupinstal anaconda-tools` passes in Rawhide? I am assuming this is what https://pagure.io/fedora-comps/pull-request/904 is about.

I also had this issue trying to upgrade from 38 to Rawhide.

This did the trick for me and am on Rawhide now.
dnf system-upgrade download --releasever=rawhide --exclude=sdubby

FYI, the same issue (and fix) applies to 39 (beta) -> Rawhide. This is probably only relevant for when users would want to upgrade *from* 39 to the release after it, though, but I thought I'd dump it here for now.


nebula@fedora:~$ sudo dnf system-upgrade download --releasever rawhide
Before you continue ensure that your system is fully upgraded by running "dnf --refresh upgrade". Do you want to continue [y/N]: y
Copr repo for PyCharm owned by phracek         31 kB/s | 2.1 kB     00:00    
Fedora rawhide - x86_64                       104 kB/s |  18 kB     00:00    
Fedora rawhide openh264 (From Cisco) - x86_64  12 kB/s | 989  B     00:00    
Fedora rawhide - x86_64 - Updates              50 kB/s |  18 kB     00:00    
Fedora rawhide - x86_64 - Updates             838 kB/s | 1.7 MB     00:02    
google-chrome                                  14 kB/s | 1.3 kB     00:00    
RPM Fusion for Fedora rawhide - Nonfree - NVI  19 kB/s | 6.3 kB     00:00    
RPM Fusion for Fedora rawhide - Nonfree - Ste  53 kB/s | 6.1 kB     00:00    
No match for group package "python3-dnf-plugin-system-upgrade"
No match for group package "gstreamer1-plugin-openh264"
No match for group package "multican"
No match for group package "nafees-web-naskh-fonts"
No match for group package "eosrei-emojione-fonts"
No match for group package "baekmuk-ttf-batang-fonts"
No match for group package "nafees-pakistani-naskh-fonts"
No match for group package "paktype-ajrak-fonts"
No match for group package "cdac-sakal-marathi-fonts"
No match for group package "samyak-devanagari-fonts"
No match for group package "kalapi-fonts"
No match for group package "samyak-tamil-fonts"
No match for group package "baekmuk-ttf-gulim-fonts"
No match for group package "nafees-naskh-fonts"
No match for group package "samyak-malayalam-fonts"
No match for group package "baekmuk-ttf-dotum-fonts"
No match for group package "nafees-pakistani-web-naskh-fonts"
No match for group package "samyak-odia-fonts"
No match for group package "fontawesome-fonts"
No match for group package "lohit-nepali-fonts"
No match for group package "lohit-malayalam-fonts"
No match for group package "lohit-tamil-classical-fonts"
No match for group package "nafees-nastaleeq-fonts"
No match for group package "samyak-gujarati-fonts"
No match for group package "baekmuk-ttf-hline-fonts"
No match for group package "nafees-riqa-fonts"
No match for group package "nafees-tehreer-naskh-fonts"
Error: 
 Problem: problem with installed package grubby-8.40-72.fc39.x86_64
  - package sdubby-1.0-4.fc40.noarch from updates conflicts with grubby provided by grubby-8.40-72.fc40.x86_64 from fedora
  - package sdubby-1.0-4.fc40.noarch from updates conflicts with grubby provided by grubby-8.40-72.fc40.x86_64 from updates
  - conflicting requests
  - package sdubby-1.0-4.fc40.noarch from fedora conflicts with grubby provided by grubby-8.40-72.fc40.x86_64 from fedora
  - package sdubby-1.0-4.fc40.noarch from fedora conflicts with grubby provided by grubby-8.40-72.fc40.x86_64 from updates
  - grubby-8.40-72.fc39.x86_64 from @System  does not belong to a distupgrade repository
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages)
nebula@fedora:~1$ sudo dnf system-upgrade download --releasever rawhide --exclude=sdubby
Before you continue ensure that your system is fully upgraded by running "dnf --refresh upgrade". Do you want to continue [y/N]: y
Copr repo for PyCharm owned by phracek        3.6 kB/s | 2.1 kB     00:00    
Fedora rawhide - x86_64                        99 kB/s |  18 kB     00:00    
Fedora rawhide openh264 (From Cisco) - x86_64 3.5 kB/s | 989  B     00:00    
Fedora rawhide - x86_64 - Updates              53 kB/s |  18 kB     00:00    
google-chrome                                  13 kB/s | 1.3 kB     00:00    
RPM Fusion for Fedora rawhide - Nonfree - NVI  19 kB/s | 6.3 kB     00:00    
RPM Fusion for Fedora rawhide - Nonfree - Ste  52 kB/s | 6.1 kB     00:00    
No match for group package "sdubby"
No match for group package "gstreamer1-plugin-openh264"
No match for group package "python3-dnf-plugin-system-upgrade"
No match for group package "lohit-malayalam-fonts"
No match for group package "samyak-gujarati-fonts"
No match for group package "nafees-riqa-fonts"
No match for group package "samyak-malayalam-fonts"
No match for group package "nafees-naskh-fonts"
No match for group package "baekmuk-ttf-dotum-fonts"
No match for group package "eosrei-emojione-fonts"
No match for group package "nafees-web-naskh-fonts"
No match for group package "kalapi-fonts"
No match for group package "nafees-tehreer-naskh-fonts"
No match for group package "cdac-sakal-marathi-fonts"
No match for group package "baekmuk-ttf-hline-fonts"
No match for group package "paktype-ajrak-fonts"
No match for group package "samyak-devanagari-fonts"
No match for group package "baekmuk-ttf-batang-fonts"
No match for group package "lohit-nepali-fonts"
No match for group package "samyak-tamil-fonts"
No match for group package "nafees-nastaleeq-fonts"
No match for group package "nafees-pakistani-web-naskh-fonts"
No match for group package "fontawesome-fonts"
No match for group package "baekmuk-ttf-gulim-fonts"
No match for group package "samyak-odia-fonts"
No match for group package "lohit-tamil-classical-fonts"
No match for group package "nafees-pakistani-naskh-fonts"
No match for group package "multican"
Dependencies resolved.
...
nebula@fedora:~$ fastfetch
             .',;::::;,'.                 nebula@fedora
         .';:cccccccccccc:;,.             -------------
      .;cccccccccccccccccccccc;.          OS: Fedora Linux 39 (Workstation Edition) x86_64
    .:cccccccccccccccccccccccccc:.        Host: MacBookPro14,1 (1.0)
  .;ccccccccccccc;.:dddl:.;ccccccc;.      Kernel: 6.5.6-300.fc39.x86_64
 .:ccccccccccccc;OWMKOOXMWd;ccccccc:.     Uptime: 12 mins
.:ccccccccccccc;KMMc;cc;xMMc;ccccccc:.    Packages: 1954 (rpm)
,cccccccccccccc;MMM.;cc;;WW:;cccccccc,    Shell: bash 5.2.15
:cccccccccccccc;MMM.;cccccccccccccccc:    Display (Color LCD): 2560x1600 @ 60Hz (as 1280x800)
:ccccccc;oxOOOo;MMM000k.;cccccccccccc:    DE: Gnome 45.0
cccccc;0MMKxdd:;MMMkddc.;cccccccccccc;    WM: Mutter (Wayland)
ccccc;XMO';cccc;MMM.;cccccccccccccccc'    WM Theme: Adwaita
ccccc;MMo;ccccc;MMW.;ccccccccccccccc;     Theme: Adwaita [GTK2/3/4]
ccccc;0MNc.ccc.xMMd;ccccccccccccccc;      Icons: Adwaita [GTK2/3/4]
cccccc;dNMWXXXWM0:;cccccccccccccc:,       Font: Cantarell (11pt) [GTK2/3/4]
cccccccc;.:odl:.;cccccccccccccc:,.        Cursor: Adwaita (24px)
ccccccccccccccccccccccccccccc:'.          Terminal: gnome-terminal 3.48.1
:ccccccccccccccccccccccc:;,..             Terminal Font: Source Code Pro (10pt)
 ':cccccccccccccccc::;,.                  CPU: Intel(R) Core(TM) i5-7360U (4) @ 3.6 GHz
                                          GPU: Intel Iris Plus Graphics 640
                                          Memory: 3.01 GiB / 7.61 GiB (40%)
                                          Disk (/): 4.52 GiB / 35.65 GiB (13%) - btrfs
                                          Battery: 45% [Discharging]
                                          Locale: en_US.UTF-8

                                          ████████████████████████
                                          ████████████████████████

whew, well at least we only made this change in rawhide...:/

(In reply to Jeremy Linton from comment #19)
> Yes, you don't really want to install that group, there is a reason its
> hidden. The fact that its installed at all on the live image, is a bit
> sketchy IMHO if the purpose is to provide a pick list of possible installed
> system dependencies. I've got a somewhat functional systemd-workstation-live
> image I created a week or so back, and it should be suffering from the same
> issues, only in reverse as I excluded all the grub dependencies when
> creating it. 
> 

Considering that, it might be a good idea to mark the 'Anaconda tools' as uninstalled
either on the Live system itself, or on the target system immediately after copying
the live system to the target system.

For example run
   dnf group mark remove 'Anaconda tools'


> So whatever is done for systemd-boot (aka make it type=optional in the
> group) should probably be done for the grub stuff as well, then assure that
> the install image picks up all the optional packages, while the live image
> has to explicitly pick the dependencies.

The sdubby package without system-boot makes no sense, and system-boot seems not
to be included in any of the groups.

Another way to resolve the conflict is to use the "alternative" mechanism. Or teach
grubby about the bls files in the ESP file system.  It already handles bls files in 
the root file system.

systemd-boot is a sdubby dependency and will get pulled into anything analyzing the packages requirements, same as shared libraries/etc.

The problem isn't just grubby, its that a number of utilities try to make dynamic decisions about where boot related files are stored, which bootloader configs might need updating, etc. Plus there doesn't appear to be a desire to extend grubby further, particularly to support !grub bootloaders. IMHO (naturally :) the current situation isn't really problematic other than that some of these things should be tweaked/cleaned up a bit to clarify how they work for the next person doing something like this, and the fact that I didn't (may still not) not be able to fully see all the edge conditions. Plus, I think there are a number of cases in comps which are leftovers from other people slamming stuff in place like me, without fully understanding the implications.

AKA, the livemedia exclusions are being pulled in during upgrades despite the desire not to install them. Which is what this bug is all about.

The thing is, we have to live with the limitations of the live image approach we have. We don't live in Spherical Cow Land where we have a perfect live image system which doesn't come with any of these issues, we live in the real world where we have this one.

We can't "fix" the live image stuff at the drop of a hat, so changes introduced *after* we introduced live images (you know, 20 years ago or so?) have to accept that those limitations exist, and work within them.

(In reply to Jeremy Linton from comment #25)

> 
> AKA, the livemedia exclusions are being pulled in during upgrades despite
> the desire not to install them. Which is what this bug is all about.


What is meant by "livemedia exclusions"?

The thing is that dnf-offline-upgrade will upgrade all installed groups, including "Anaconda tools",
and if that group is installed on the Live media, it will also be installed on the user's system.

So should dnf-offline-upgrade be taught to not upgrade the "Anaconda tools" group?

We exclude sdubby from the live images via kickstarts:

https://pagure.io/fedora-kickstarts/blob/main/f/fedora-live-base.ks#_42

unfortunately, dnf doesn't know about that. This problem may well apply to other things from group packages that are excluded via kickstarts too, I guess.

btw, it may possibly help to list sdubby as 'default' rather than 'mandatory' in comps. I haven't tested, though.

2247911 was opened as a user found the issue occurs between 39 and Rawhide as well. Not sure if you want to merge these two.

Yup, just got this from 39 to rawhide too

This is clearly affecting many users, so raising the severity.

Also check bug 2250498.  It is similar, but different.

I guess i should link this PR: https://pagure.io/fedora-comps/pull-request/905 which has been there for a month or so too, without any review comments.

I don't think that PR is the right way to fix anything. Functionally I believe it's more or less identical to simply not listing sdubby in the group at all. I did suggest the idea of changing sdubby to 'default', rather than 'optional'.

One way we could deal with this would be to except anaconda-tools from this group update mechanism, if there's any good way to do that for dnf. It probably doesn't make sense in general for changes to that group to be reflected on installed systems at upgrade time.

But it still picks it up for the iso builds (or did when I was testing my hacky pungi-koji), but doesn't install it anywhere. Which is exactly what is needed. (well AFAIK)

The problem is that "default" doesn't fix anything, it is still installed by anything that installs the group, which isn't want we want.

*** Bug 2247911 has been marked as a duplicate of this bug. ***

the problem we're trying to solve is upgrades. I was wondering if, if the package is marked as default rather than mandatory, dnf would be more willing to just leave it out if it cannot be installed. I don't know whether it would be, but it seems possible.

Generally, optional packages are not pulled in by default when resolving groups, and I can't find anything in pungi indicating it would pull in optional packages from groups when creating the Server tree, which is what gets put on the DVD in the end, I think. It's difficult to be sure, though, as it's hard to spot the exact codepath we wind up following there, all the way through pungi-fedora and pungi. I don't know what you mean by 'your hacky pungi-koji' exactly to be sure if that was a valid test.

I also think you are still not understanding why we install anaconda-tools on live images. It is not a bug, as you claimed in your PR comment. It is intentional. It goes like this:

1. Things in anaconda-tools are there because, depending on choices made in the installer, they may need to be on the installed system.
2. We cannot actually change the ultimate installed package set for live images at all. Whatever is on the live image itself winds up on the installed system.
3. Therefore, we must include everything in anaconda-tools on the live images, in order to ensure that if anyone takes the path through the installer that requires any package from anaconda-tools to be on the installed system, it is actually there.

That is, given that a package's presence in anaconda-tools indicates it *might* need to be on the installed system depending on what the user does in the installer, and any user of the lives might take any possible path through the installer, the only safe thing to do is include everything from anaconda-tools, because they *might* hit the path that requires any single thing from it.

Excluding anything from that group on a live image has the consequence that, if a user chooses the relevant path through the installer, the required package will not actually be on the installed system, with whatever consequences come with that. For this case, it means that `inst.sdboot` doesn't do what you think it will on live images. For, e.g., device-mapper-multipath, it means if you try and do a multipath install from the live images, it probably won't work. We accept that problem on the basis that we're pretty sure nobody's doing live installs to multipath storage, but we did have to specifically evaluate that question before making the choice. See the original commit message:

"Since multipath is very much a data-center / server only feature we can simply exclude it from the livecd to get rid of the dependency on systemd-udev-settle.service ."

I think I understood that, the comment in the PR indicates that anaconda should be making the decisions about what is placed on those live images rather than being told to install all its possible requirements. Its aware of the difference, so it should be placing the dependencies for the final installed live on that image, not that it should be told to install a package group providing them. So, yes I consider it a "bug" that group is being installed, rather than provided because anaconda should be making the decision for the live media, and hence the need to "exclude" things because the live image is solidifying those requirements when the live images are created. So for non conflicting things that are selected later on the users machines, anaconda should be able to toss them both on the image even if they are redundant. In other words there should be another "anaconda-tools-live" subset that is installed on the live image via selection from the anaconda-tools group.

I understand that its a bit of legacy now, but it should never have been done that way, and going forward its going to be better to add things in anaconda where it can add it to the installed package list on the live media image rather than trying to wedge it into this package set. 

And this systemd-boot thing is the prime example, in theory it will require two different live media sets (not that i'm suggesting such a thing). A live images with grub, and a live images with systemd because the filesystem layout, loader entries and tools used to boot the machine vary in conflicting ways (aka you can't/shouldn't have the kernels in both a /boot directory and the /boot/EFI directory, assuming /boot remains for files that aren't critical for the kernel+initrd). And so while you could in theory wedge them together with redundant tooling by doing the usual install them both, the existing code is full of confused state about which one is actually active and different pieces make that determination in different ways rather than `bootctl is-installed` being authoritative.

And I should point out, i'm pretty sure I could have set the grub dependencies to optional in that PR as well, since anaconda is now correctly selecting them for grub targeted machines (which would be the live image as it stands). Which is the short version of my point above.

I don't see any way for anaconda to choose that which would look any better. The way this is implemented in anaconda is approximately:

if (going_down_path_that_requires_package_a):
    packages.append(package_a)

...all throughout anaconda's code. So how do we have anaconda do what you want it to do? Either we add some wacky routine which somehow finds all those paths and goes down them to construct the package list, or we'd just have to add a separate list of all the packages on all the paths. Which is...exactly what anaconda-tools is, except we keep it in comps, which is our canonical location for groups of packages. Moving that list to anaconda doesn't seem like it'd be a particularly huge win. Especially since I don't know if we could also use the same list in the context of creating the Server DVD.

Well its class based, but yes, the class that requires the package in order to configure it adds it to the install payload.

For example: grub vs systemd 

https://github.com/rhinstaller/anaconda/blob/2a192b3756bd23b72cdb65d2eecaec3726bc064e/pyanaconda/modules/storage/bootloader/efi.py#L150
vs
https://github.com/rhinstaller/anaconda/blob/2a192b3756bd23b72cdb65d2eecaec3726bc064e/pyanaconda/modules/storage/bootloader/efi.py#L208

or the mac packages

https://github.com/rhinstaller/anaconda/blob/2a192b3756bd23b72cdb65d2eecaec3726bc064e/pyanaconda/modules/storage/bootloader/efi.py#L285

Things which aren't actually being selected by anaconda in this manner should not be in that group, because the point of the group is to assure those packages are available. Things anaconda itself needs to run, are in the anaconda package dependency lists.

"Things which aren't actually being selected by anaconda in this manner should not be in that group, because the point of the group is to assure those packages are available."

I know that. I wrote the comment which explains it. All the things in the group except 'kdump-anaconda-addon' are things that ought to be in that group. I checked that a couple of months ago and sent https://pagure.io/fedora-comps/pull-request/898 to fix kdump-anaconda-addon.

For a lot of the package names (storage-related stuff) you won't find them in the anaconda source, but that's because they're referenced in the blivet source.

Yes, I thought you did, but i'm confused why you didn't view it as a bug, because it seems to me there are two different things happening here, and no way to differentiate them. 

1: Packages which are being selected by anaconda based on the target machine and need to be in the dvd repos

2: Packages which need to be on the live image payloads, but anaconda isn't selecting them from this list because it is unaware that it will need them to complete the live image install. With the knowledge that at least a portion of the packages from #1 above are actually being selected and installed on the live images already.


Which is why I was mumbling maybe the fix is to just create an "anaconda-live" group where the things falling into #2 are, and what I thought could be differentiated by "normal" (installed on live) vs "optional" (exists in the repo, selected by anaconda for live or DNf/repo payloads) in the existing group.

I'm confused as to why you think 2) comes into this bug at all. We don't use anaconda-tools for 2) (except in the case of kdump-anaconda-addon, which as I made clear with the links above, was an error by somebody which I'm correcting). anaconda-tools is specifically for 1). Everything in it except kdump-anaconda-addon falls into the category of 1).

How do you think 2) is actually relevant to anything here?

Oh, and your definition of 1) is still incomplete. it should read:

"1: Packages which may be selected by anaconda based on the target machine or configuration and so need to be in the dvd repos and on the live images"

Well, I think we are getting side tracked. 

Can you point me at the code which selects the comps groups for inclusion on the DVDs? I see the stuff in pungi-fedora which appears to take the package groups from variants-fedora.xml and includes "mandatory", "normal" and "optional" packages. But i'm not 100% sure that is the code building the package list for the DVD images since you mentioned you didn't think the install DVD's would pick up optional packages.


Because for sure sdubby can be marked optional in the anaconda-tools group, removed from the live image exclusions (or not, doesn't matter at that point), and it doesn't show up on the live media, nor is it pulled in during upgrades (well 99% sure given my testing) because the upgrade won't try and install optional packages.

So then all we need to do is assure that optional packages in that group get pulled into the DVD repos, right? 

That solves this immediate issue, because we can pull it in for the install DVD's, and it won't get installed to the live images, nor will it break updates. The tweak is just to assure that optional packages get pulled in, and since there haven't been any in that group in the past, it shouldn't create new problems. Right?

The tricky part would be whether you can specify optional package inclusion *per group*, I think. It's possible you can only set it to include optional packages from *all* groups, or optional packages from *no* groups.

Honestly, I can't point you at the code because I went looking and it's hard to pin down. There's a lot of bits in pungi, some of which aren't actually used in Fedora at all, so it gets confusing. I think what happens is that pungi builds the entire Server *tree* and then the DVD gets built out of that. But I couldn't pin it down precisely in the time I thought was worth spending on it.

So, I think there is a round about way to determine if optional things are included in the DVD's besides just looking at the resulting snipits, or trusting that my hacked up build enviroment works, and that is to look for packages marked optional in their groups which appear on the DVD.

And hdparm/etc which is part of the `server-hardware-support` group fits the bill here. Its on the DVD despite being marked "optional" in the package group in comps.

Well, you'd have to check it's also not getting pulled in as a dependency of something else. But assuming that's the case, yeah, I agree that indicates optional entries are being pulled in, and that could be in practice a useful way to cause something to be pulled into DVDs but left off lives.

I'm a bit worried still that it's essentially relying on unspecified behaviour for a not-entirely-obvious purpose, though. If anything I suspect we still pull optional group packages into the DVDs/trees because, waaaay back in the mists of time, there was a UI in the installer where you could pick them. That hasn't been the case for, sheesh, at least a decade, though, so it seems plausible someone might stumble across this behaviour, think it's an ancient remnant, and change it.

At minimum we'd want to extend the comment in comps to specify that we're relying on the precise current behaviour wrt optional packages, but that's not a great solution because a person who was going to change lives to include optional packages or DVDs to exclude them wouldn't have any particular reason to be looking at that particular comment...ideally we'd want a comment in the source they'd need to change, which would mean finding it. :D

Without checking, the package group drill down is still there, or was a few months back when I was hacking on anaconda. It only shows up on the full installers (ex the one on the server/everything image) though. And yes hdparm itself is sorta a bad example because its in (base?) too, but is marked optional there too. I think its liquidctl which only shows up in server-hardware-support, which is sorta funny because actual publicly available servers with liquid cooling are largely non-existent, while its fairly common on self built desktops and workstations.

you can pick (some) groups (it depends if they're listed as options for environment groups...) but you can't pick individual packages within them. Doing a graphical install there is no way to cause optional packages to be pulled in when selecting a group. You *can* do it with a kickstart, but I've no idea how common that is (most groups with optional packages are set up as 'shopping lists', you were never really intended to install *all* of them), and I don't think we ever explicitly promised that optional packages would be on the Server DVD to allow people to use kickstarts to pull them in if they wanted to.

sigh, I love cruft!

Oh, its liquidio-firmware which returns nothing when I `dnf repoquery --whatrequires` it (not liquidctl)

Your right its gone, I've must have lost my marbles, because I swore I used the package selector not long ago. Now it doesn't go any finer than per group. But I guess the fact its been a while and I didn't notice its missing proves that I at least didn't use it that much.

I think we are in agreement that my type="optional" PR fixes all currently known issues. Would it be more likely to be merged if I tweaked the comment to remove the bit about installing the group being a "bug"?

Well, personally I would say remove all the added text, except maybe the note that packages added to the group will be installed on any system initially installed from a live image when doing a distro upgrade, so people should be aware of that when adding things to the group. Instead I'd add a new note specifically noting the current effects of 'optional' items - that they will be pulled into DVD images, but not live images - that we intend and are relying on that behaviour, and when you might want to add an item as 'optional' versus 'mandatory' (when it's something that would cause problems if included on the live images, worse problems than are caused by leaving it out).

PR comment/commit message tweaked.

Reassign because is is less about the fact that sdubby conflicts with grubby and more about the fact that the distro/packaging has a problem with that fact.

I'm hitting same issue on Fresh Rawhide install

# dnf install grubby
Last metadata expiration check: 0:19:04 ago on Tue 19 Dec 2023 04:13:40 AM EST.
Error: 
 Problem: problem with installed package sdubby-1.0-5.fc40.noarch
  - package sdubby-1.0-5.fc40.noarch from @System conflicts with grubby provided by grubby-8.40-72.fc40.x86_64 from rawhide
  - package sdubby-1.0-5.fc40.noarch from rawhide conflicts with grubby provided by grubby-8.40-72.fc40.x86_64 from rawhide
  - conflicting requests
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages)

That's not really the same issue, though. You have sdubby actually installed. It's not blocking an upgrade.

How exactly did you install your system, that you wound up with sdubby and not grubby installed?

I just used the latest Fedora-Rawhide compose available in the internal beaker instance. Do you want me to open a new BZ for this?

Proposed as a Blocker for 40-beta by Fedora user jlinton using the blocker tracking app because:

 This will become a larger issue when people start trying to upgrade from F39 to F40 if its not merged/fixed.

AKA: This likely fails the basic criteria for "updating software", because the live images will require `--exclude sdubby`which likely won't happen for GUI based updaters.

sorry for leaving this one alone for a while. I decided to just go ahead and merge jlinton's "optional" PR, the reworded comments look okay. if that solves the problem, great. if not, we have a bit of time to figure out something else.

after the next compose is done and lands on the mirrors, this can be re-tested by again trying to upgrade an F39 workstation live install, ensuring the upgrade uses a mirror with the new comps data.

+4 in https://pagure.io/fedora-qa/blocker-review/issue/1451 , marking as accepted blocker. But as noted, this should actually be resolved already now; we just need to test.

This bug appears to have been reported against 'rawhide' during the Fedora Linux 40 development cycle.
Changing version to 40.

So, I did a clean install of F39 Workstation live, updated it fully, then upgraded to F40 with `dnf --releasever=40 --refresh system-upgrade download`. It did not install sdubby, and grubby was still installed.

I'm gonna say this is fixed. Please, if anyone still sees problems here, yell.

Thanks for working on it, Jeremy, and sorry I kinda held it up for a while.

(In reply to Adam Williamson from comment #71)
> So, I did a clean install of F39 Workstation live, updated it fully, then
> upgraded to F40 with `dnf --releasever=40 --refresh system-upgrade
> download`. It did not install sdubby, and grubby was still installed.
> 
> I'm gonna say this is fixed. Please, if anyone still sees problems here,
> yell.
> 
> Thanks for working on it, Jeremy, and sorry I kinda held it up for a while.

I thought with this bug resolved, grubby instead of sdubby will be installed by default. But it's not true for all cases. Currently a clean install of Fedora-Server-dvd-x86_64-40-20240314.n.0 will install sdubby but Fedora-Server-dvd-x86_64-39-1.5 has grubby installed. And I tried install Fedora 39, 40 and 41 on beaker machines, all cases have sdubby installed.

Ugh. That is definitely a problem. Thanks a lot for checking. I will look into that. Guess we need to fiddle with it more. :(

(In reply to Adam Williamson from comment #73)
> Ugh. That is definitely a problem. Thanks a lot for checking. I will look
> into that. Guess we need to fiddle with it more. :(

You are welcome! I've filed https://bugzilla.redhat.com/show_bug.cgi?id=2269992 to make it easier to track it.

Hello!

Confirmed same problem (sdubby automatically installed on BIOS only machine) - using latest Fedora-Server-netinst-x86_64-39-1.5.iso (today 2024-04-19), with layout GPT+BIOS, partitions: "BIOS boot", ext4 /boot,swap , LVM with xfs / - used foreign fdisk to prepare GPT partitions and then Blivet to allocate LVs and format them.

After install it was impossible (and confusing) because "apparent" grubby (actually sdubby) just reported error that EFI partition is not mounted. Only later found that it was actually symlink to sdubby.

Fixed with:

dnf install --allowerasing grubby

Oh, yeah, I think we can safely have sdubby not provide grubby on f39 too. I will send an update for that.