Bug 1793870

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

Ben,

I just tried to install FC32 x86_64 (Rawhide) and selected the eclipse package group as mentioned above. The problem STILL EXISTS. ALL the packages who fail for whatever reason SHOULD give the user the option to make changes to the package selection(s) AND try again to install. Python Science had a problem AND did this right. Eclipse STILL hasn't changed it's behavior AND ABANDONS the installation instead of allowing the user to remove that package group from the selected packages.

I'm wondering how many other package groups have this same problem.

Regards,

George...

Hi, I am not able to reproduce the issue. Please, attach all logs (including syslog) from the installation. You can find them during the installation in /tmp.

Vendula,

Thanks for responding.

I have worked around the problem by installing what I wanted AFTER the install, the problem is STILL aggravating. I haven't figured out just how to get the log files from the VM to the "real" world. Any ideas? How about "ctrl-f3;start sshd;scp from /tmp"?

I selected the KDE Plasma Workspaces which gave me another menu of additional packages to request. Initially I selected all of them but the install choked on the "Fedora Eclipse". I got a message about "there was a problem" but the popup only offered "Terminate the install". That's what I'm reporting.

Regards,

George...

Created attachment 1667575 [details]
gzip'd tar file of installer logs from /tmp

Vendula,

I just tried an install with the "latest" .iso for FC33...

This "current" problem has disappeared but left some others in it's wake.

There is a notification now that errors have occurred BUT, there is NO way to determine which selections caused the problems. What am I to do now? Guess and remove? I don't see anyway to remove specific packages from the "groups" I selected.

Other problems are:
1) when partitioning I used an existing system disk which appeared in the "Unknown Linux". You have to poke this link(?) EVERY time you want to refer to partitions in it. This IS NOT VERY Convenient.
2) my idea of starting sshd from a different tty worked great but I had to copy sshd_config.anaconda to sshd_config since "systemctl start sshd" wanted 'sshd_config'. I have sshd disabled on my host due to numerous attempts by hackers to gain access to my system. ARGH! A POX on them!

So, here is a tar file of the logs that I scp'd from the installer on the VM to my host system.

Thanks for your help with this.

George...

Vendula,

Is there any progress in the resolution of this bug report?

I would like to suggest that "--skip-broken" be added to the dnf commands invoked by the installation process. 

Regards,

George...

(In reply to George R. Goffe from comment #5)
> Created attachment 1667575 [details]
> gzip'd tar file of installer logs from /tmp
> 
> Vendula,
> 
> I just tried an install with the "latest" .iso for FC33...
> 
> This "current" problem has disappeared but left some others in it's wake.
> 
> There is a notification now that errors have occurred BUT, there is NO way
> to determine which selections caused the problems. What am I to do now?
> Guess and remove? I don't see anyway to remove specific packages from the
> "groups" I selected.

These suggestions would have to be provided by DNF, Anaconda just shows their output. Reassigning to DNF.

> Other problems are:
> 1) when partitioning I used an existing system disk which appeared in the
> "Unknown Linux". You have to poke this link(?) EVERY time you want to refer
> to partitions in it. This IS NOT VERY Convenient.

Please, report a new bug with this issue.

> 2) my idea of starting sshd from a different tty worked great but I had to
> copy sshd_config.anaconda to sshd_config since "systemctl start sshd" wanted
> 'sshd_config'. I have sshd disabled on my host due to numerous attempts by
> hackers to gain access to my system. ARGH! A POX on them!

You can run the installation with the boot option inst.sshd to start up sshd. See: https://anaconda-installer.readthedocs.io/en/latest/boot-options.html#inst-sshd

(In reply to George R. Goffe from comment #6)
> Vendula,
> 
> Is there any progress in the resolution of this bug report?
> 
> I would like to suggest that "--skip-broken" be added to the dnf commands
> invoked by the installation process. 
> 
> Regards,
> 
> George...

Anaconda supports that for kickstart installations. See the --ignorebroken option of the %packages section (https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#chapter-9-package-selection).

In packaging log there is everything what is required for debugging.

Example:
Problem 1: conflicting requests
  - nothing provides xmlrpc-client needed by eclipse-pydev-1:7.1.0-2.fc31.x86_64
  - nothing provides xmlrpc-common needed by eclipse-pydev-1:7.1.0-2.fc31.x86_64
  - nothing provides xmlrpc-server needed by eclipse-pydev-1:7.1.0-2.fc31.x86_64

When you search log for eclipse-pydev you can see that it is part of group 'eclipse' (11:14:59,641 DBG dnf: Adding packages from group 'eclipse':). 

I suggest that the issue is not in DNF, and also not in Anaconda, but in packaging (missing dependency). I will try to reassign the component to something more relevant.

Jaroslav,

Thank you for responding to this bug report, IT IS APPRECIATED!

Maybe there is already an answer to what I'm asking below. I would appreciate any pointers/hints/tips.

Can you help me to do more of this kind of research myself please? It would help "us" all if I could narrow down to a specific package causing trouble.

I am not a dnf/yum/rpm expert by ANY stretch of the imagination. What dnf commands should be issued by me? Perhaps a brief "flow chart"? Are there other commands? I know this is a big question but it would help me and maybe most of the other people writing bug reports. Occasionally I run across a package that is NOT in bugzilla. Who should I notify about that?

Something short and sweet would be GREATLY appreciated by me for sure. I WANT to write better bug reports.

What do you think?

Best regards and, again, thanks for your help.

George...

Thanks for referring this to the pydev package, there was indeed a broken dep on xmlrpc. Renaming the bug appropriately.

FEDORA-2020-1d0635bd71 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-1d0635bd71

FEDORA-2020-1d0635bd71 has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-1d0635bd71`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-1d0635bd71

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2020-1d0635bd71 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.