I've encountered a boot hang using both: Mageia-4-alpha1-LiveCD-KDE4-en-i586-CD and Mageia-4-alpha1-LiveCD-GNOME-en-i586-CD when testing as a VirtualBox Client. I do not have the same hang using: Mageia-4-alpha1-LiveDVD-GNOME-x86_64-DVD or Mageia-4-alpha1-LiveDVD-KDE4-x86_64-DVD A screen capture of the hang point is attached to this Bug report. Using the same iso on a USB drive and on real hardware boots, and installs, just fine. Reproducible: Steps to Reproduce:
Whiteboard: (none) => 4alpha1
Created attachment 4246 [details] M4A1 Boot hang in Vbox client
Created attachment 4254 [details] without the splash sceen any way to have more info (as it does'nt go to rescue mode)
CC: (none) => mageia, sysadmin-bugs, tmbComponent: Installer => Release (media or process)Summary: M4A1 Boot hang in Vbox client => Live i586, hang at boot in virtualboxSource RPM: TBD => (none)
Run level 1 (aka rescue mode) does work. Run level 3 is also working, though you have to switch to tty2 (host+f2), to get a login screen, after the line with "Permit user sessions" is shown. After logging in as live, trying startx locks it up after Loading extensions GLX. Booting to run level 3, logging in as root, and using XFdrake to switch from the VirtualBox video driver to Xorg/Vesa and then running "systemctl start dm.service" does start kde as the live user. So it looks like the problem with the i586 vboxvideo_drv.so module.
CC: (none) => davidwhodgins
Using the kernel option xdriver=vesa also works.
Created attachment 4256 [details] Xorg.0.log (compressed)
Created attachment 4257 [details] Output of strace startx (compressed) Not sure how to run xinit under gdb. startx hangs quickly enough, can't switch to another console to use gdb to attach to the running process. The strace shows that there is a segfault.
(In reply to Dave Hodgins from comment #3) > Run level 1 (aka rescue mode) does work. Run level 3 is also working, > though you have to switch to tty2 (host+f2), to get a login screen, > after the line with "Permit user sessions" is shown. FWIW, The lack of a tty1 getty on multi-user.target (aka RL3) should be solved now after fixing bug #10931.
bug fixed with new isos, according to Thomas mail on @qa-discuss it was x11 thanks
Status: NEW => RESOLVEDResolution: (none) => FIXEDSource RPM: (none) => x11-server
(In reply to Manuel Hiebel from comment #8) > bug fixed with new isos, according to Thomas mail on @qa-discuss it was x11 Work'n through'em now. Looks good all the way around. Reports in: http://bn.parinux.org/p/mageia4alpha1