After a clean install using Mageia 3 alpha 3 x86-64 dvd from Sun Nov 11 21:11:12 CET 2012 (custom install, selecting everything except individual package selection), logging in to a kde session, and then pressing alt+ctrl+f2, a blank screen is displayed. Pressing alt+ctrl+f1 goes back to a kdm login screen. After installing rsyslog, /var/log/syslog shows ... Nov 11 22:16:09 x3 kernel: QProcessManager[5027]: segfault at 8 ip 00007fb73d99231b sp 00007fb72bae64e8 error 4 in libQtDBus.so.4.8.3[7fb73d950000+79000] Nov 11 22:16:11 x3 kdm[891]: X server for display :0 terminated unexpectedly Similarly, after logging into a gnome classic session, after the switch to a blank screen on tty2, back to the kdm login on tty1, it has ... Nov 11 22:19:31 x3 gnome-session[6217]: Gdk-WARNING: gnome-session: Fatal IO error 11 (Resource temporarily unavailable) on X server :0. Nov 11 22:19:31 x3 kdm[891]: X server for display :0 terminated unexpectedly My guess at this point, is that there is a permissions problem with kdm. I'll dig into this more tomorrow.
Whiteboard: (none) => 3alpha3
Created attachment 3080 [details] syslog output switching to/from tty2 under gdm Same result using gdm instead of kdm. tty2 stays blank, kills de on tty1.
This bug does not affect an install done using the gnome i586 dvd, so it's most likely a missing package causing the problem. I'll try and track down which one(s).
Assignee: bugsquad => ennael1
Created attachment 3083 [details] List of packages, one or more of which are causing the bug. The bug is present after a Mageia-3-alpha3-i586-DVD gnome install. It is not present after a Mageia-3-alpha3-LiveDVD-GNOME-i586-DVD gnome install. The packages in the attached list, are all installed, after an install from the live dvd, but not from the install dvd. Installing all of the nonfree packages does fix the problem, but I'm having trouble narrowing down which one(s) are actually needed, to fix it.
Priority: Normal => release_blocker
The bug is not present in a vb install, so taking the release blocker tag off.
Priority: release_blocker => Normal
Finally figured out the problem. It is not a missing package. To fix the problem, I have to run "dracut -f", and then reboot. So it looks like the problem is caused the the installer running dracut before I've had a chance to configure the monitor. My old crt monitor does not return any edid information, and has a maximum resolution of 1280x1280, but my video card is capable of resolution settings of 1600x1200. With the live iso images, bug 7774 explains the workaround I currently use. As that's done before dracut gets run, the reboot after install is ok. It may get fixed by having the installer running under systemd, or by including the firmware, but I expect it will require postponing the running of dracut until after the video resolution has been set in the summary. Would probably be a good idea to run dracut at the same time as the boot loader installation. Resetting the priority to release blocker, as discussed on irc.
CC: (none) => eeeemail
CC: (none) => mageia, thierry.vignaud, tmb
Hmm, do you have the install logs? Dracut should not run until the preparing bootloader stage but previously there were bugs in e.g. mageia-theme that triggered it early via a circuitous route. It would be nice to know at what point the initrd was generated in the install process as that would give us a list of package with faulty post scripts...
Created attachment 3095 [details] Compressed report.bug As shown in the attached report.bug file, dracut is run before the summary is shown, where the "setting PreferredMode" shows 1280x1024 being selected.
Created attachment 3096 [details] dracut.log
Hmm, that's kinda odd overall. I'm not sure why the generate initrd would be different. Can you possibly upload (e.g. to dropbox or somewhere similar both the initrd generate at install and the one generated subsequently? I don't see any more packages being installed after the initrd generation (the original problem I was expecting a reoccurance off actually generates the initrd half way through package installation with predictably horrible results) and thus I'm not sure where the resolution is set in the initrd other than via the kernel command line etc. with the vga= stuff. Being able to compare the two initrds might give some clues. Cheers
Sorry for the delay, had to reinstall to get the initial initrd. https://www.dropbox.com/s/c7hnmw1ptaqdwi1/initrd-3.6.5-server-1.mga3.img.install https://www.dropbox.com/s/5muyofph6u49vnv/initrd-3.6.5-server-1.mga3.img The initrd.*.install is the one created during installation, while the other is from running dracut -f in the installed system.
I should add, with the initrd created from the running system, I do encounter the long delay, while it tries to load the missing radeon-firmware, but, after that, going to/from a console login does work. With the install initrd, I don't get the delay, but the switching doesn't work.
Is it still valid with last isos ?
Reporter please? If no answer in the coming days we will close this bug report
Created attachment 3606 [details] Differences between the two initrds linked to previously. OK, so there are some differences in the initrds: Several kernel modules are not included initially, namely the radeon module and friends (drm+kms helper etc) and all the radeon firmware. Perhaps this sheds some light if there is still a problem but a test with latest isos would be appreciated for sure.
I noticed during testing that the journal appeared to be displayed on tty2/3 while I was trying to log in, and there was a delay before the login prompt appeared. I was into something else at the time and forgot all about it until I saw this so can't provide any details.
Sorry for not responding sooner. The problem is still present in beta 3, Given comment 14, the cause is clear. The installer displays the dialog titled "Preparing boot loader", which is when dracut is being run, just before it asks if I want to use the proprietary driver, so the radeon module is not available when dracut is run. The order of operations in the installer need to be changed. I'd postpone the running of dracut until after the summary, just before the bootloader installation. In beta 3, the tty2 login does work. It's just when switching back to tty1, that the display is black.
Whiteboard: 3alpha3 => 3beta3
Still present in beta 4, however running dracut -f, or adding xdriver=vesa does not fix it. I'm starting to think it's the monitor not providing edid, combined with a graphics card that supports resolutions higher than what the monitor supports.
Whiteboard: 3beta3 => 3beta4
wouldn't/shouldn't the summary reconfigure display rerun dracut?
CC: (none) => alien
that would be a good fix, wouldn't it?
Yeah probably would be a good solution. I'm still cautious about this tho' - e.g. we need to rebuild all initrds as the user may have upgraded their kernel but not yet rebooted, but that's just the way it is... I can only be paranoid for so long before it impacts the user!
@colin, well you can still track this at the summary screen and then decide to do it or not...
@colin: did you rerun dracut at end? or will we not do this?
@AL13N I didn't make any changes in this area sadly :( Must have missed this one on my list :( I guess it's too late to do anything about it now sadly, but will try and take a quick look.
Since I no longer have the monitor that failed to return any edid info, I'm going to close this bug as old.
Status: NEW => RESOLVEDResolution: (none) => OLD