Description of problem: I tried to install Mageia 6 using Mageia-6-netinstall-nonfree-x86_64.iso flashed on a disk on key by rufus. The installer GUI is almost stuck right after the "installing" stage is started to work. After a few minutes it got free for a few seconds and than it's stuck again untill the next free-stuck loop iteration. If I go to consoles (Ctrl+Alt+F1/F3) I can see that the installation actually works and the RPMs are downloaded. If I go back to the installer GUI (Ctrl+Alt+F7) I usually see a previous console window. If I move the mouse I see parts of the stuck installer GUI apper on the screen. I will upload a picture that shows this "painting". It looks there is some GUI refresh bug related to the "installing" stage of the installation. Version-Release number of selected component (if applicable): How reproducible: Just try to install Mageia6 64bit (using Mageia-6-netinstall-nonfree-x86_64.iso flashed into a disk on key by rufus) on i7 4790 based machine with internal Intel HD 4600 video controller. Steps to Reproduce:
Created attachment 9496 [details] Screenshot The stuck installer GUI screenshot.
CC: (none) => rosti.bsd
Priority: Normal => High
Additional information. Don't know if it matters for this bug but I selected the KDE Plasma desktop type - the default.
This is what I would expect on a slow machine. The system, at the start of installing, is doing CPU-intensive stuff which is going to make repainting the screen spotty and slow. By switching to tty3 and back you forced the entire screen to repaint. Moving the mouse initiates GUI events that cause portions of the screen to repaint. Try clicking "Details" on the install screen (it will not seem to have an effect, but it does). Then just wait. After a while it will start to list the RPMs that are being installed. But it takes a while for the RPMs to start to list.
CC: (none) => ftg
(In reply to Frank Griffin from comment #3) > This is what I would expect on a slow machine. The system, at the start of > installing, is doing CPU-intensive stuff which is going to make repainting > the screen spotty and slow. But my machine isn't slow, at least not for this. It is an Intel i7 4790 (Haswell) 3.6 GHz CPU with 16 GB RAM and SSD hard disk. > Try clicking "Details" on the install screen (it will not seem to have an > effect, but it does). Then just wait. After a while it will start to list > the RPMs that are being installed. But it takes a while for the RPMs to > start to list. This is what I started from. I realized the installer GUI is stuck after I clicked on the "Details" button and nothing happened immediatly. The tty-s switching and mouse moves after switched back were done later. If I press to the "Details" button and wait it open the details window and start printing the RPMs progress. But it does it by the same "stuck minutes / not stuck seconds" loop. This is definitly a bug and I think it's critical.
It may be disconcerting to see and could be improved but this not what I would consider to be a bug but more of an enhancement request. At the inception of the installation screen it is still necessary for the installer to determine the order in which the rpms should be installed and to then group the rpms into transactions of 50. This can take from several seconds to several minutes during which the screen will not be redrawn. After the installation of rpms begins all the rpms within a transaction must be downloaded before any are installed and the gui will not be redrawn or active while these rpms are being downloaded. This will occur with every transaction. When you switch TTYs and then back to the GUI you can get a black or corrupted screen. The screen will be redrawn|active only when the rpms within the current transaction are being installed. The screen can manually be redrawn using the mouse|cursor.
CC: (none) => cae
(In reply to Charles Edwards from comment #5) > It may be disconcerting to see and could be improved but this not what I > would consider to be a bug but more of an enhancement request. I strongly disagree with you. Just think about a regular user reaction to a stuck Installer GUI when he/she tries Mageia for the first time. This user will not wait too long or investigate this behavior but will throw the installation media into a garbage bin almost instantly. > At the inception of the installation screen it is still necessary for the > installer to determine the order in which the rpms should be installed and > to then group the rpms into transactions of 50. > This can take from several seconds to several minutes during which the > screen will not be redrawn. > > After the installation of rpms begins all the rpms within a transaction must > be downloaded before any are installed and the gui will not be redrawn or > active while these rpms are being downloaded. > This will occur with every transaction. Why I don't remember such a regression in Mageia 5, that I had tried on a much older and slower machine? BTW I see you're the Mageia QA team member. Is this bug reproducable on your machine(s) as well? I mean is it general or does it relate to a specific hardware?
@ Rostislav Thanks for you report. Can you please reproduce this issue and then switch to tty2 with, as you already know, Ctrl+Alt+F2, insert a USB key and then type: bug that will put report.bug on the USB key. Please attach that file to this bug report. If it is too large to attach, then run xz report.bug and attach report.bug.xz Setting Version: to cauldron, because we cannot fix already released isos. Putting (MGA6) on the Whiteboard:, to show the problem was last seen in a Mageia 6 iso.
Source RPM: (none) => drakx-installer-stage2CC: (none) => marja11Version: 6 => CauldronKeywords: (none) => NEEDINFOWhiteboard: (none) => (MGA6)Assignee: bugsquad => mageiatools
Try selecting a different mirror. If the mirror site you are using is overloaded, the installer will spend a much higher proportion of its time waiting for network transactions to complete, and will only rarely get round to refreshing the screen.
Good catch, Martin. I do all my network installs from my local intranet mirror, so even though I see moderate delays, I wouldn't see the type of delays described using a true network source. There's already a "Please wait" for checking installed packages. Maybe whatever is interacting with the mirror before starting actual installation should be included in that, but if delays are going to be encountered for each 50-package download, that should probably have its own "Please wait".
(In reply to Rostislav Krasny from comment #6) > > Why I don't remember such a regression in Mageia 5, that I had tried on a > much older and slower machine? Mga5 used a transaction size of only 8 and Mga6 uses 50. There will be less transactions for Mga6 but each can take 4x longer than they would in Mga5. The speed of your connection as well as traffic and available bandwidth from the mirror chosen for the install can also radically affect the time needed for each transactions. > BTW I see you're the Mageia QA team member. Is this bug reproducable on your > machine(s) as well? I mean is it general or does it relate to a specific > hardware? This can occur on any Mga6 installation if switching TTYs but most "regular' users or "newbies" will stay on the GUI and not see it. Personally on 99.9% of the installs|test I do when it reaches the pkg installation screen I will leave the computer to do something else and only come back to it when it reaches the password|configuration stage.
Version: Cauldron => 6Whiteboard: (MGA6) => (none)Source RPM: drakx-installer-stage2 => (none)Assignee: mageiatools => bugsquadKeywords: NEEDINFO => (none)
Created attachment 9499 [details] report.bug.xz per Marja van Waes request @ Marja van Waes Attaching. This time the semi-stuck behavior of the Installer GUI was different. After switching from a console back to the GUI (Ctrl+Alt+F7) I saw a black screen and mouse moves didn't repaint part of the GUI screen, although the mouse pointer itself shown properly. The GUI screen then refreshed as in the previous try after a few minutes. Also this time I selected the first German mirror instead of the first Greece mirror I selected previously. Don't think it has any influence, maybe it's a little bit faster. I didn't find any local Israeli mirror anyway.
(In reply to Martin Whitaker from comment #8) > Try selecting a different mirror. I don't know about any local Mageia mirror. Maybe the best workaround would be using the full installation media instead of the network install.
(In reply to Rostislav Krasny from comment #12) > (In reply to Martin Whitaker from comment #8) > > Try selecting a different mirror. > > I don't know about any local Mageia mirror. Maybe the best workaround would > be using the full installation media instead of the network install. http://mirrors.mageia.org/mirrors/ftp.cc.uoc.gr and it has bandwidth of 1Gbits Full listing of mirrors can be found here http://mirrors.mageia.org/
(In reply to Charles Edwards from comment #10) > Mga5 used a transaction size of only 8 and Mga6 uses 50. Ok. It looks like the Installer GUI doesn't have a separate thread for refreshing or this thread is blocked most of the time by the RPMs processing. > > BTW I see you're the Mageia QA team member. Is this bug reproducable on your > > machine(s) as well? I mean is it general or does it relate to a specific > > hardware? > > This can occur on any Mga6 installation if switching TTYs but most "regular' > users or "newbies" will stay on the GUI and not see it. But the GUI will be almost stuck from the beginning of the RPMs processing even if you don't switch TTYs. I mean it will look stuck after pressing on any of the three buttons there: "Rlease Notes", "Cancel", "Details". This is a bad user experience. > Personally on 99.9% of the installs|test I do when it reaches the pkg > installation screen I will leave the computer to do something else and only > come back to it when it reaches the password|configuration stage. I think most users make sure the pkg installation is running before they leave the computer. I mean they make sure the estimate time is changing and/or there is some life in the details window that can be opened. If it looks stuck from the beginning they would start worrying about what is going on.
(In reply to Marja van Waes from comment #7) > Setting Version: to cauldron, because we cannot fix already released isos. > Putting (MGA6) on the Whiteboard:, to show the problem was last seen in a > Mageia 6 iso. Someone has changed all these fields back, probably by a mistake. Take a look at History. BTW I've noticed the boot screen of the installation media shows "Mageia 6 (Cauldron)". Why it's still Cauldron? Is it another (this time minor) bug?
(In reply to Rostislav Krasny from comment #15) > (In reply to Marja van Waes from comment #7) > > > Setting Version: to cauldron, because we cannot fix already released isos. > > Putting (MGA6) on the Whiteboard:, to show the problem was last seen in a > > Mageia 6 iso. > > Someone has changed all these fields back, probably by a mistake. Take a > look at History. Thanks, fixed it. > > BTW I've noticed the boot screen of the installation media shows "Mageia 6 > (Cauldron)". Why it's still Cauldron? Is it another (this time minor) bug? I thought that was fixed... oh, maybe it was only fixed in the Classical isos, but not in the netinstall isos?
Whiteboard: (none) => (MGA6)Assignee: bugsquad => mageiatoolsSource RPM: (none) => drakx-installer-stage2Version: 6 => Cauldron
(In reply to Marja van Waes from comment #16) > (In reply to Rostislav Krasny from comment #15) > > BTW I've noticed the boot screen of the installation media shows "Mageia 6 > > (Cauldron)". Why it's still Cauldron? Is it another (this time minor) bug? > > I thought that was fixed... oh, maybe it was only fixed in the Classical > isos, but not in the netinstall isos? Stage 1 was not updated /drakx/images/grub2.config is still using menuentry 'Start Mageia 6 (Cauldron) Install' { linux /isolinux/x86_64/vmlinuz audit=0 quiet noiswmd initrd /isolinux/x86_64/all.rdz } menuentry 'Start Mageia 6 (Cauldron) Rescue' { linux /isolinux/x86_64/vmlinuz audit=0 noiswmd rescue initrd /isolinux/x86_64/all.rdz }
(In reply to Rostislav Krasny from comment #0) In my experience rufus don't make a good bootable usb with mageia, try with other https://wiki.mageia.org/en/Dump_Mageia_ISO_on_a_USB_flash_drive_-_Alternative_tools
CC: (none) => j.alberto.vc
We have today a recommendation for Rufus, using "ISO image" option in the page you point to. If this is not valid, please edit the wiki. We have also another place where we recommend it: https://wiki.mageia.org/en/Mageia_in_dual_boot_with_Windows8_and_over#Creation_of_the_bootable_DVD_or_USB_stick
CC: (none) => yves.brungard_mageia
(In reply to katnatek from comment #18) > (In reply to Rostislav Krasny from comment #0) > > In my experience rufus don't make a good bootable usb with mageia, try with > other > https://wiki.mageia.org/en/Dump_Mageia_ISO_on_a_USB_flash_drive_- > _Alternative_tools Maybe but in my case I don't see any issue related to the ISO flashing (no boot problem, no "file not found" error message in the console) that can have any influence to the Installer. The RPMs are also installed from network and not from the USB drive.
(In reply to katnatek from comment #18) > (In reply to Rostislav Krasny from comment #0) > > In my experience rufus don't make a good bootable usb with mageia, try with > other > https://wiki.mageia.org/en/Dump_Mageia_ISO_on_a_USB_flash_drive_- > _Alternative_tools (In reply to papoteur from comment #19) > We have today a recommendation for Rufus, using "ISO image" option in the > page you point to. > If this is not valid, please edit the wiki. I've corrected that, it should have never recommended ISO image in the first place. When using DD method it works just fine.
CC: (none) => doktor5000
Does this bug exist in the recently released Mageia 6.1 or it's fixed now?
(In reply to Rostislav Krasny from comment #22) > Does this bug exist in the recently released Mageia 6.1 or it's fixed now? Mageia 6.1 is just Mageia 6 with all updates applied. Fixing this would require a major change to the installer. (I don't see the screen being redrawn when I move the mouse. It just stays black until the current download finishes, and then gets redrawn all at once)
CC: (none) => mageia