| Summary: | glibc_post_upgrade test is not correct for modern kernels | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Bill Nottingham <notting> |
| Component: | glibc | Assignee: | Jeff Law <law> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 15 | CC: | fweimer, jakub, rvokal, schwab |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-02-06 19:20:37 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
How is that a bug? It was obviously written as a check to see if it's in a chroot, as it doesn't want to perform some of the actions if it is in a chroot. (See the comment, for example). As a test for a chroot, it doesn't work. Does it create any problems? It causes it to run telinit & sshd restart in situations where it shouldn't, relying on telinit and sshd's own mechanisms to error out, not stall the transaction, not do other weird things, etc. Please provide a test case. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. I've improved the code to detect when we're in a chroot by checking inode numbers for the root directory. It's not 100% foolproof, but it will catch the common cases. |
Description of problem: ... /* Check if we are not inside of some chroot, because we'd just timeout and leave /etc/initrunlvl. */ if (readlink ("/proc/1/exe", initpath, 256) <= 0 || readlink ("/proc/1/root", initpath, 256) <= 0) _exit (0); if (check_elf ("/proc/1/exe")) verbose_exec (116, "/sbin/telinit", "/sbin/telinit", "u"); ... These tests all succeed on a modern kernel in brief testing; /proc/1/{exe,root} are readable, and reading /proc/1/exe gives you the init binary, even if it's not in the chroot. Version-Release number of selected component (if applicable): glibc-2.13.90-6.x86_64 How reproducible: Looked at the code when debugging something else