Description of problem: snippet from /root/drakx/install.log starting installing packages created transaction for installing on /mnt (remove=0, install=0, upgrade=8) libkdegames4-14.12.3-3.mga6.x86_64 lib64kdegames6-14.12.3-3.mga6.x86_64 openssh-askpass-common-7.2p2-3.mga6.x86_64 failed to read link /usr/lib64/ssh/ssh-askpass: No such file or directory the primary link for ssh-askpass must be /usr/lib64/ssh/ssh-askpass openssh-askpass-qt4-1.0.1-12.mga6.x86_64 lib64kdegamesprivate1-14.12.3-3.mga6.x86_64 Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. network install 2. grep -i failure /root/drakx/install.log 3.
Oops, that should be grep -i fail /root/drakx/install.log
This might have been fixed since your network install (your log shows openssh-askpass-common-7.2p2-3.mga6 but we now have openssh-askpass-common-7.3p1-1.mga6), though I don't see strong evidence of the alternative being handled differently in recent changes. There are no longer references to /usr/lib64/ssh/ssh-askpass in the spec file though: http://svnweb.mageia.org/packages/cauldron/openssh/current/SPECS/openssh.spec?view=markup Could you provide the whole install.log? It could be that you got ksshaskpass installed previously which still had wrong alternatives (I fixed it yesterday) - though I'd expect openssh-askpass-common to be installed first, and thus to setup the proper alternatives path. @Guillaume: I'd expect such issues to pop up on upgrades though, maybe openssh-askpass-common should have some logic to remove the wrong alternative before adding the new one (I fixed it for my system manually yesterday, it was actually a pain to remove the bad alternative as it seems to error out if the target files are missing...).
Assignee: bugsquad => guillomovitchSource RPM: (none) => openssh
(In reply to Rémi Verschelde from comment #2) > This might have been fixed since your network install (your log shows > openssh-askpass-common-7.2p2-3.mga6 but we now have > openssh-askpass-common-7.3p1-1.mga6), though I don't see strong evidence of > the alternative being handled differently in recent changes. > > There are no longer references to /usr/lib64/ssh/ssh-askpass in the spec > file though: > http://svnweb.mageia.org/packages/cauldron/openssh/current/SPECS/openssh. > spec?view=markup > > Could you provide the whole install.log? What would be the actual desired compression command for # dir *.log -rw-r--r-- 1 root root 635K Aug 9 22:45 install.log > @Guillaume: I'd expect such issues to pop up on upgrades though, maybe > openssh-askpass-common should have some logic to remove the wrong > alternative before adding the new one (I fixed it for my system manually > yesterday, it was actually a pain to remove the bad alternative as it seems > to error out if the target files are missing...). Yep, in my stupid opinion all rm commands doing cleanup type work should have -f to suppress deletion of non-esistant targets.
The handling of those multiple ssh-askpass alternatives (x11-ssh-askpass, gnome-askpass, askpass-qt4, kssaskpass) seems quite complex, and triggers multiple bug reports since the path change from /usr/lib64/ssh/ssh-askpass to /usr/libexec/openssh/ssh-askpass. Morevoer, at least two of them (x11-ssh-askpass, askpass-qt4) seems unmaintained, and gnome-askpass usefulness is questionable, since gnome-keyring (seahorse) handle entering passphrases directly. I'd rather reduce the number of available alternatives to the ones really needed, and drop usage of setup-alternative in favor of simpler conflict between packages.
(In reply to Guillaume Rousse from comment #4) > I'd rather reduce the number of available alternatives to the ones really > needed, and drop usage of setup-alternative in favor of simpler conflict > between packages. That would be fine by me.
Tue Nov 1 05:54:10 CDT 2016 clean network install does not have the fail message.
Status: NEW => RESOLVEDResolution: (none) => FIXED