| Summary: | kernel rpm links /lib/modules/`uname -r`/build incorrectly (broken after usrmove) | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | kevin martin <ktmdms> |
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | gansalmon, itamar, john.haxby, jonathan, kernel-maint, madhu.chinakonda |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-02-07 17:04:36 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
kevin martin
2012-02-07 14:51:48 UTC
Thanks for the report. I'll look into this today. Should be fixed in tomorrow's rawhide kernel. Unfortunately, the fix to use an absolute pathname is going to cause trouble further down the line. It's not uncommon to use something like kpartx to make available the file systems for a guest file system and in that case the absolute pathname is going to be pointing to completely the wrong place. Similarly, the disk of an ailing machine might be temporarily connected to a machine used to fix problems. (A chroot is not always possible in these environments.) Admittedly, these two use-cases are not common, but the use of relative symbolic links is long established and the cases where the symbolic link is absolute rather than relative does cause unnecessary difficulties when you're trying to sort out some urgent problem. I think relative symbolic links first became the norm when diskless NFS clients became available: in that case you don't want symbolic links pointing outside the diskless client's root. I should add that symbolic links pointing outside of the client's root on a server don't break the client but do cause confusion when looking at the client's root from the server. It was to remove this confusion and some genuine problems that arose from it that relative symbolic links became the norm. We've just got used to having them so that problems that the absolute links used to cause haven't been seen in a while! I'm aware of the problems with absolute links. I didn't forget them. The UsrMove feature for F17 has made /lib a symlink to /usr/lib, so ../../../usr points to nothing on F17 whereas it obviously works on F16. Given that people can grab newer F17 kernels and try to use and build against them on F16, I went with the simplest solution that worked on both. If you have a patch to solve that incompatibility with a relative link, I'd be happy to look at it. Your use cases are valid, but if people are off doing stuff like that, I think they can figure out how to fix a symlink for a couple releases. We can go back to the relative link when F17 is the oldest supported release. That's fine. Can I log a bug against F19 to fix the symbolic link? :-) |