Created attachment 531057 [details] dmesg output Description of problem: Some "pause" occurs before login screen appears. Then after login screen, could not open live session. Version-Release number of selected component (if applicable): https://download.fedora.redhat.com/pub/alt/stage/16.RC2/Live/x86_64/Fedora-16-x86_64-Live-Desktop.iso Checksum ok. Used dd to place it on USB dongle. Dongle boots ok, built-in media check also passed. How reproducible: Always I suppose. My first two attempts with F16, for sure. Steps to Reproduce: 1. Create the media 2. Boot Asus V1S from it (note: external screen also attached, and "everything" happens there) 3. Shortly before login screen, process seems paused. Press [Enter] x times 4. Login screen (kdm) then appears. Press [Enter] again x times Actual results: Session eventually starts loading (KDE Splash screen) while icons are being displayed as usual from left to right (3 of them ?) Nothing else happens. Other ttys are available and responding. After a while switching back and forth, KDE Splash screen leaves place to the initial boot screen. Expected results: Login screen is reached without such "pause" Then after login screen, session opens. Additional info: Attached are lspci, lsusb and dmesg outputs (sorry no Xorg.0.log), as well as a (bad) photo of the final result (back to the initial boot screen on first tty). I can try again tomorrow - with and without external screen attached - connected to a CatV cable (hence getting the machine easily online) - to grab more log files especially Xorg.0.log and will follow any guidance. Thanks. Xavier
Created attachment 531058 [details] lspci output
Created attachment 531059 [details] lsusb output
Created attachment 531060 [details] first tty back to initial boot screen That phone really makes ugly photos, display was much nicer :)
Created attachment 531061 [details] first tty back to initial boot screen (zoom!) :)
Important, same machine runs F14 KDE daily great till now (didn't try F15). Using kmod-nvidia from rpmfusion because Nouveau was lacking perfection (but never prevented starting KDE or opening a session, IIRC).
Had a chance to try RC3 (shasum256 ok, used dd to place it on usb flash drive, then it passed self media check, both before and after reproducing the error). Could reproduce the issue and tried a few more things. Conjunction of few different issues ? Here is my two cents, including errors of mine I guess ^^ Ugly screen caps I posted, are still a potential "end point" of the boot attempt here. However it is possible to start a successful session if patient enough. Such graphical failure (but not the failure itself, unfortunately) seems exclusive to having chosen "Check this media and launch" option in advanced boot. That media check takes tty0 into a different graphic mode, has no "finished" look and feel and gets a wrong display geometry, but the media check works and, itself, doesn't seem to cause the failure. Once complete, "check screen" disappears while KDM session is preparing (during standard splash), but then it will come back whenever X gets terminated (?) or fails at a later stage. So -- while KDM session is being prepared (showing the 2nd icon, aka "Settings" under KDE, precisely), a sound can be heard. At this moment, progress stops (but doesn't freeze, mouse pointer moves) for a "pause" that lasts around 4'30 to 5 minutes. During this time, pressing Ctrl+Alt+Fx let one switch ttys and come back to the "paused" kdm splash screen. Initially attached "dmesg" was coming from this stage, I'll now add two more logs with a ".pause" suffix. If *not* being very patient (or not being quietly busy on another tty), hitting Enter or Ctrl+Alt+Enter (I think) "regresses" to the login screen (which *was* previously skipped with success, hence it's the first time it appears). User name is auto-filled as "liveuser" as expected. Pressing now simply the Enter key will *not* start any session, Ctrl+Alt+Enter restarts KDM every time (rapid flash, same screen). After a few retries X seems to terminate and that's when it leaves place to the "check screen" for good. Shutting down from cli in tty1 doesn't work (signal sent, tty's get closed but tty1 end up printing yet another 4 lines of error messages, last stating some process is "restarting"). I'll attach another set of logs for this stage with the ".failed" suffix. If, instead, *being* very patient, after these 5 minutes KDM Splash leaves place "automagically" to a deep blue screen with a small error dialogue: « Unable to save bookmarks in /home/liveuser/.local/share//user- places.xbel. Reported error was: Insufficient permissions in user directory.. This error message will only be shown once. The cause of the error needs to be fixed as quickly as possible, which is most likely a full hard drive. » (sic! double slashes, dots and formatting here, were exact literal on screen) Closing the error dialogue by pressing OK/Esc, KDE session finally starts, and seems to work great overall. I could use eg. Konqueror, Konversation and other apps over wlan. I'll attach a third set of logs with a ".session" suffix for this stage. Thanks. (seen a few unrelated obvious krash/bugs, thou, will report too)
Created attachment 531223 [details] dmesg at "pause" stage
Created attachment 531225 [details] messages at "pause" stage
Created attachment 531226 [details] Xorg.0.log at "pause" stage
Created attachment 531228 [details] messages at "fail" stage
Created attachment 531230 [details] Xorg.0.log at "fail" stage
Created attachment 531231 [details] messages at "session" stage
Created attachment 531232 [details] Xorg.0.log at "session" stage
Created attachment 531357 [details] Core dump 1
Created attachment 531358 [details] Core dump 2
Tried RC4, putting by brain in (better ?) order Cf. my Comment 6 -> Bug 750838 (just open) "Check media" (advanced boot option) exposes keyboard interrupts to KDM, leading to session start fail. Attached two core dumps I found reading messages
Observed the same on f15 with usb bluetooth inserted. Little googling and found this: https://bbs.archlinux.org/viewtopic.php?id=112580 Modified kickstart script to create /home/liveuser/.local/share directory in the livesys initscript as workaround (I am using customized scripts anyway). But: 1) This error message is misleading 2) Why 5 min delay?
Confirmed : disabling bluetooth (internal here)
Seems https://bugs.launchpad.net/ubuntu/+source/kde4libs/+bug/627815 has some good analysis of the problem, I'll keep reading and see if we can come up with something.
Researching the "unable to save user-places.xbel" problem, seems this is supposedly mostly harmless. Re: comment #17 Armands, did pre-creating ~/.local/share make the 5 minute delay go away too or just the error message?
Looks like Kubuntu already has a workaround, we just need to apply their patch.
(In reply to comment #20) Yes, with pre-creating directory the delay goes away too.
Still current in RC5. Description of problem: Some very long and almost silent "pause" (almost 5 minutes here) occurs during KDE splash screen *if* and only if some USB bluetooth adapter is present (integrated to the Asus V1S, and enabled by default when system first loads). After the delay, an interactive error dialogue then appears, before session completes to load with success. Version-Release number of selected component (if applicable): Fedora 16 Live KDE : RC2 RC3 RC4 RC5 https://download.fedora.redhat.com/pub/alt/stage/16.RC5/Live/x86_64/Fedora-16-x86_64-Live-Desktop.iso Checksum ok, placed on a USB dongle using dd, boots and self-media check pass. How reproducible: Always. Steps to Reproduce: 1. Boot KDE Live CD. 2. Make some coffee. Integrated USB Bluetooth dongle is automatically enabled at system load, as ever (this equipment presents a led, which is turned on at this time) Actual results: 3. During KDE Splash screen (2nd icon aka "Settings" showed up), a sound is played but nothing appears. It just "pauses". Input devices and other ttys remain available and responding. 4. After 5 minutes, a blue screen shows up with (unrelated?) error dialogue. 5. Exiting dialogue will then let KDE session start correctly. Expected results: 3. Session is started without any delay or error. Additional info: Dialogue at step 5 (literal): « Unable to save bookmarks in /home/liveuser/.local/share//user- places.xbel. Reported error was: Insufficient permissions in user directory.. This error message will only be shown once. The cause of the error needs to be fixed as quickly as possible, which is most likely a full hard drive. » Workaround This equipment offer a special key to toggle Bluetooth on/off, automatically handled correctly but not immediately after device is auto-enabled. Switching it off ASAP (half way before Fedora logo appears), let everything goes as expected. Switching it back on once KDE session is fully started, shows BT icon in tray and prove functional /a priori/ (basic device search and PIN exchange success).
OK, pre-creating ~/.local/share directory should be easy enough to add as a quick-n-dirty workaround. No idea how that relates to the long delay though...
Catching up ^^ oh, okay. Thanks for looking at this. Sorry my initial description was a mess, comment #23 should be clearer. But I can see now it wasn't needed :) Are my kernel dumps any related ? Armands, did you get kernel dumps too ? Or is it yet another issue ?
No kernel dumps here.
Armands, could you please provide lsusb info about your adapter ?
Don't know how it can help, but please: Bus 003 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode) or you wanted more detailed?
Thanks ^^ Not sure either, but we gotta have something in common :) Bus 004 Device 002: ID 0b05:1712 ASUSTek Computer, Inc. BT-183 Bluetooth 2.0+EDR adapter Still can't see what, thou.. https://www.google.com/search?q=%2B"0b05:1712"+%2B"0a12:0001"
Here we get more slight more evident match ^^ Hope all CSRs won't be affected cause it seems widespread :/ # hciconfig -a hci0: Type: BR/EDR Bus: USB BD Address: 00:1B:FC:EF:42:9F ACL MTU: 384:8 SCO MTU: 64:8 UP RUNNING PSCAN RX bytes:713 acl:0 sco:0 events:27 errors:0 TX bytes:364 acl:0 sco:0 commands:27 errors:0 Features: 0xff 0xff 0x8b 0xfe 0x9b 0xf9 0x00 0x80 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH HOLD SNIFF PARK Link mode: SLAVE ACCEPT Name: 'venus.xapaho.com-0' Class: 0x580100 Service Classes: Capturing, Object Transfer, Telephony Device Class: Computer, Uncategorized HCI Version: 2.0 (0x3) Revision: 0x77b LMP Version: 2.0 (0x3) Subversion: 0x77b Manufacturer: Cambridge Silicon Radio (10)
Created attachment 531716 [details] Fresh log set (bt off, on, pause, reduced with grep) Ran Live RC5 twice more to get clean logs - with bluetooth ON, which brings delay (*.bt-on, *.bt-on.pause) - with bluetooth OFF, brings no delay (*.bt-off) - grep'd them all to reduce differences as I was comparing (*.grep)
Could the link be a defect in power management for this BT chipset model/range from CSR ? Here are logs differences I found. 1. ~/.xsessions-errors a. unique to bt-on, little before pause Agent registered QFile::remove: Empty or null file name QFile::remove: Empty or null file name then while resuming **** kded(1507) PowerDevil::Action::trigger: Unsatisfied policies, the action has been aborted **** kded(1507): "Unable to save bookmarks in /home/liveuser/.local/share//user-places.xbel. File reported the following error-code: 13." b. instead, in bt-off QDBusObjectPath: invalid path "" QObject::connect: Cannot connect (null)::deviceFound(Device*) to BlueDevilDaemon::deviceFound(Device*) QObject::connect: Cannot connect QTimer::timeout() to (null)::stopDiscovery() 2. /var/log/messages Two blocs both unique to bt-on* (these were rather expected ^^) Nov 3 22:25:10 localhost bluetoothd[1042]: Listening for HCI events on hci0 Nov 3 22:25:10 localhost bluetoothd[1042]: bluetoothd[1042]: Listening for HCI events on hci0 Nov 3 22:25:10 localhost bluetoothd[1042]: HCI dev 0 up Nov 3 22:25:10 localhost bluetoothd[1042]: bluetoothd[1042]: HCI dev 0 up Nov 3 22:25:10 localhost bluetoothd[1042]: Parsing /etc/bluetooth/serial.conf failed: No such file or directory Nov 3 22:25:10 localhost bluetoothd[1042]: bluetoothd[1042]: Parsing /etc/bluetooth/serial.conf failed: No such file or directory Nov 3 22:25:10 localhost kernel: [ 92.308459] Bluetooth: RFCOMM TTY layer initialized Nov 3 22:25:10 localhost kernel: [ 92.308466] Bluetooth: RFCOMM socket layer initialized Nov 3 22:25:10 localhost kernel: [ 92.308468] Bluetooth: RFCOMM ver 1.11 Nov 3 22:25:10 localhost bluetoothd[1042]: Adapter /org/bluez/1042/hci0 has been enabled Nov 3 22:25:10 localhost bluetoothd[1042]: bluetoothd[1042]: Adapter /org/bluez/1042/hci0 has been enabled Nov 3 22:25:12 localhost systemd[1]: Failed to read PID file /var/run/fcoemon.pid after start. The service might be broken. Nov 3 22:25:13 localhost systemd[1]: Failed to read PID file /run/sm-client.pid after start. The service might be broken. 3. dmesg Two blocks, both unique to bt-off* (I really did *not* expect such difference) [ 0.176108] pci 0000:09:01.0: proprietary Ricoh MMC controller disabled (via firewire function) [ 0.176110] pci 0000:09:01.0: MMC cards are now supported by standard SDHCI controller [ 2.030896] ep_00: hash matches [ 2.030899] ep_00: hash matches [ 2.030902] ep_00: hash matches [ 2.030904] ep_00: hash matches [ 2.030907] ep_00: hash matches [ 2.030909] ep_00: hash matches [ 2.030912] ep_00: hash matches
*** Bug 752327 has been marked as a duplicate of this bug. ***
So, this is really a mess. So far, we still don't know reliably: * whether the delay is directly related to the user-places.xbel error or whether they're both caused by some common cause, * whether Bluetooth has anything to do with this or whether this can also be triggered by some other hardware, * what exactly is causing this, * whether it was a mistake not to treat this as a release blocker.
Created attachment 533274 [details] System up to date, logs from new user "Bart Simpson" I can reproduce at will: just create a new user... Benefit is that we could prepare this test bed ? I can't migrate anyway into F16 at it stand now, this is a fresh install and is up to date, getting filled with debuginfos as I issue backtraces for other purposes. Yet, please welcome Bart and his new set of logs, similar to previous ^^ Attaching an archive, I haven't diff/grep'ed those. 1. Reboot with Bluetooth on, login, warning sound -> "paused" log folder 2. After the 5min delay, dialogue opened, session launched -> "resumed" log folder [ ..bonus, plasma starts behaving a little weird w/ windows drawn off-screen cf. what I was trying to reproduce for another bug (I didn't push yet) ] 3. Reboot, login again, no delay -> "subseq" log folder
Anyone mind testing updating to kde-settings-4.7-14, https://koji.fedoraproject.org/koji/taskinfo?taskID=3528505 and try logging in as a new user (ie, one with no ~/.kde or ~/.local), to see if this workaround of ensuring ~/.local/share exists helps?
OK, here's a kde-settings-4.7-14 build that actually succeeded, http://koji.fedoraproject.org/koji/buildinfo?buildID=274983
kde-settings-4.7-14.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/kde-settings-4.7-14.fc16
http://quickgit.kde.org/?p=kdelibs.git&a=commitdiff&h=f67c4d76139d85968f17284fa6ba4b00adacf62b looks like the fix for this. But I wonder if kdelibs/kdecore/io/ksavefile.cpp:KSaveFile::open() should do this, as kdelibs/kdecore/config/kconfigini.cpp:KConfigIniBackend::createEnclosing() does for kconfig files. Still not obvious where the timeout comes from. Probably something that is listening to signals emitted by KBookmarkManager? Or something in KMessageBox::error()?
PS. I compared 'strace -e trace=file' for a login with and without an existing .local in a futile attempt to work out what's going on (logs available). Didn't find anything conclusive, but: * it looks likely that user-places.xbel* really is the only file missing (ENOENT or not mentioned) on the first (slow) login that's acessed on the second (normal) login. * There may be other similarly fragile components, but kio_trash creates directories down to .local/share/Trash early on, so hiding potential problems with anything after it.
The aforementioned patch from Comment #39 is already included in kdelibs-4.7.3, yet folks seem to be still experiencing this after updating to kde-4.7.3, no? (Seems my kde-settings workaround is not really needed then, unless anyone can help test whether that's true or not).
Package kde-settings-4.7-14.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kde-settings-4.7-14.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2011-16215/kde-settings-4.7-14.fc16 then log in and leave karma (feedback).
Comment #40 was not based on 4.7.3 - it was performed on a pre-release nightly image of F16 that happened to be the newest image on the usb stick I booted with, I did mean to include version details, but it got lost in the editing process, sorry. I think all the other reports in this bug pre-date 4.7.3 being pushed to stable?
Created attachment 535056 [details] cannot reproduce the issue, yum history Good news here, I could *not* reproduce this issue any longer, while (still): # rpm -qa kde-settings kde-settings-4.7-13.fc16.4.noarch Changes I did in the mean time: 1. install a few debuginfo packages, tracing other bugs 2. customize grub install (moving /boot, fresh grub2-install, custom settings) 3. yum update to latest stable For now I am attaching yum history. I'll most probably re-install anyway. If so, I will only yum update, so I can firmly confirm whether this issue should be considered as resolved -- for this hardware. Delay during KDM's first icons display, is now just a few seconds (which I assume is normal for a new user). Still, I found many dbus & other errors in xsession-errors, will attach if related/required.
Catching up with the thread ^^ Yes, indeed, my last test and comment #35 were on KDE 4.7.2 (after updating on Nov. 12th). So 4.7.3 seems to fix the issue. But again, I'll confirm after fresh reinstall. NB. I noticed also that under 4.7.2, just disabling/re-enabling bluetooth at KDM screen (before new user login), was removing the issue.
May I confirm, thanks: fresh install + yum update (4.7.3) = "problem gone" ^^ Workaround (for users to reach yum update -- booting LiveCD and first boot after install): - turn device off+on around KDM (in my case, using Asus' Bluetooth laptop key) - if this didn't help: once KDM has paused -> Ctrl+Alt+BackSpace and login again
kde-settings-4.7-14.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.