Bug 790521 - dkms executable named /usr/sbin/dkms.old instead of /usr/sbin/dkms
Summary: dkms executable named /usr/sbin/dkms.old instead of /usr/sbin/dkms
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: dkms
Version: rawhide
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: sunil
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: https://fedoraproject.org/wiki/Common...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-02-14 18:33 UTC by Andre Robatino
Modified: 2012-06-09 00:03 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-06-09 00:03:59 UTC
Type: ---


Attachments (Terms of Use)

Description Andre Robatino 2012-02-14 18:33:56 UTC
Description of problem:
On F17 and Rawhide, a fresh install of the dkms package now names the executable as /usr/sbin/dkms.old, even though "rpm -ql dkms" indicates that it should be /usr/sbin/dkms. I have to move it manually. The postin scriptlet says

[ -e /sbin/dkms ] && mv -f /sbin/dkms /sbin/dkms.old 2>/dev/null

Due to the post-usrmove symlink from /sbin to /usr/sbin, this is the same as moving /usr/sbin/dkms to /usr/sbin/dkms.old.

Version-Release number of selected component (if applicable):
dkms-2.2.0.3-2.fc17

Comment 1 sunil 2012-02-16 06:03:39 UTC
(In reply to comment #0)
> Description of problem:
> On F17 and Rawhide, a fresh install of the dkms package now names the
> executable as /usr/sbin/dkms.old, even though "rpm -ql dkms" indicates that it
> should be /usr/sbin/dkms. I have to move it manually. The postin scriptlet says
> 
> [ -e /sbin/dkms ] && mv -f /sbin/dkms /sbin/dkms.old 2>/dev/null
> 
> Due to the post-usrmove symlink from /sbin to /usr/sbin, this is the same as
> moving /usr/sbin/dkms to /usr/sbin/dkms.old.
> 
> Version-Release number of selected component (if applicable):
> dkms-2.2.0.3-2.fc17

Can you please elaborate it? I tried to upgrade the dkms but I did not face the problem.

which was the previous version of dkms and the OS on which you tried to upgrade?


[root@sunil ~]# rpm -ivh dkms-2.2.0.2-1.noarch.rpm
Preparing...                ########################################### [100%]
   1:dkms                   ########################################### [100%]
[root@sunil ~]# rpm -q dkms
dkms-2.2.0.2-1.noarch

[root@sunil ~]# rpm -Uvh /tmp/test/dkms-2.2.0.3-1.fc17.noarch.rpm
warning: /tmp/test/dkms-2.2.0.3-1.fc17.noarch.rpm: Header V3 RSA/SHA256 Signature, key ID 1aca3465: NOKEY
Preparing...                ########################################### [100%]
   1:dkms                   ########################################### [100%]
[root@sunil ~]# cd /usr/sbin/
Display all 384 possibilities? (y or n)
[root@sunil ~]# ls /usr/sbin/dkms*
/usr/sbin/dkms
[root@sunil ~]# rpm -q dkms
dkms-2.2.0.3-1.fc17.noarch

Comment 2 Andre Robatino 2012-02-16 06:23:07 UTC
Not sure why you're not able to reproduce it. Assuming you've done the usrmove conversion and have a symlink  /sbin -> /usr/sbin, /sbin/dkms and /usr/sbin/dkms should be equivalent, so the postin scriptlet should always move /usr/sbin/dkms to /usr/sbin/dkms.old.

As stated in comment 0,

fresh install of dkms (dkms was not previously installed)
OS: either F17 or Rawhide

Comment 3 Andre Robatino 2012-02-16 19:06:09 UTC
To reproduce:

1. Verify that the symlink from /sbin to /usr/sbin exists, as it should on either F17 or Rawhide:

[root@localhost ~]# ls -l /sbin
lrwxrwxrwx. 1 root root 8 Feb 10 22:38 /sbin -> usr/sbin
[root@localhost ~]#

2: Install or update dkms.

Actual results:
Due to the symlink, /usr/sbin/dkms is moved to /usr/sbin/dkms.old.

Comment 4 Vallimar 2012-02-18 13:28:24 UTC
I can confirm this problem.  Furthermore, it happens upon upgrades as well as new installs due to a lack of any logic in the re-naming. I would be surprised if that scriptlet line doesn't violate the packaging guidelines as it doesn't appear to make any sense for why it would be there.  Commenting it out and rebuilding dkms has it behaving normally and as expected.

Comment 5 Andre Robatino 2012-02-18 20:43:12 UTC
Found this in the changelog from over 8 years ago. I'm guessing the scriptlet line has been there ever since. Not sure why it would be necessary though since RPM should clean up the old version's files automatically, unless it was copied from a non-RPM version of the package.

* Wed Oct 29 2003 Gary Lerhaupt <gary_lerhaupt@dell.com> 0.41.10-1
- Added Red Hat specific kernel prep to avoid make dep (Thanks Matt Domsch)
- Added dkms_mkkerneldoth script to support RH kernel prep
- Moved dkms from /sbin/ to /usr/sbin
- Fixed typo which caused original_module not to get replaced on uninstall
- No longer edit Makefiles, just specify KERNELVERSION=$kernel_version on the command line
- Removed unnecessary depmod during uninstall

Comment 6 sunil 2012-02-21 05:26:35 UTC
Ok I can see the problem it seems symlinks are creating the problem.

Comment 7 sunil 2012-02-24 04:45:12 UTC
The patch solves the problem . Submitted to upstream as well.


--- dkms.spec	2012-01-09 16:11:09.000000000 -0500
+++ dkms.spec.orig	2012-02-23 14:25:35.953999530 -0500
@@ -5,7 +5,7 @@ Release: 1%{dist}
 License: GPLv2+
 Group: System Environment/Base
 BuildArch: noarch
-Requires: sed gawk findutils modutils tar cpio gzip grep mktemp
+Requires: sed gawk findutils kmod tar cpio gzip grep mktemp
 Requires: bash > 1.99
 # because Mandriva calls this package dkms-minimal
 Provides: dkms-minimal = %{version}
@@ -116,7 +116,9 @@ rm -rf $RPM_BUILD_ROOT
 
 
 %post
-[ -e /sbin/dkms ] && mv -f /sbin/dkms /sbin/dkms.old 2>/dev/null
+if [ %{_sbindir} == /sbin ]; then
+   mv -f /sbin/dkms /sbin/dkms.old 2>/dev/null
+fi
 # enable on initial install
 [ $1 -lt 2 ] && /sbin/chkconfig dkms_autoinstaller on ||:

Comment 8 Andre Robatino 2012-02-24 19:12:37 UTC
The upstream post is here:

http://lists.us.dell.com/pipermail/dkms-devel/2012-February/001068.html

Comment 9 Andre Robatino 2012-04-09 17:22:44 UTC
Nominating this for CommonBugs. The problem is that due to usrmove, the postin scriptlet (which is over 8 years old)

[ -e /sbin/dkms ] && mv -f /sbin/dkms /sbin/dkms.old 2>/dev/null

now has the effect of renaming the dkms executable as dkms.old, so it's not found after installation, unless it's renamed back. Hence the package is broken out of the box.

Comment 10 Mark Harig 2012-05-11 21:42:50 UTC
Adding some details since this problem remains in dkms-2.2.0.3-2.fc17:

$ ls /usr/sbin/dkms.old
ls: cannot access /usr/sbin/dkms.old: No such file or directory

$  rpm -q dkms
package dkms is not installed

$ sudo yum install dkms
...
Installing:
 dkms                      noarch                      2.2.0.3-2.fc17                       fedora                      105 k
...
Installed:
  dkms.noarch 0:2.2.0.3-2.fc17                                                                                                

Complete!
$ rpm -V dkms
missing     /usr/sbin/dkms

$ ls /usr/sbin/dkms.old
/usr/sbin/dkms.old*

$ file /usr/sbin/dkms.old
/usr/sbin/dkms.old: Bourne-Again shell script, ASCII text executable, with very long lines

$ rpm -qf /usr/sbin/dkms.old
file /usr/sbin/dkms.old is not owned by any package

Because it is not owned by any package, it will not be removed by an un-install/erase action by yum or rpm.

Comment 11 rvcsaba 2012-05-17 22:29:29 UTC
subscribe

Comment 12 Kevin Kofler 2012-05-28 23:06:39 UTC
> -[ -e /sbin/dkms ] && mv -f /sbin/dkms /sbin/dkms.old 2>/dev/null
> +if [ %{_sbindir} == /sbin ]; then
> +   mv -f /sbin/dkms /sbin/dkms.old 2>/dev/null
> +fi

That stupid mv should just be removed entirely instead. RPMs shouldn't be moving around files which don't belong to them.

Comment 13 Andre Robatino 2012-06-02 09:33:17 UTC
There was never any response from upstream. In light of this, I agree with Kevin.

Comment 14 Didier G 2012-06-02 11:53:38 UTC
Same problem with a fresh install.

I had to rename /sbin/dkms.old and /usr/sbin/dkms.old to get dkms working.

Comment 15 Kevin Kofler 2012-06-03 17:52:52 UTC
Dear dkms maintainer,

this bug is trivial to fix, a correction has already been proposed (just remove the offending mv line), and several people are complaining about it. Please fix it! If you do not fix the bug (and file an update in Bodhi to fix it on Fedora 17) within the next 48 hours, I will use my provenpackager powers to fix it.

Thanks in advance for your understanding.

Comment 16 sunil 2012-06-04 05:34:54 UTC
Kevin,

I have contacted upstream maintainer for this, I should be able to fix this in a day or two. 

Thanks,
Sunil

Comment 17 Kevin Kofler 2012-06-04 13:22:19 UTC
Well, please fix this quickly. We

I also don't see why you need to contact the upstream maintainer. You only need to remove one line from the Fedora specfile in Fedora dist-git. There is no requirement in Fedora that our specfile matches the upstream one, and in fact it is almost never the case, because upstream specfiles rarely comply to our packaging guidelines. In particular, trying to move a file which does not belong to the package is a bad idea even when it works as intended.

Comment 18 Kevin Kofler 2012-06-04 13:25:45 UTC
(Oops, I sent the previous message too quickly.)

Well, please fix this quickly. The problem was reported to you almost 4 months ago, well over 3 months before the Fedora 17 release. Now Fedora 17 is released and many users are being hit by the bug, completely unnecessarily, because it should not take 4 months to remove a line from a specfile! The more you delay fixing it, the more users are hit by this stupid bug.

I also don't see why you need to contact the upstream maintainer. You only need to remove one line from the Fedora specfile in Fedora dist-git. There is no requirement in Fedora that our specfile matches the upstream one, and in fact it is almost never the case, because upstream specfiles rarely comply to our packaging guidelines. In particular, trying to move a file which does not belong to the package is a bad idea even when it works as intended.

Comment 19 sunil 2012-06-05 20:45:52 UTC
the patch is committed in upstream 

http://linux.dell.com/cgi-bin/gitweb/gitweb.cgi?p=dkms.git;a=commit;h=e98e7a355dcaad128c00b0bde4ed883e0f5a20d6

I am in process of committing it in fedora will update once done.

Thanks,
Sunil

Comment 20 Fedora Update System 2012-06-05 21:41:33 UTC
dkms-2.2.0.3-3.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/dkms-2.2.0.3-3.fc17

Comment 21 christian.kirbach@googlemail.com 2012-06-06 11:05:57 UTC
Hello sunil,

thanks for fixing this.
Being a contributor to the OS community myself, I hate ranting,
but I am not happy taking it 14 weeks to apply the (rather simple) fix.

I can confirm that dkms-2.2.0.3-3.fc17 fixes it.

However, it still leaves the .old files on the system:

[nazgul@rivendell ~]$ rpm -qv dkms
dkms-2.2.0.3-2.fc17.noarch

[nazgul@rivendell ~]$ ls /sbin/dkms.old 
/sbin/dkms.old

[nazgul@rivendell ~]$ ls /usr/sbin/dkms.old 
/usr/sbin/dkms.old

[nazgul@rivendell ~]$ sudo rpm -U dkms-2.2.0.3-3.fc17.noarch.rpm 
[nazgul@rivendell ~]$ rpm -qv dkms
dkms-2.2.0.3-3.fc17.noarch

[nazgul@rivendell ~]$ ls /usr/sbin/dkms*
/usr/sbin/dkms  /usr/sbin/dkms.old

[nazgul@rivendell ~]$ ls /sbin/dkms*
/sbin/dkms  /sbin/dkms.old

Comment 22 Andre Robatino 2012-06-06 11:27:05 UTC
(In reply to comment #21)

> I can confirm that dkms-2.2.0.3-3.fc17 fixes it.
> 
> However, it still leaves the .old files on the system:

Personally, I think that's best. The problem happened originally because the package insisted on tampering with files that didn't belong to it. Trying to remove the dkms.old file would require a temporary patch that would continue that bad practice (since the dkms.old file doesn't belong to either the old or new versions of the package). The patch would have to be removed eventually, before then it might actually remove a dkms.old file that came from somewhere else (although the dkms.old file *probably* came from the old broken version of the package, there's no guarantee of that), most users will never even notice the dkms.old file, and if they do they can remove it manually.

Comment 23 Andre Robatino 2012-06-06 11:34:04 UTC
(In reply to comment #22)

> Personally, I think that's best. The problem happened originally because the
> package insisted on tampering with files that didn't belong to it.

I should have said "that it *thought* didn't belong to it", since /sbin/dkms actually *did* belong to it, thanks to usrmove. But it's a bad practice anyway.

Comment 24 Fedora Update System 2012-06-07 02:42:57 UTC
Package dkms-2.2.0.3-3.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing dkms-2.2.0.3-3.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-8942/dkms-2.2.0.3-3.fc17
then log in and leave karma (feedback).

Comment 25 Andre Robatino 2012-06-07 19:49:36 UTC
(In reply to comment #24)

> Please go to the following url:
> https://admin.fedoraproject.org/updates/FEDORA-2012-8942/dkms-2.2.0.3-3.fc17
> then log in and leave karma (feedback).

All concerned - please test this, it needs one more +1 to go to stable.

Comment 26 Fedora Update System 2012-06-09 00:03:59 UTC
dkms-2.2.0.3-3.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.