| Summary: | nss_db-2.2.3-0.3.pre1.el6_1.1 breaks ssh logins | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Kevin Fenzi <kevin> | ||||
| Component: | nss_db | Assignee: | Nalin Dahyabhai <nalin> | ||||
| Status: | CLOSED ERRATA | QA Contact: | BaseOS QE Security Team <qe-baseos-security> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 6.1 | CC: | mussulma, prc | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2011-08-19 16:31:29 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Bug Depends On: | 712125 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
|
Description
Kevin Fenzi
2011-07-22 21:52:59 UTC
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. If you would like it considered as an exception in the current release, please ask your support representative. Additionally, this nss_db seems to cause rhel6 xen (or kvm) guests to panic on boot. I've not tried it on a bare metal machine. From a xen guest case: blkfront: xvda: barriers disabled xvda: xvda1 xvda2 xvda3 dracut: Scanning devices xvda3 for LVM logical volumes GuestVolGroup00/root dracut: inactive '/dev/GuestVolGroup00/root' [7.72 GiB] inherit EXT4-fs (dm-0): INFO: recovery required on readonly filesystem EXT4-fs (dm-0): write access will be enabled during recovery EXT4-fs (dm-0): recovery complete EXT4-fs (dm-0): mounted filesystem with ordered data mode dracut: Mounted root filesystem /dev/mapper/GuestVolGroup00-root dracut: Loading SELinux policy type=1403 audit(1311367267.760:2): policy loaded auid=4294967295 ses=4294967295 dracut: dracut: Switching root udev: starting version 147 Initialising Xen virtual ethernet driver. kjournald starting. Commit interval 5 seconds EXT3-fs (xvda1): using internal journal EXT3-fs (xvda1): mounted filesystem with ordered data mode Adding 2097144k swap on /dev/xvda2. Priority:-1 extents:1 across:2097144k SS Kernel panic - not syncing: Attempted to kill init! Pid: 1, comm: init Not tainted 2.6.32-131.6.1.el6.x86_64 #1 Call Trace: [<ffffffff814da518>] ? panic+0x78/0x143 [<ffffffff81300366>] ? get_current_tty+0x66/0x70 [<ffffffff8106c452>] ? do_exit+0x852/0x860 [<ffffffff8106c4b8>] ? do_group_exit+0x58/0xd0 [<ffffffff8106c547>] ? sys_exit_group+0x17/0x20 [<ffffffff8100b172>] ? system_call_fastpath+0x16/0x1b Just to clarify, when the guest panics, are you talking about nss_db in the guest, or on the host? In the guest. Downgrading the guest's nss_db causes it to boot ok again. Whoa, how'd I miss that 'undefined symbol' error? This isn't the weird signal-handling thing I suspected it would be, after all. The new package depends on a glibc change (bug #705465, the fix for which makes __libc_alloca_cutoff externally-accessible for us here) that at this time is still in the queue. Created attachment 515928 [details]
work around __libc_alloca_cutoff() not being available by acting as though it always fails
It looks like the glibc update has been released: https://rhn.redhat.com/rhn/errata/details/Details.do?eid=12021 Kevin, does this resolve the problem you're seeing? Based on a quick peek at the symbol table in the updated glibc package, I believe it will. I can confirm that this fixes the issue I was seeing. ;) Thanks. Awesome. I guess I can mark this as closed->errata, then, even if it ended up being fixed by a glibc erratum rather than an nss_db one. |