Description of problem: Attempting a x86_64 UEFI net-install of cauldron in Virtualbox woks OK up to just before the 'users' screen, when the display corrupts to what looks like a black and white TV set with no horizontal hold (assuming readers are old enough to know what that look like!). If this is left alone until drive activity ceases and the vm is powered off, then a re-install using the same configuration but without formatting root jumps straight to the users page and the install completes normally. Version-Release number of selected component (if applicable): How reproducible: Always, also confirmed by David H on IRC in UEFI and non-UEFI mode where the corruption was less severe allowing the screen to be read sufficiently to complete the install. Steps to Reproduce: 1. 2. 3.
I don't have the slightest idea whether this bug should be assigned to virtualbox, to installer or to a kernel or driver :-/ Can you please attach report.bug.xz? (If, because you started again _without_ formatting /root, there's also a report.bug, then please compress & attach that one, too, while mentioning which report.bug* had which time stamp).
CC: (none) => mageiatools, marja11, tmb
I can confirm this bug, in normal non-uefi mode. It happens only when using the netinstall iso in virtualbox, since a while now. No problem with the sta2 live isos. See here a screenshot and more users: https://forums.mageia.org/en/viewtopic.php?f=15&t=11573 Host is Mageia 5, vbox version 5.1.10. It happens at stage2. The distortion of the screen starts for me at a certain point while installing/fetching rpms. Moving the mouse at this point will make it worse. If I just let it go on to the next stages, I can hardly see anything. But I can blindly guess and type away and it completes the install.
CC: (none) => shybluenight
Created attachment 8995 [details] report bug vbox netinstall
When using the old M5 netinstall iso, on a M5 vbox host (version 5.1.10), all is well. No issues. I can recall that this graphics/screen distortion started somewhere in december last year.
Created attachment 8997 [details] report.bug.xz (In reply to Marja van Waes from comment #1) > I don't have the slightest idea whether this bug should be assigned to > virtualbox, to installer or to a kernel or driver :-/ > > Can you please attach report.bug.xz? > (If, because you started again _without_ formatting /root, there's also a > report.bug, then please compress & attach that one, too, while mentioning > which report.bug* had which time stamp). There is only one report* but there are two ddebug.logs and two install.logs. The report.bug.xz attached is timed at the end of the second install :\ It seems to show the same xorg/dbus errors that the other reporter's log shows.
The tail of install1.log does show that all files were installed, but I suspect from the drive activity after the video died that it died shortly before this point: -------snip------- * running: test -e /etc/alternatives/rvi with root /mnt * running: test -e /etc/alternatives/icesh with root /mnt * running: test -e /etc/alternatives/gst-install-plugins-helper with root /mnt * running: update-menus -n with root /mnt * step "installPackages" took: 0:06:21 * step `installPackages' finished This was a minimal LXDE custom install.
Both for Barry and for Chris, there are errors and warnings in the "* Xorg.log" part of report.bug.xz The errors are: [ 55.081] (EE) dbus-core: error connecting to system bus: org.freedesktop.DBus.Error.FileNotFound (Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory) [ 55.087] (EE) Unable to find a valid framebuffer device [ 55.087] (EE) Screen 0 deleted because of no matching config section. [ 55.307] (EE) dbus-core: error connecting to system bus: org.freedesktop.DBus.Error.FileNotFound (Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory) and the last line is repeated many times. I still don't know what to assign this bug report to, though :-(
There is another bug report, same issue: https://bugs.mageia.org/show_bug.cgi?id=20368 The reporter over there does not specify if it's on real hardware. I think -but could be completely wrong- that it's not a virtualbox bug. If people who use sta2 CI or the sta2 live isos don't have this bug, then it should be something specific how the net install isos are being built. Before the two double very small screens appear, the screen goes black for a second.
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=20368
(Assigning to stage2, even if that might be wrong)
Source RPM: (none) => drakx-installer-stage2Assignee: bugsquad => mageiatools
(In reply to Chris B from comment #8) > > If people who use sta2 CI or the sta2 live isos don't have this bug, then it > should be something specific how the net install isos are being built. > That doesn't sound like stage2 is the culprit at all :-/
does it help to add: iommu=relaxed to the kernel command line before you start the install ?
(In reply to Thomas Backlund from comment #11) > does it help to add: > > iommu=relaxed > > to the kernel command line before you start the install ? With that it did not happen, however there was a new kernel since it did, so I will have to test again without it.
(In reply to Barry Jackson from comment #12) > > With that it did not happen, however there was a new kernel since it did, so > I will have to test again without it. Still does not happen, so it seems fixed by updates? [baz@jackodesktop ~]$ rpm -q virtualbox virtualbox-5.1.12-1.mga6 [baz@jackodesktop ~]$ uname -r 4.9.13-desktop-1.mga6 Barry
Created attachment 9007 [details] Updates since it happened Here's what was updated since it last happened just in case it's of use. Barry
(In reply to Marja van Waes from comment #7) > Both for Barry and for Chris, there are errors and warnings in the "* > Xorg.log" part of report.bug.xz Nope, dbus errors (really warnings) are "expected" and will be present in all report.bug.xz for years. Basically Colin make us switch to udev+systemd+dracut in 2013. Then I made us rely on udev for input devices in xorg in installer, thus fixing some bugs & getting more input support (installer now basically behaving in installer like in installed system) But since that we got those warnings. Basically we don't run dbus... I told him so in 2014 and he say he would looking :-)
Source RPM: drakx-installer-stage2 => kernelCC: (none) => thierry.vignaud
(In reply to Barry Jackson from comment #13) > (In reply to Barry Jackson from comment #12) > > > > With that it did not happen, however there was a new kernel since it did, so > > I will have to test again without it. > > Still does not happen, so it seems fixed by updates? > @ Chris Did that fix it for you, too?
Assignee: mageiatools => kernel
Host M5, same vbox version 5.1.10 New netinstall.iso from 28.02.17 Same stage2 file from 25.02.17 (on the server). A very basic install, no DE, no X. Install time less than 2 minutes. It works now, without editing the kernel command line. I'm not sure though if this bug returns when the install time increases. Need to test it.
The bug is back when I select X, thus more packages, and the install time increases. Host M5, same vbox version 5.1.10 New netinstall.iso from 28.02.17 Same stage2 file from 25.02.17 (on the server)
(In reply to Chris B from comment #17) > Host M5, same vbox version 5.1.10 > New netinstall.iso from 28.02.17 > Same stage2 file from 25.02.17 (on the server). > A very basic install, no DE, no X. Install time less than 2 minutes. > > It works now, without editing the kernel command line. I'm not sure though > if this bug returns when the install time increases. Need to test it. (In reply to Chris B from comment #18) > The bug is back when I select X, thus more packages, and the install time > increases. > > Host M5, same vbox version 5.1.10 > New netinstall.iso from 28.02.17 > Same stage2 file from 25.02.17 (on the server) Thanks for your tests, Chris, and for thinking of testing a larger install. With more packages, if you add iommu=relaxed to the kernel command line, do you then still see the bug?
Starting with 'linux iommu=relaxed' doesn't help. As soon as a certain install time is reached, screen goes black for a second, then the two small windows appear, and moving the mouse within the vbox window does more weirdo stuff.
Just to clarify, Chris is using a Mga5 host, I am using Mga6 host. I will re-test with full plasma install, as my previous were LXDE without docs, or workstation stuff.
On a M6 host machine (64bit, but much slower, it's a laptop), fully updated, kernel 4.9.13 desktop, vbox 5.1.14. New netinstall.iso from 28.02.17 Same stage2 file from 25.02.17 (on the server) Still the same bug, after around 4 minutes, black screen in the vbox window, then two small windows etc.
I just did a full default Plasma5 x86_64 UEFI install in VBox with no issues at all. I notice that I am using Mageia-Cauldron-netinstall-nonfree-x86_64.iso which displays Mageia release 6, Oct 18 2016 20:48:15 on boot. I don't really see how that can make a difference once stage1 is running - or can it?
I just repeated another LXDE install alongside the original that gave me the initial problems, using the exact same package choices (in the same vdi) but this time on btrfs, and that too went OK.
I can't believe what just happens. M5 host as above. * I created a new vm, only difference is: now less memory allocated, 2 GB (is that relevant?) * I selected ftp instead of http, and a different mirror. Install went without problems. * Next try. Same VM. Selected http, but with a different mirror. No problems. I don't have any networking or connections problems here. Barry: for me it displays Febr 25 2017 (that's the date of the stage2, not of the boot.iso) May I stop now with testing? Maybe it will magically repair itself ;-)
If I understand comments 23, 24 and 25 correctly, the bug fixed itself? :)
I have not done any installs recently, only upgrades from 5, so my last tests were as above.
The bug appears when I select X. The install time increases. https://spanishdictionary.cc/
CC: (none) => tylerc3q2
Can you try booting with "linux iommu=relaxed"? What are your host OS and your virtualbox version?
Source RPM: kernel => kernel (fb driver)Keywords: (none) => NEEDINFO
CC: (none) => hannahberry071
CC: (none) => identifiedcall
CC: (none) => mageia
Mageia 5 is EOL since Dec 31st 2015. There will not have any further bugfix for this release. You are encouraged to upgrade to Mageia 8 as soon as possible. @reporter, if this bug still apply with Mageia 8, please let us know it. @packager, please check the Mageia 8 package if issue is also present. In this case, please fix the Mageia 8 version instead.
Resolution: (none) => OLDStatus: NEW => RESOLVED