Revert "FIX dkms built issues for rhel kernel update ,change prerm sc… #77
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ript to fix." This reverts commit 0c19129. Per man dkms, the `uninstall` command should leave the uninstalled modules in the 'built' state and only removed after running `remove`.
|
@yuzaipiaofei can you please review this? |
|
LGTM |
|
Holy cow, I just ran into this exact issue, I can't believe it's been around for 2 years! Thanks for the fix! |
evelikov
pushed a commit
to evelikov/dkms
that referenced
this pull request
Jan 20, 2020
Add an action "unbuild" to align with the existing "build" one. This provides for a complete symmetry - add/remove, build/unbuild and install/uninstall. Apart from the seeming cosmetic affect, this function is required when the binary kernel module(s) produced with "dkms build" must be pruned. Without this command that is not possible since using: - "dkms uninstall" will remove the symlinks/copies produced with "dkms install", while - "dkms remove" will erase all references of the dkms module. Hence "dkms status" will have no references about the module. This allows for a proper fix for dell#20 while avoiding regressions like dell#77 Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
superm1
pushed a commit
that referenced
this pull request
Feb 19, 2020
Add an action "unbuild" to align with the existing "build" one. This provides for a complete symmetry - add/remove, build/unbuild and install/uninstall. Apart from the seeming cosmetic affect, this function is required when the binary kernel module(s) produced with "dkms build" must be pruned. Without this command that is not possible since using: - "dkms uninstall" will remove the symlinks/copies produced with "dkms install", while - "dkms remove" will erase all references of the dkms module. Hence "dkms status" will have no references about the module. This allows for a proper fix for #20 while avoiding regressions like #77 Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
…ript to fix."
This reverts commit 0c19129.
Creating this PR also for discussion, as we think the current behavior is wrong and not fitting the design defined in the manpage.
Per man dkms, the
uninstallcommand should leave the uninstalled modules in the 'built' state and only removed after runningremove. After this commit it seems that dkms uninstall started to remove the modules from the built tree, making them no longer stay in the 'built' state (they're not reported as such anymore).This caused a regression in Ubuntu 19.04 where some of our other packages expected things to work as per the manpage. Quoting:
"Uninstalls an installed module/module-version combo from the kernel/arch passed in the -k option, or the current kernel if the -k option was not passed upon. After uninstall completion, the driver will be left in the built state.
To completely remove a driver, the remove action should be utilized."
Without this change reverted, this does not seem to be the case anymore. After the revert,
dkms uninstallseems to work as expected (and as it previously did). What was the rationale for the original change? What use-case was it fixing? The change description wasn't very descriptive.Thank you!