Bug 443602
| Summary: | haldaemon doesn't start (was: no sound with xine) | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Adrin Jalali <adrin.jalali> | ||||||||
| Component: | hal | Assignee: | David Zeuthen <davidz> | ||||||||
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | urgent | Docs Contact: | |||||||||
| Priority: | low | ||||||||||
| Version: | 9 | CC: | atu, mclasen, sonarguy | ||||||||
| 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: | 2009-04-09 13:13:28 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: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Adrin Jalali
2008-04-22 14:21:57 UTC
works fine here (using kaffeine and amarok). I'll try out totem-xine. I upgraded from fedora 9 betta to last rawhide and this happened. I'll attache a maybe related file and this is the lsmod output. # /sbin/lsmod Module Size Used by vfat 13056 0 fat 42784 1 vfat usb_storage 76296 0 cdc_acm 16260 0 rfcomm 34576 0 l2cap 22272 3 rfcomm sunrpc 151412 3 ipt_REJECT 6784 2 nf_conntrack_ipv4 11396 8 iptable_filter 6528 1 ip_tables 13840 1 iptable_filter nf_conntrack_netbios_ns 6144 0 ip6t_REJECT 7552 2 xt_tcpudp 6656 14 nf_conntrack_ipv6 15864 8 xt_state 5888 16 nf_conntrack 49748 4 nf_conntrack_ipv4,nf_conntrack_netbios_ns,nf_conntrack_ipv6,xt_state ip6table_filter 6400 1 ip6_tables 14736 1 ip6table_filter x_tables 15236 6 ipt_REJECT,ip_tables,ip6t_REJECT,xt_tcpudp,xt_state,ip6_tables cpufreq_ondemand 10124 1 acpi_cpufreq 11532 1 fuse 41116 4 dm_mirror 26116 0 dm_multipath 18056 0 dm_mod 49236 2 dm_mirror,dm_multipath radeon 116996 2 drm 145508 3 radeon ipv6 221660 14 ip6t_REJECT,nf_conntrack_ipv6 snd_hda_intel 330144 1 snd_seq_dummy 6660 0 arc4 5760 2 snd_seq_oss 30364 0 ecb 6528 2 crypto_blkcipher 17924 1 ecb b43 123168 0 rfkill 9108 1 b43 snd_seq_midi_event 9600 1 snd_seq_oss mac80211 184928 1 b43 firewire_ohci 21636 0 snd_seq 48448 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event snd_seq_device 10124 3 snd_seq_dummy,snd_seq_oss,snd_seq snd_pcm_oss 42496 0 snd_mixer_oss 16768 2 snd_pcm_oss snd_pcm 67076 2 snd_hda_intel,snd_pcm_oss firewire_core 34336 1 firewire_ohci snd_timer 21640 2 snd_seq,snd_pcm cfg80211 24712 1 mac80211 input_polldev 7176 1 b43 sdhci 16908 0 snd_page_alloc 11400 2 snd_hda_intel,snd_pcm wmi 9640 0 mmc_core 40604 1 sdhci hci_usb 16284 0 snd_hwdep 10500 1 snd_hda_intel video 20368 0 ricoh_mmc 7552 0 crc_itu_t 5760 1 firewire_core b44 25488 0 mii 8192 1 b44 output 6656 1 video snd 48312 10 snd_hda_intel,snd_seq_dummy,snd_seq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer,snd_hwdep bluetooth 47588 3 rfcomm,l2cap,hci_usb button 10000 0 iTCO_wdt 13476 0 pcspkr 6272 0 ac 8068 0 joydev 12608 0 iTCO_vendor_support 6916 1 iTCO_wdt ssb 34052 2 b43,b44 i2c_i801 11920 0 battery 14084 0 dcdbas 10272 0 i2c_core 20628 2 drm,i2c_i801 soundcore 9288 2 snd sr_mod 17064 0 cdrom 32796 1 sr_mod sg 31028 0 ata_generic 8964 0 pata_acpi 8192 0 ata_piix 19972 5 libata 126432 3 ata_generic,pata_acpi,ata_piix sd_mod 25624 6 scsi_mod 120820 5 usb_storage,sr_mod,sg,libata,sd_mod ext3 108424 3 jbd 40852 1 ext3 mbcache 10116 1 ext3 uhci_hcd 22928 0 ohci_hcd 22276 0 ehci_hcd 32268 0 Created attachment 303443 [details]
catalog.cache
Finally I've found it :D the problem was with haldaemon. it was shut down. While starting, start of haldaemon fails and I should start it manually. So how can I report this ? Reassigning to hal, hopefully those kind folks can help sort out what's going wrong. Adrin, can you show us the output you get when starting hal fails ? Created attachment 303574 [details]
dmesg output
ok, I'd like to, but when I start the service after login, no problem exists,
and haldeamon starts and after that, my xine can play audio. But I can attach
the dmesg output for you. I think it's the least.
Also my avahi daemon has the same problem and I should start it manually after logon. This bug I detected after glibc update to 2.8. hald don't show any specific error message (exept 'Failed') at system startup, so I don't know how to debug this condition. After system startup hald starts without errors. Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Confirmed, I have the same problem. Attaching log from tweaked haldaemon script. Created attachment 305996 [details]
stderr from haldaemon script, with an exec 2>| logfile added
What are the start priorities in the rc.d dirs? Does bug sound like whats going on... https://bugzilla.redhat.com/show_bug.cgi?id=444410 Indeed, this recipe from bug 444410 works for me (tm): chkconfig network resetpriorities chkconfig messagebus resetpriorities chkconfig haldaemon resetpriorities Actually, the recipe solved the hald problem. However, after doing an update earlier today the network startup fails. I have a bridge setup, this might possibly be part of the problem. To boot the system, I now need the following in rc.local: service network restart brctl addif br0 vbox5 All this occurred automagically (without any rc.local stuff) until yesterday, governed by the scripts in /etc/sysconfig/network-scripts. Seems like a mess, this ;-) Adrin, Are you still running Fedora 9, or have you upgraded to 10 or Rawhide? In either case, can you let us know whether the issue is still happening, and give the current version of the HAL packages you're using? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers I'm using Fedora 10 using hal-cups-utils-0.6.19-1.fc10.x86_64 hal-libs-0.5.12-14.20081027git.fc10.x86_64 hal-0.5.12-14.20081027git.fc10.x86_64 hal-info-20090202-1.fc10.noarch and the problem was solved a few days after reporting this problem. As I remember, that was because of wrong order of services on start up. And that was the reason when I started it manually, it works fine. I think the bug should be closed ;) :) Regards. Thank you for your bug report. We are closing this bug based on the users latest comment. If these symptoms should return please ensure that your utilizing the latest version of the component and then file a new bug report against that version. CLOSED: NOTABUG -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers |