I have a couple of CIFS shares in my /etc/fstab that require a password that I manually enter when mounting them. Since migrating to systemd-206, I get sh: /bin/systemd-ask-password: No such file or directory before every password prompt. Creating a link to /usr/bin/systemd-ask-password solves it for me. Reproducible: Always
What was the previous version that you were using? How are you mounting the shares?
(In reply to Michał Górny from comment #1) > What was the previous version that you were using? How are you mounting the > shares? I migrated from a pure openrc system directly to systemd-206 due to the gnome upgrading kerfuffle. I'm mounting the shares via "sudo mount /mountpoint".
The fix for this is part of bug #472792. I have had a patch for the systemd ebuild for some time which hasn't been accepted that would take care of this issue. I will post the specific part of that patch to take care of this issue on this bug.
How about instead of moving shit around, we figure out what is calling /bin/systemd-ask-password and what it is using that path?
Created attachment 354544 [details, diff] fix-systemd-install.patch @mgorny: I have verified on my system that applying this patch and revbumping systemd will install systemd-ask-password in the correct location so there would be nothing else to fix. I know you are concerned about the possible qa violation of having binaries in / linking to libs in /usr/lib* [1]. Read the following blog posts from our qa lead; however, and I think you will agree that he isn't really concerned about it since systemd users who have separate /usr are supposed to use an initramfs anyway [2] [3]. This patch does less than my previous patch since it does not add the optional use flags. Please take a look and tell me what you think. [1] http://blogs.gentoo.org/mgorny/2012/01/04/moving-systemd-into-usr-the-technical-side/ [2] https://blog.flameeyes.eu/2012/12/my-take-on-the-separate-usr-issue [3] https://blog.flameeyes.eu/2013/01/the-boot-process
@mtgorny: By the way, this is the last bug where I'll bring this up, I just think there is a case that is getting stronger for moving things back to where upstream recommends installing them.
Looks like mount.cifs has hard-coded the path to systemd-ask-password. http://git.samba.org/?p=cifs-utils.git;a=blob;f=mount.cifs.c;h=e76beeea80dd40120501a9db966fca61436c6574;hb=HEAD#l1652
That is a valid path, even on a /usr merged system, because /bin points to /usr/bin in that case as well. I suppose it could be argued that the path still shouldn't be hard coded. I'm just thinking that more and more upstreams are going to do this.
(In reply to William Hubbs from comment #8) > I suppose it could be argued that the path still shouldn't be hard > coded. I'm just thinking that more and more upstreams are going to do > this. Right, chasing down paths in various packages could become a chore. We might want to proceed with what has been suggested in bug 472792. Or at the very least, install some compatibility symlinks of our own.
(In reply to Mike Gilbert from comment #9) > (In reply to William Hubbs from comment #8) > > I suppose it could be argued that the path still shouldn't be hard > > coded. I'm just thinking that more and more upstreams are going to do > > this. > > Right, chasing down paths in various packages could become a chore. > > We might want to proceed with what has been suggested in bug 472792. Or at > the very least, install some compatibility symlinks of our own. The problem with installing compatibility symlinks is going to come if/when the /usr merge happens. Say we have a symlink at /bin/system-ask-password pointing to /usr/bin/system-ask-password, then the /usr merge happens. Now there will be file colissions because /bin and /usr/bin are the same location. If we use the method suggested in the previously-mentioned bug, which is what the attached patch in this bug does, that setup is compatible both with and without the /usr merge. Using the compatibility symlinks you suggest is not.
The issue has been reported upstream, a patch has been provided and agreed upon. I'd appreciate if William stopped hijacking bugs with his private war.
We probably need to apply the patch downstream until a new version is released by upstream
+*cifs-utils-6.1-r1 (21 Sep 2013) + + 21 Sep 2013; Pacho Ramos <pacho@gentoo.org> +cifs-utils-6.1-r1.ebuild, + +files/cifs-utils-6.1-hardcoded-path.patch: + Do not rely on hardcoded path to systemd-ask-password, bug #478538 by Dennis + Lichtenthäler +
