With a clean install from the Mageia 2 beta 2 DVD on my desktop machine, the elapsed time from leaving the GRUB boot menu to an active GDM login prompt was ~36 seconds, with the switch to the graphics screen occurring at ~33s (I have bootsplash disabled). After performing a full update 2 days ago, the elapsed time has increased to ~65 seconds, with the switch to the graphics screen still occurring at ~33 seconds. The graphics screen remains blank with just a spinning blue circle of dots under the cursor. Examining /var/log/messages, the reason seems to be a long timeout delay in pulseaudio, waiting for the org.bluez service. bluetooth.service has previously failed: Note that my desktop machine has no bluetooth devices. This occurs on every reboot. Not sure which package is to blame for this.
Created attachment 1879 [details] Extract from /var/log/messages I've extracted the relevant section of /var/log/messages. This shows the bluetooth service starting then failing, and pulseaudio reporting a timeout 25 seconds later.
CC: (none) => mageiaBlocks: (none) => 2120Source RPM: (none) => systemd
I've seen this too. I'll certainly get this fixed before release.
Status: NEW => ASSIGNEDAssignee: bugsquad => mageia
I did see this, but can you confirm it's still present? I tried to reproduce the error and it seems to have gone... or rather the error is still there but it doesn't seem to cause any harm. Looking back in my logs I've seen the error as far back as 8th March. I think the reason it's denied is simply due to dbus policy (gdm user is basically not allowed to do all the things a regular user can do). I'm not really too worried about this if it doesn't cause any delays. So can you check again and see if the problem persists with everything up-to-date?
After updating, I no longer get to the GDM login screen at all (although psuedo-ttys are working). Will investigate further tomorrow.
CC: (none) => hhielscher
Well, I still can't figure out why GDM is not being started on boot, but if I start it manually via systemctl start dm.service I still see the ~30s delay and the same messages in /var/log/messages
Oh you might be suffering from a similar problem to Anssi regarding gdm not starting (or rather dm - he was using kdm, but the same logic applies). Can you attach "systemctl show dm.service" and "systemctl --all --full" after boot (i.e. when dm fails to start). As for the gdm bluetooth issue, I'll look into it and see if I can reproduce.
Created attachment 1936 [details] output from systemctl show dm.service
Created attachment 1937 [details] output of systemctl --all --full
Thanks Colin. FWIW I have the gdm bluetooth problem on two different machines, one of which has bluetooth hardware, the other does not.
OK, so the problem is caused by dbus policy that apparently forbids pulseaudio when run as the gdm user from spawning bluetoothd this then results bluetoothd terminating with a 30s timeout. You can fix it with an ajustment to the bluez policy file, but this is a bit hacky. I need to work out the *right* way to do it.
As a work around for the machine that does have bt hardware, the timeout shouldn't kick in if bluetoothd is already running (i.e. does not need bus activation). If you do: systemctl enable bluetooth.service, that should fix things. But obviously if bluetoothd is not running for whatever reason, it still shouldn't delay things.
Oh and as for the dm.service thing, it appears you do have the same problem as Anssi. Good, at least it's not isolated :D I'll work on that too, I'll split it out into a separate bug.
Blocks: (none) => 5262
Please see bug #5262 for the prefdm not starting bug.
OK, so it seems adding: session optional pam_console.so to gdm-welcome pam.d file will solve the problem. I'll fix it in gdm, as I need to tweak the pam.d configs there anyway for gnome-keyring.
Source RPM: systemd => gdm
Your proposed fix works for me on the machine I've tested it on (the other machine is busy right now).
OK, so this should be addressed in latest gdm package. As you've confirmed that it works, I'll close this bug, but please do feel free to reopen if this is incorrect. Hopefully we'll get #5262 licked soon too :)
Closing as per above comment (forgot to do it then!)
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED