Bug 21253 - The installer GUI is almost stuck right after starting the "installing" stage
Summary: The installer GUI is almost stuck right after starting the "installing" stage
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: Installer (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
Priority: High critical
Target Milestone: ---
Assignee: Mageia tools maintainers
QA Contact:
URL:
Whiteboard: (MGA6)
Keywords:
Depends on:
Blocks:
 
Reported: 2017-07-16 23:26 CEST by Rostislav Krasny
Modified: 2017-07-25 20:21 CEST (History)
7 users (show)

See Also:
Source RPM: drakx-installer-stage2
CVE:
Status comment:


Attachments
Screenshot (921.43 KB, image/jpeg)
2017-07-16 23:30 CEST, Rostislav Krasny
Details
report.bug.xz per Marja van Waes request (130.07 KB, application/octet-stream)
2017-07-17 21:38 CEST, Rostislav Krasny
Details

Description Rostislav Krasny 2017-07-16 23:26:00 CEST
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:
Comment 1 Rostislav Krasny 2017-07-16 23:30:08 CEST
Created attachment 9496 [details]
Screenshot

The stuck installer GUI screenshot.
Rostislav Krasny 2017-07-16 23:31:39 CEST

CC: (none) => rosti.bsd

Rostislav Krasny 2017-07-16 23:32:13 CEST

Priority: Normal => High

Comment 2 Rostislav Krasny 2017-07-16 23:51:03 CEST
Additional information. Don't know if it matters for this bug but I selected the KDE Plasma desktop type - the default.
Comment 3 Frank Griffin 2017-07-17 14:59:23 CEST
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

Comment 4 Rostislav Krasny 2017-07-17 18:34:58 CEST
(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.
Comment 5 Charles Edwards 2017-07-17 19:42:59 CEST
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

Comment 6 Rostislav Krasny 2017-07-17 20:18:54 CEST
(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?
Comment 7 Marja van Waes 2017-07-17 20:44:23 CEST
@ 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-stage2
Keywords: (none) => NEEDINFO
Whiteboard: (none) => (MGA6)
Version: 6 => Cauldron
CC: (none) => marja11
Assignee: bugsquad => mageiatools

Comment 8 Martin Whitaker 2017-07-17 21:00:56 CEST
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.
Comment 9 Frank Griffin 2017-07-17 21:23:45 CEST
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".
Comment 10 Charles Edwards 2017-07-17 21:33:22 CEST
(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.

Whiteboard: (MGA6) => (none)
Keywords: NEEDINFO => (none)
Version: Cauldron => 6
Assignee: mageiatools => bugsquad
Source RPM: drakx-installer-stage2 => (none)

Comment 11 Rostislav Krasny 2017-07-17 21:38:54 CEST
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.
Comment 12 Rostislav Krasny 2017-07-17 21:46:05 CEST
(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.
Comment 13 Charles Edwards 2017-07-17 21:57:50 CEST
(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/
Comment 14 Rostislav Krasny 2017-07-17 22:06:32 CEST
(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.
Comment 15 Rostislav Krasny 2017-07-17 22:20:04 CEST
(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?
Comment 16 Marja van Waes 2017-07-17 22:51:56 CEST
(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?

Source RPM: (none) => drakx-installer-stage2
Assignee: bugsquad => mageiatools
Whiteboard: (none) => (MGA6)
Version: 6 => Cauldron

Comment 17 Charles Edwards 2017-07-17 23:44:40 CEST
(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
}
Comment 18 katnatek 2017-07-18 00:37:59 CEST
(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

Comment 19 papoteur 2017-07-18 09:06:30 CEST
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

Comment 20 Rostislav Krasny 2017-07-18 16:38:11 CEST
(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.
Comment 21 Florian Hubold 2017-07-25 20:21:59 CEST
(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


Note You need to log in before you can comment on or make changes to this bug.