Bug 411321
Summary: | sound drivers created with different ownership/permission | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Sammy <umar> |
Component: | pilot-link | Assignee: | Ivana Varekova <varekova> |
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | 8 | CC: | bnocera, davidz, farrellj, lam, libbe, luis, mcepl, mcepl, pgueckel, ralston, redhat-bugzilla |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2007-12-10 10:06:04 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 158809, 280251 |
Description
Sammy
2007-12-05 00:50:38 UTC
This happened to me yesterday, after upgrading my F8 with updates-testing enabled. You're wrong though about the normal permissions - on my other two machines (one is F8, upgraded with updates-testing disabled, second is rawhide), all files under /dev/snd are root.root and 660 (and opening them as normal user works miraculously). Looking through rpm -qa --last, I see no package that I can suspect of causing that, apart for the kernel (upgraded from 2.6.23.8-62.fc8 to 2.6.23.8-63.fc8), but the kernel isn't the (only?) cause - downgrading to 2.6.23.8-62.fc8 or 2.6.23.1-49.fc8 doesn't help. That's why I think "kernel" is not the proper component for this bug. chmod o+rw /dev/snd/* is a short-term work-around for single-user systems, but I'm wondering, what happened and how to fix it for good. I just noticed a suspected program looking in dmesg (on two different kernels): hal-acl-tool[3111]: segfault at 0ab66914 eip 00b80c4c esp bf8154f4 error 4 lines like this pop up whenever I log in (be it the GNOME session or plain VT) with different "at" and "esp" addresses, but eip and error are the same. I've never seen hal-acl-tool segfaulting before (confirmed by grep on /var/log). The only hal-acl-tool I know about is /usr/libexec/hal-acl-tool from hal-0.5.10-1.fc8. But there was no upgrade for hal in F8. I also checked if any of the libs in `ldd /usr/libexec/hal-acl-tool` come from an upgraded packages, with no success. So I have a suspect, but I still don't know what caused it to break. I booted into kernel -77 and everything worked fine. I updated from updates- testing and on the next reboot the sound didn't work. If it helps, here's the packages that got updated: Dec 04 10:54:06 Updated: compiz-fusion - 0.6.0-7.fc8.i386 Dec 04 10:54:07 Updated: flash-plugin - 9.0.115.0-release.i386 Dec 04 10:54:14 Updated: firefox - 2.0.0.10-2.fc8.i386 Dec 04 10:56:04 Updated: compiz-fusion-gnome - 0.6.0-7.fc8.i386 Dec 04 11:04:14 Updated: createrepo - 0.4.11-1.fc8.noarch Dec 04 11:04:15 Updated: python-telepathy - 0.14.0-4.fc8.noarch Dec 04 11:04:18 Updated: shadow-utils - 2:4.0.18.1-20.fc8.i386 Dec 04 11:04:20 Updated: pilot-link - 2:0.12.2-9.fc8.i386 Dec 04 11:04:22 Updated: xorg-x11-server-Xorg - 1.3.0.0-36.fc8.i386 Dec 04 11:04:23 Updated: xorg-x11-server-utils - 7.3-2.fc8.i386 Dec 04 11:04:29 Updated: gdm - 1:2.20.2-2.fc8.i386 Dec 04 11:05:09 Updated: evolution - 2.12.2-2.fc8.i386 Dec 04 11:05:11 Updated: gnokii - 0.6.22-1.fc8.i386 Dec 04 11:05:12 Updated: libtheora - 1.0beta2-3.fc8.i386 Dec 04 11:05:15 Updated: ghostscript - 8.61-4.fc8.i386 Dec 04 11:05:17 Updated: poppler - 0.6.2-1.fc8.i386 Dec 04 11:05:21 Updated: rhythmbox - 0.11.3-5.fc8.i386 Dec 04 11:05:21 Updated: xen-libs - 3.1.2-1.fc8.i386 Dec 04 11:05:22 Updated: xorg-x11-drv-ati - 6.7.196-2.fc8.i386 Dec 04 11:05:26 Updated: freeciv - 2.1.1-1.fc8.i386 Dec 04 11:05:27 Updated: dcraw - 8.80-1.fc8.i386 Dec 04 11:05:47 Updated: BackupPC - 3.1.0-1.fc8.noarch Dec 04 11:05:48 Updated: gdm-extra-faces - 1:2.20.2-2.fc8.i386 This was caused by pilot-link upgrade (can be because of a try to fix bug 158809). Downgrading pilot-link fixes the issue. Just don't ask me how many reboots it required to make sure :) I'm asking you to switch the component to hal. No matter, which package causes HAL to break (pilot-link can blame udev, udev can blame kernel or something else), a system as important as HAL to todays Fedora can't never, ever, segfault. I'd change the component, but only the submitter can do that. Meanwhile, I'm commenting in https://admin.fedoraproject.org/updates/F8/FEDORA-2007-4050 to stop pilot-link from being pushed to updates. (In reply to comment #1) > You're wrong though about the normal permissions - on my other two machines (one > is F8, upgraded with updates-testing disabled, second is rawhide), all files > under /dev/snd are root.root and 660 (and opening them as normal user works > miraculously). This is because in a login process the hal-acl-tool sets acl permissions on that files. But now hal-acl-tool is segfaulting, so no persmissions are set. (In reply to comment #2) > I just noticed a suspected program looking in dmesg (on two different kernels): > hal-acl-tool[3111]: segfault at 0ab66914 eip 00b80c4c esp bf8154f4 error 4 > lines like this pop up whenever I log in (be it the GNOME session or plain VT) > with different "at" and "esp" addresses, but eip and error are the same. I've > never seen hal-acl-tool segfaulting before (confirmed by grep on /var/log). Are you able to get a stack trace? Not being sure if this does something to do with kernel (comment #3), I don't change the component -- just adding the HAL maintainer to CC. I don't see any hal-acl-tool messages, but my sound card has stopped working after I updated only pilot-link from updates-testing. Seeing this too, since the same batch of updates. [I'd mark this 'urgent', since sound is, you know, fairly critical, but I don't have perms.] This had been driving me mad too. Having to chmod a+rx /dev/snd/* before logging in was getting old. I can confirm that reverting back to pilot-link-0.12.2-7.fc8 from -9 in updates-testing has fixed the problem. Reverting pilot-link fixes the soundcard for me too. Curiously, the newer pilot-link package with the PolicyKit/udev permissions rule also seems to break the fingerprint reader on my laptop - which works in gdm but not gnome-screensaver, where it fails with an selinux alert: Dec 5 21:29:51 localhost kernel: input: Virtual ThinkFinger Keyboard as /class/input/input8 Dec 5 21:29:54 localhost setroubleshoot: #012 SELinux is preventing /usr/bin/setfacl (hald_acl_t) "setattr" to <Unknown> (event_device_t).# 012 For complete SELinux messages. run sealert -l bafd80da-bc89-4933-9818-85ea94d9fd42 The sealert raw audit messages were: avc: denied { setattr } for comm=setfacl dev=tmpfs egid=0 euid=0 exe=/usr/bin/setfacl exit=-13 fsgid=0 fsuid=0 gid=0 items=0 name=event8 pid=7079scontext=system_u:system_r:hald_acl_t:s0 sgid=0 subj=system_u:system_r:hald_acl_t:s0 suid=0 tclass=chr_file tcontext=system_u:object_r:event_device_t:s0 tty=(none) uid=0 With pilot-link reverted the fingerprint reader Just Works, and I just get: Dec 5 23:12:30 localhost kernel: input: Virtual ThinkFinger Keyboard as /class/input/input8 FWIW, I've filed a separate bug against pilot-link. (In reply to comment #11) > FWIW, I've filed a separate bug against pilot-link. Which is bug 412921 but not everyone may be able to see it just yet as it's marked as security... Fixed in pilot-link-0.12.2-10. I can confirm that it is fixed by pilot-link 0.12.2-10. *** Bug 412581 has been marked as a duplicate of this bug. *** |