Description of problem: After DE is selected and some options for Workstation, Server etc., the classical installer initiates package installation (e.g. from DVD). There's an estimate of the remaining time, but a progress bar can be drawn (possibly because the amount of bytes is know from the outset). Not so with netinstall: the progress bar remains at 0% during all the installation. One bad consequence is that, not knowing that the first time, I aborted an installation because I thought the connection was not working. For netinstalls, BTW, it would be nice to have an indication of the (moving) average transfer speed -- e.g. to encourage users to use mirrors with more bandwidth. I thus request as enhancement that the progress bar work. Version-Release number of selected component (if applicable): Mageia netinstall How reproducible: Always, I suppose. Steps to Reproduce: 1.Download netinstall image. 2.Start netinstallation, enter configs up to start of package download. 3.Observe installation progress bar remain at 0%. PS: Not the object of the request, but it would be highly efficient to prompt the user to provide a big enough usb drive (say, 4+ GB) to cache downloaded packages. It would easy the load on mirrors and probably make installations faster for people with slow connections.
It would ease (not "easy") the load on mirrors...
Summary: On netinstall, progress bar is not available when installing packages. => On Mga6 netinstall, progress bar is not available when installing packages.
Just tried netinstall with Mageia 5.1 and the progress bar worked perfectly. Maybe I try to Mageia 6 netinstall again to confirm if the issue is reproducible (in other words, a regression).
(In reply to Renato Dali from comment #2) > Just tried netinstall with Mageia 5.1 and the progress bar worked perfectly. > > Maybe I try to Mageia 6 netinstall again to confirm if the issue is > reproducible (in other words, a regression). Thierry mentioned in a recent commit that the progress bar misbehaves, and one of the QA testers confirmed it.
CC: (none) => marja11Assignee: bugsquad => mageiatoolsSource RPM: (none) => drakx-installer-stage2Keywords: (none) => 6sta2
(changing severity to normal, because this is a regression and not an enhancement request)
Severity: enhancement => normal
(In reply to Marja van Waes from comment #3) > Thierry mentioned in a recent commit that the progress bar misbehaves, and > one of the QA testers confirmed it. Yeah this is because of fix for bug #19895
CC: (none) => thierry.vignaudDepends on: (none) => 19895
(In reply to Thierry Vignaud from comment #5) > > Yeah this is because of fix for bug #19895 As you probably noticed, this bug report was opened at 2016-12-12 02:57:18 CET before the 3 last commits for that bug were pushed. Only this one was already pushed: http://gitweb.mageia.org/software/drakx/commit/?id=08d23a39f5ff5bdfe736190b1088dc534e5b1bb9
Summary: On Mga6 netinstall, progress bar is not available when installing packages. => On Mga6 netinstall, progress bar is not available when installing packages, (at least since DrakX v17.64)
And it could way be the culprit
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=19933
commit d6b9de2d5c0d748a35287dae11950afbdb848b55 Author: Pascal Terjan <pterjan@...> Date: Tue Dec 13 23:49:20 2016 +0000 17.66 (should fix mga#19933 and mga#19930) --- Commit Link: http://gitweb.mageia.org/software/drakx/commit/?id=d6b9de2d5c0d748a35287dae11950afbdb848b55 Bug links: Mageia https://bugs.mageia.org/19933 https://bugs.mageia.org/19930
The problem is that $ratio is now an int64 so it can be only 0 or 1.
CC: (none) => pterjan
Yeah we've revert parts of the int64() calls. Which shows the issue is that the division of int64 returns an int64 which converts progress_total from its intial value of "scalar ref to 0" to "ref to Int64 resulting from div)...
See eg: $ perl -e 'use Math::Int64 "int64"; $a =int64(32); $b=int64(128); warn $a/$b' 0 at -e line 1. $Â perl -e 'use Math::Int64 ":native_if_available", "int64"; $a =int64(32); $b=int64(128); warn $a/$b' 0.25 at -e line 1.
int64_to_number() does the trick
But the ratio is absurd because it returns strings for big numbers...
I think size2time is used only for that ratio so we should be able to rewrite totally a size2time_ratio taking int64s and returning a (normal) number
I regret having listening guibo for fixing that small issue of bogus sizes printed on i586 for big packages :-( I think I'll patch Math::Int64 in order to provide int64_to_float() or we'll just make drakx uses sg like: sub int64_to_float { sprintf("%.2f", $_[0])*1 }
(In reply to Pascal Terjan from comment #14) Yeah it's the only user of size2time() in all our code
It works...
Created attachment 8776 [details] (size2time) enforce returning a float (mga#19930)
Created attachment 8777 [details] revert forcing $progress_total & $ratio to be int64
commit 1b0aaf551631c1f9c997100b61d674abf7aead75 Author: Thierry Vignaud <thierry.vignaud@...> Date: Wed Dec 14 16:42:04 2016 +0100 revert forcing $progress_total & $ratio to be int64 it's bogus as then, when not using native int64 (eg: i586), the ratio cannot be a float between 0 & 1 and thus the progress bar can never be updated (mga#19930) --- Commit Link: http://gitweb.mageia.org/software/drakx/commit/?id=1b0aaf551631c1f9c997100b61d674abf7aead75
commit 50edb3c63a62c3b842f483588bdde8deb8a4fc84 Author: Thierry Vignaud <thierry.vignaud@...> Date: Wed Dec 14 16:41:26 2016 +0100 (size2time) enforce returning a float (mga#19930) with the previous fix, the progress bar will now properly update on i586 will be a float between 0 & 1 --- Commit Link: http://gitweb.mageia.org/software/drakx/commit/?id=50edb3c63a62c3b842f483588bdde8deb8a4fc84
Fixed
Status: NEW => RESOLVEDResolution: (none) => FIXED
Sorry but I have to reopen. There is no visible difference in i586 install using drakx-installer-stage2-17.68 * getFile install/stage2/VERSION on http://mirrors.kernel.org/mageia/distrib/cauldron/i586 * retrieving VERSION * '/usr/bin/curl' '-q' '--location-trusted' '-R' '-f' '--disable-epsv' '--connect-timeout' '60' '--anyauth' '-s' '--stderr' '-' '-O' 'http://mirrors.kernel.org/mageia/distrib/cauldron/i586/install/stage2/VERSION' * retrieved VERSION * second stage install running (DrakX v17.68) On this install the 'Time remaining' switched back and forth between 16:48 and 10 sec. For a brief period every time TR showed 10 sec the 'Progress bar' would be fully populated, at All others it remained empty.
Status: RESOLVED => REOPENEDCC: (none) => caeResolution: FIXED => (none)
In a dvd.iso install both 'Time remaining' and 'Progress bar' are reasonably accurate through out the install. It is only during boot.iso installs that the values are bad.
What is the drakx version used on the dvd?
(In reply to Pascal Terjan from comment #25) > What is the drakx version used on the dvd? 17.68 is used
(In reply to Pascal Terjan from comment #25) > What is the drakx version used on the dvd? 17.68 is used on the dvd.
Pardon my ignorance, but these estimates are based on average transfer rates, right? Because instantaneous network rates would bring trouble... Because that is what would cause a big difference between a more-or-less steady rate device like a DVD and the totally unpredictable internet, paired with HTTP, known for quite meaningful speed variations -- not to mention ISP/mirror shaping policies... That reminds me of something... https://xkcd.com/612/ :-)
Reinstalled Mageia 6 netinstall. There was an error in the script to install Flashplayer-plugin... maybe that's related to the new version. Or not. The problem still persists. 0% all the time. As it was said that stage2 comes from the server, are we really testing the fixed version. Shouldn't we choose a specific server or are all mirrors already in sync? (I'm using http, BTW)
(In reply to Renato Dali from comment #29) > > As it was said that stage2 comes from the server, are we really testing the > fixed version. Shouldn't we choose a specific server or are all mirrors > already in sync? (I'm using http, BTW) After installing and rebooting into the new install, run as root: xzcat /root/drakx/report.bug.xz | grep DrakX If you have the correct stage2 version, you'll see: * second stage install running (DrakX v17.68)
http://mageia.c3sl.ufpr.br/distrib/cauldron/i586/install/stage2/ looks good, btw
Created attachment 8797 [details] Screenshot of the package install screen I just tried an i586 netinstall in qemu, using ftp.free.fr, and it worked well, here is a screenshot in the middle but it progressed in the right direction.
(In reply to Renato Dali from comment #28) > Pardon my ignorance, but these estimates are based on average transfer > rates, right? Because instantaneous network rates would bring trouble... It is based on the number of bytes to install in total and how many have been installed so far, so it should approximate the average download + write to disk speed
Closing again, it is *fixed*
Status: REOPENED => RESOLVEDResolution: (none) => FIXED
@ Marja OK, it is the right version (17.68). @Pascal Pascal, I think we're not on the same page. I mean, literally, as I've been using the "text" image instead of the graphical one (it's a 512MB RAM netbook). Don't know whether this makes any difference (it shouldn't, I suppose), but the fact is that it stays at 0% during the whole package download & install. @ Thierry I suppose this is minor anyway, after all the installation works -- so at least it's a WORKSFORME. But some people (like me) could be fooled into thinking it's not working and that would cause lost time and stress to mirrors...
Ah right, parts of the fixes were in gtk interface so it is likely the text version also has some problems but text had not been mentioned previously
Curses::UI does things like: # Compute percentage my $perc = ($this->{-pos}-$this->{-min}) /($this->{-max}-$this->{-min})*100; And we are now giving int64 for -pos and -max so yes that will be 0, we should transform the values before passing them on
We'd better open a new/separate bug for the text version, this one is already too long
(In reply to Thierry Vignaud from comment #38) > We'd better open a new/separate bug for the text version, this one is > already too long Done, see bug 19973
Marja/Pascal/Thierry, thanks for answering and I'm sorry I didn't say anything about text. I try to avoid losing important details -- and it happens anyway.