Description of problem: Mageia cauldron sta2 .Net install launched yesterday evening. I let the installation go on all the night (9 hours duration announced) . When i come back this morning, the installation was waiting for root password but the screen was double and very small. However, i succeded in finishing the installation, and Mageia sta2 has rebooted perfectly with a normal display.
hi, i saw this too but "not all the time" :( thierry any idea ? if i reproduce i will take a picture
CC: (none) => mageiaAssignee: bugsquad => mageiatools
I can reproduce with net install too, using VBox (if you needed another confirmation).
Priority: Normal => HighTarget Milestone: --- => Mageia 6
This looks like a duplicate of: https://bugs.mageia.org/show_bug.cgi?id=20354 (Installer graphics die at start of users screen in VBox)
CC: (none) => zen25000
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=20354
(In reply to Barry Jackson from comment #3) > This looks like a duplicate of: > https://bugs.mageia.org/show_bug.cgi?id=20354 > (Installer graphics die at start of users screen in VBox) And there Barry reported updates (incuding kernel updates ) fixed it. @ Daniel Is it fixed for you, too?
CC: (none) => marja11
(In reply to Marja van Waes from comment #4) > (In reply to Barry Jackson from comment #3) > > This looks like a duplicate of: > > https://bugs.mageia.org/show_bug.cgi?id=20354 > > (Installer graphics die at start of users screen in VBox) > > And there Barry reported updates (incuding kernel updates ) fixed it. > > @ Daniel > > Is it fixed for you, too? Hi Marja Yes the bug is fixed, no duplicated or small screen, but i encountered a new problem : At the choice of the monitor , the system has frozen. I wait a moment but no mouse or keyboard responding. I took a "instantané " (Menu/ machine "host T").I stopped the machine. Then i restored it and the installation went on without any problem.
*** Bug 20504 has been marked as a duplicate of this bug. ***
CC: (none) => wilcal.int
@Thomas: any idea why fbdev does this?
CC: (none) => thierry.vignaud, tmb
Priority: High => release_blockerCC: (none) => davidwhodgins
Source RPM: (none) => x11-driver-video-fbdev, kernel
Can it still be reproduced? Comments in bug 20354 (which is apparently related if not a duplicate) hint that it may be fixed now.
Status comment: (none) => Might be fixed already, needs testing on current netinstall
i got it yesterday with prestesting isos
(In reply to Nicolas Lécureuil from comment #9) > i got it yesterday with prestesting isos But what urpmi version do they have?
(In reply to Rémi Verschelde from comment #10) > (In reply to Nicolas Lécureuil from comment #9) > > i got it yesterday with prestesting isos > > But what urpmi version do they have? Nevermind, wrong bug report.
Status comment: Might be fixed already, needs testing on current netinstall => Still valid in current ISOs
This bug is still valid today.
Created attachment 9199 [details] Installer report.bug.xz (from upgrade) Just hit this when doing a mga5 -> mga6 upgrade in VirtualBox, using the Apr 7 Mageia-6-rc-x86_64-DVD.iso. In my case at least, the display corruption occurs when the system switches from using the framebuffer device to the vboxvideo drm device. The key section from the system log (extracted from report.bug) is: <6>[ 215.672960] [drm] Initialized <4>[ 215.688367] vboxguest: loading out-of-tree module taints kernel. <4>[ 215.691310] vgdrvHeartbeatInit: Setting up heartbeat to trigger every 2000 milliseconds <6>[ 215.691411] input: Unspecified device as /devices/pci0000:00/0000:00:04.0/input/input5 <4>[ 215.691510] vboxguest: misc device minor 56, IRQ 20, I/O port d020, MMIO at 00000000f0400000 (size 0x400000) <7>[ 215.691511] vboxguest: Successfully loaded version 5.1.18 (interface 0x00010004) <6>[ 215.694294] [drm] VRAM 01000000 <6>[ 215.694460] [TTM] Zone kernel: Available graphics memory: 2024542 kiB <6>[ 215.694462] [TTM] Initializing pool allocator <6>[ 215.694466] [TTM] Initializing DMA pool allocator <7>[ 215.694648] checking generic (e0000000 1000000) vs hw (e0000000 1000000) <6>[ 215.694650] fb: switching to vboxdrmfb from VESA VGA <6>[ 215.694720] Console: switching to colour dummy device 80x25 <6>[ 215.694788] fbcon: vboxdrmfb (fb0) is primary device <6>[ 215.694907] Console: switching to colour frame buffer device 100x37 <6>[ 215.694920] vboxvideo 0000:00:02.0: fb0: vboxdrmfb frame buffer device <6>[ 215.699951] [drm] Initialized vboxvideo 1.0.0 20130823 for 0000:00:02.0 on minor 0 and from Xorg.0.log: [ 215.569] (II) config/udev: removing GPU device /sys/devices/pci0000:00/0000:00:02.0/drm/card0 /dev/dri/card0 [ 215.569] (II) config/udev: Adding drm device (/dev/dri/card0) [ 215.569] (II) xfree86: Adding drm device (/dev/dri/card0) [ 215.574] (II) LoadModule: "modesetting" [ 215.574] (WW) Warning, couldn't open module modesetting [ 215.574] (II) UnloadModule: "modesetting" [ 215.574] (II) Unloading modesetting [ 215.574] (EE) Failed to load module "modesetting" (module does not exist, 0) [ 215.574] xf86: found device 0
CC: (none) => mageia
Summary: Net installation of Mageia 6 sta2 finished with a very small and double screen. => VirtualBox netinstall ends with display corruptions (when switching to vboxvideo drm device)Source RPM: x11-driver-video-fbdev, kernel => x11-driver-video-fbdev, kernel, virtualbox
Would this issue be related to bug 20354 too?
Remi: 20354, 20368, 20504 are the same bug.
CC: (none) => shybluenight
I can work around this bug by adding 'nomodeset' to the boot command line when booting the installer. Note that 'nomodeset' should not be used when rebooting the installed system, otherwise you'll get bug 20455.
Updating the bug summary as this also affects upgrades using the Mageia 6RC DVD.
Severity: normal => majorSummary: VirtualBox netinstall ends with display corruptions (when switching to vboxvideo drm device) => Installing Mageia 6 in VirtualBox ends with display corruptions (when switching to vboxvideo drm device)CC: (none) => LpSolit
(In reply to Martin Whitaker from comment #16) > I can work around this bug by adding 'nomodeset' to the boot command line > when booting the installer. Martin, is this workaround hard to implement? If not, could we include it in Mageia 6 RC? Because I think most reviewers will test Mageia in a virtual machine, and the review would be pretty negative with such a bug.
(In reply to Frédéric Buclin from comment #18) > (In reply to Martin Whitaker from comment #16) > > I can work around this bug by adding 'nomodeset' to the boot command line > > when booting the installer. > > Martin, is this workaround hard to implement? If not, could we include it in > Mageia 6 RC? Because I think most reviewers will test Mageia in a virtual > machine, and the review would be pretty negative with such a bug. We could try adding 'nomodeset' to the default boot options on the classic installer ISOs - but that might cause problems on real H/W. First I want to try preventing the vboxvideo driver being installed while the installer is running. It ought to be possible to delay this until first boot, as is now done for the proprietary video drivers.
Status comment: Still valid in current ISOs => Proposed solution to prevent using the vboxvideo driver during install, and enable it post-install
Will I see this change when installing with netinstall?
(In reply to William Kenney from comment #20) > Will I see this change when installing with netinstall? Yes, when the fix is pushed. In the meantime you can try the manual workaround of using 'nomodeset' when running the installer.
My original intention of fixing this by not installing the vboxvideo driver doesn't fly, because it is still a pre-built driver. Instead I've fixed it by patching dkms to disable autoload of drivers when being run by the installer. I've tested this fixes this bug, and also tested that it doesn't break the installation of proprietary drivers.
Fixed in dkms-2.0.19-38.mga6. You rock Martin! :)
Status comment: Proposed solution to prevent using the vboxvideo driver during install, and enable it post-install => Fixed by patching dkms to disable autoload of drivers in installerResolution: (none) => FIXEDStatus: NEW => RESOLVED
I confirm that using the latest netinstall (05/08/17), x86_64, Plasma on both hardware and a Vbox client the bug is fixed.