Bug 1223183 - Anaconda took nearly 7 hours to install Fedora 22 in VirtualBox
Summary: Anaconda took nearly 7 hours to install Fedora 22 in VirtualBox
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 25
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: Reopened
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-05-20 03:36 UTC by Ali Akcaagac
Modified: 2017-12-12 10:08 UTC (History)
8 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2017-12-12 10:08:17 UTC


Attachments (Terms of Use)
Fedora 22 Netinstall (146.32 KB, application/x-bzip)
2015-05-23 16:15 UTC, Ali Akcaagac
no flags Details
Debian Jessie Netinstall (3.09 MB, application/x-bzip)
2015-05-23 16:16 UTC, Ali Akcaagac
no flags Details
Fedora 22 Netinstall - Debian Setup (145.95 KB, application/x-bzip)
2015-05-23 20:16 UTC, Ali Akcaagac
no flags Details

Description Ali Akcaagac 2015-05-20 03:36:47 UTC
Yesterday I tested what will become Fedora 22 on a VM (VirtualBox). I downloaded the Beta Version of the Fedora 22 image (Workstation Netinstall) ran through the configuration process and let it run.

The host machine is an E-320 Lenovo with 4 gb ram, 320gb harddrive, E-450 APU. I know not the best machine but I get to the comparison soon.

The VM is set up to use 30 gb of physical hard disk (no image), 128mb of graphics space and 1024mb of ram. The entire setup is - what VirtualBox shows as default for the guest OS (only memory has been increased).

The entire installation process took nearly 7 hours (seven hours). That includes downloading the packages (nearly 1200 packages), installing and running the post installation stuff until the "restart" button pops up on the bottom right of anaconda.

Now I thought this to be a bug and downloaded the TC4 version of The Workstation Netinstall and re-tried the entire process. Same result close to 7 hours.

I know this is all a subjective "measurement" and everything depends on a lot of factors here. Internet connection, harddisk space, speed of host machine etc. but I tried a Debian Jessie Netinstall a couple of days ago (for comparison and testing reasons) with the same VM with similar package set and the entire process (including downloading and installation) took less than 1 hour (one hour) using their graphical installer.

I recall that I tried Fedora 21 on a VM - around half a year ago - on a VM, which took quite long as well.

Nearly 7 hours (Fedora 22) vs less than 1 hour (Debian Jessie) with a similar package set (Workstation, Libreoffice, XFCE, Firefox).

No offense but this is absolutely inacceptable. I would expect a a similar installation time here compared Fedora 22 vs Debian Jessie for a similar package set. I would understand if it might differ by 30 minutes due to a different installer (or process if we call it that way) but having it differ by the factor of 7 is far to high.

Comment 1 Martin Kolman 2015-05-20 08:54:12 UTC
Could you attach the installation logs so that we can check what took so long ? The logs are in /var/log/anaconda after the installation and we would strongly prefer to have them attached to the bug as separate text/plain attachments (as working with log tarballs is cumbersome, also bugzilla does not index tarballs for searching).

Comment 2 Ali Akcaagac 2015-05-20 11:24:42 UTC
This is kind of problematic, because I erased the harddisk after the installation and some tests finished. This was right after I filled in this bug report. All I can offer is, that I am going to re-install Fedora 22 at the weekend and attach the requested logs here.

Comment 3 Martin Kolman 2015-05-21 09:30:40 UTC
(In reply to Ali Akcaagac from comment #2)
> This is kind of problematic, because I erased the harddisk after the
> installation and some tests finished. This was right after I filled in this
> bug report. All I can offer is, that I am going to re-install Fedora 22 at
> the weekend and attach the requested logs here.

Thanks! That should help us pinpoint the issue.

Comment 4 Michal Schmidt 2015-05-21 13:53:37 UTC
It may be specific to running under VirtualBox. Is it possible for you to test with a different kind of virtualization (preferrably KVM)?

Comment 5 Ali Akcaagac 2015-05-21 15:36:36 UTC
(In reply to Michal Schmidt from comment #4)
> It may be specific to running under VirtualBox.

Could be. The Jessie Installation that I was referring here happened a few weeks earlier. During that time a bunch of kernel, kmod and virtualbox updates have shown up. But I still recall similar experiences with Fedora 21 in my mind.

I tried this libvirt stuff with virtual-manager the same day I reported this issue here. But no matter what CPU I have choosen, the result is always a python error with a message saying that the CPU specification can not be parsed. The reason why I have choosen virtual-manager is, because it autodetects and configures the network. QEMU is easier to use for me but sadly applying network to it is a PITA.

The weekend I will retry these steps from scratch:
a) Installing Debian Jessie Netinstall using VirtualBox (I will write down the overall installation time).
b) Installing Fedora 22 (last release candidate) Netinstall using VirtualBox (I will write down the overall installation time).

I will make sure that a) and b) have a similar set of packages. Usually this is XFCE, Libreoffice and Firefox.

I will retry a) and b) (depending on my motivation and the overall time spent) doing the same thing with a FULL iso. Again the times will be written down. I will secure and apply the logs here to this report.

Comment 6 Diego Viola 2015-05-21 17:37:07 UTC
I also experienced a similar problem when upgrading from Fedora 20 to 21 on a slower machine (laptop with 2GB of RAM and 1ghz Celeron CPU IIRC).

I used yum to do the upgrade and the whole upgrade took something like 10 hours.

Comment 7 Diego Viola 2015-05-21 17:42:29 UTC
(In reply to Diego Viola from comment #6)
> I also experienced a similar problem when upgrading from Fedora 20 to 21 on
> a slower machine (laptop with 2GB of RAM and 1ghz Celeron CPU IIRC).
> 
> I used yum to do the upgrade and the whole upgrade took something like 10
> hours.

The problem could have been my internet connection too, which tends to be slow.

However, installing other distros (e.g. Arch Linux) takes usually 20 minutes using the same internet connection.

So I'm pretty confused as to what the problem is.

Comment 8 Ali Akcaagac 2015-05-23 16:14:50 UTC
Preparation for Tests

Fedora-22 ...: https://dl.fedoraproject.org/pub/alt/stage/22_RC1/Workstation/i386/iso/Fedora-Workstation-netinst-i386-22.iso
Debian-8 ....: http://cdimage.debian.org/debian-cd/8.0.0/i386/iso-cd/debian-8.0.0-i386-netinst.iso

* kernel-3.19.8-100.fc20.i686
* kmod-VirtualBox-3.19.8-100.fc20.i686-4.3.28-1.fc20.i686
* VirtualBox-4.3.28-1.fc20.i686

The host system has received the latest updates and was rebooted. The update
contains kernel and kmod updates. The host machine is unhooked from it's place
and is using 54mbit shared WLAN now - rather than 100mbit cable (most likely
it's pulling packages with 18mbit - which is fine). VirtualBox has been
installed and started as root. Default values for 32 bit Fedora has been
chosen. Again a Again a physical hard disk with 320gb has been attached to the
system.





Now installing Fedora-22 Netinstall

Start Time ...: 13:03
Stop Time ....: 16:28

Default values for 32 bit Fedora has been chosen. Fedora got booted from
netinstall iso and default values has been selected (automatic partitioning,
workstation, root password created, user created, go). From booting 13:03 till
this point 13:11. ca. 250mb downloaded now 13:17. No further progress in
downloading has been shown. Instead it skipped over to showing the following
packages installed messages.

-   40/1391 13:32
-   63/1391 13:39
-   87/1391 13:43
-  228/1391 13:50
-  255/1391 13:52
-  347/1391 13:58 stuck here libudisks2 for nearly 40 minutes

1 hour since start passed

-  968/1391 14:42 the next output after 13:58
- 1049/1391 14:52
- 1083/1391 14:57

2 hours since start passed

- 1203/1391 15:07
- 1278/1391 15:19 stuck here gnome-system-monitor for nearly 25 minutes

Post-Installation process started 15:46.

3 hours since start passed

* Post-Installation process still working 16:04
* Post-Installation process still working 16:13
* Post-Installation process still working 16:24
* Initramfs generated 16:25
* Restart shown up 16:28

Nearly 3.5 hrs.





Now installing Debian Jessie Netinstall

Start Time ...: 16:55
Stop Time ....: 17:54

Now the same Stuff with Debian Jessie Netinstall. The entire process for the
installer took 4 minutes. Password and User creation included. This also
includes setting language, keyboard, default formatting of harddisk till the
point where it starts installing the basic core system. Same situation as for
Fedora, VirtualBox uses the default values for debian. No adjustments for
anything has been made. For installation purposes I've selected the graphical
installer.

* Core System installation finished    17:03
* FTP Server selection and network     17:04
* Grabbing and updating Metadata for
  Packages and Preparation             17:07
* Popularity Contest for packages "no" 17:07
* Package selection. GNOME, Printserver, Standard System tools.
* Starting to grab 1550 packages
  (This is slightly more than Fedora (size and packages)) 17:08

-  330/1550 17:10
-  550/1550 17:11
-  850/1550 17:13
- 1000/1550 17:14
- 1250/1550 17:16
- 1550&1550 17:17

From powering on VirtualBox 16:55 till 17:17 for Debian installer to download
all packages. A step had to be redone (installing virtual guest add on) 17:19
it started with the installation of the 1550 packages. The progressbar is
updating so fast, I can't even follow it. Reporting back once "Reboot" pops up.

* Cleanup of the system 17:51
* GRUB Installer        17:52
* Final Configuration   17:53
* Restart shown up      17:54

Nearly 1.0 hrs.





Please find attached two tarballs with the required informations. Sorry I am
not willing to post the files one by one here. If you need this requirement
then please feel free to extract the required file and do so on your own. While
this time the entire installation process only took 3.5 hrs for Fedora and 1.0
hrs for Debian (last time it was around 7 hrs for unknown reasons). The 3.5 hrs
va 1.0 hrs is still too much.

Comment 9 Ali Akcaagac 2015-05-23 16:15:20 UTC
Created attachment 1029063 [details]
Fedora 22 Netinstall

Comment 10 Ali Akcaagac 2015-05-23 16:16:04 UTC
Created attachment 1029064 [details]
Debian Jessie Netinstall

Comment 11 Ali Akcaagac 2015-05-23 20:16:48 UTC
Created attachment 1029107 [details]
Fedora 22 Netinstall - Debian Setup

Start ...: 18:42
Stop ....: 22:10
Changes .: This time I've used the Debian VirtualBox setup to make sure it's using the same parameters that I used when I installed Debian Jessie Netinstall. I will now download the Fedora 22 Workstation version (Full ISO) and install it with QEMU. I expect it to show a similar time for installation. Say 3.5 hrs - 0.5 hrs because I don't need to grab the files over net. So my expectation is something around 3.0 hrs for the installation with QEMU.

Comment 12 Nolaan 2015-06-01 07:41:54 UTC
I have similar problem I guess but using qemu kvm. I'm trying to install Fedora 22 workstation in a VM on my laptop ( core i5 3337u, 4 * 1.8ghz, 4GB ram) and I cannot start the live image, the fan becomes crazy and the laptop heats :(
I did get the F splash screen.
I've notice some dmesg errors from kvm :

...
[15061.988708] kvm [28177]: vcpu0 unhandled rdmsr: 0x639
[15061.988833] kvm [28177]: vcpu0 unhandled rdmsr: 0x641
[15061.988923] kvm [28177]: vcpu0 unhandled rdmsr: 0x619
[15062.095652] kvm [28177]: vcpu0 unhandled rdmsr: 0x611
[15062.095699] kvm [28177]: vcpu0 unhandled rdmsr: 0x639
[15062.095733] kvm [28177]: vcpu0 unhandled rdmsr: 0x641
[15062.095746] kvm [28177]: vcpu0 unhandled rdmsr: 0x619
...

uname -r : 3.19.7-200.fc21.x86_64

Comment 13 Michal Schmidt 2015-06-02 10:53:10 UTC
(In reply to Nolaan from comment #12)
The symptoms you describe suggest you have a different problem than this BZ.

Comment 14 Michal Schmidt 2015-06-02 11:41:58 UTC
I tested on a machine with AMD E2-1800, which should be only slightly faster than your E-450. I have kernel-4.0.4-202.fc21.x86_64, VirtualBox-4.3.28-1.fc21.x86_64.

I can confirm the installation under VirtualBox is painfully slow. The GUI reacts with visible delays.
The slowness is most obvious in the progress hub. Just getting past the preparation step takes minutes (as opposed to a couple of seconds under virt-manager QEMU/KVM). After several minutes I did not have the patience to let it finish mkfs'ing the filesystem (this also takes just a few seconds under QEMU).

Then I tried installing under VirtualBox in text mode (added "inst.text" on the kernel command line). Creating the filesystem there was fast.
It seems that it is VirtualBox's graphics emulation that's very slow.

Anaconda draws a graphical spinner in the progress hub. Let's see if removing the spinner helps:
1. Boot the installer with "init=/bin/sh" added on the kernel command line.
2. Edit the XML for the progress hub:
   vi /usr/share/anaconda/ui/hubs/progress.glade
3. Search for progressSpinner. You'll see something like this:

      <object class="GtkSpinner" id="progressSpinner">
         <property name="visible">True</property>
         <property name="can_focus">False</property>
         <property name="active">True</property>
      </object>

4. Edit the "active" property to False:

      <object class="GtkSpinner" id="progressSpinner">
         <property name="visible">True</property>
         <property name="can_focus">False</property>
         <property name="active">False</property>
      </object>

5. Save & exit the editor.
6. Continue booting into anaconda:
   exec /sbin/init

For me it made a very significant difference.
Could you test it too?

Comment 15 Martin Kolman 2015-06-02 13:29:24 UTC
(In reply to Michal Schmidt from comment #14)
> Then I tried installing under VirtualBox in text mode (added "inst.text" on
> the kernel command line). Creating the filesystem there was fast.
> It seems that it is VirtualBox's graphics emulation that's very slow.
> 
> Anaconda draws a graphical spinner in the progress hub. Let's see if
> removing the spinner helps:
The GTK spinner used by Anaconda is known to be implemented in a very inefficient & CPU intensive manner - this is a known issue tracked in the Gnome bugzilla[0]. Once this is fixed (in GTK) VM installations should be significantly faster.

[0] https://bugzilla.gnome.org/show_bug.cgi?id=732199

Comment 16 Michal Schmidt 2015-06-03 10:01:27 UTC
(In reply to Martin Kolman from comment #15)
> [0] https://bugzilla.gnome.org/show_bug.cgi?id=732199

Thanks. That explains it.

I see Kamil Páral created a tiny update image to use as a workaround (more convenient than what I described in comment #14):
  inst.updates=https://kparal.fedorapeople.org/tmp/no-spinner.img

So it is a GTK+ bug. Unfortunately fixing it is not easy and we should not expect a quick resolution, according to Matthias Clasen:
https://bugzilla.redhat.com/show_bug.cgi?id=1204242#c3

Seeing that the bug affects not just VirtualBox users, but even the Fedora QA efforts, giving up on implementing a workaround in Anaconda (bug 1204242 was closed as WONTFIX) is a mistake, IMO.

Comment 17 Martin Kolman 2015-06-03 10:57:27 UTC
(In reply to Michal Schmidt from comment #16)
> Seeing that the bug affects not just VirtualBox users, but even the Fedora
> QA efforts, giving up on implementing a workaround in Anaconda (bug 1204242
> was closed as WONTFIX) is a mistake, IMO.
Such a huge performance issue affecting *any* application using the GTK spinner should be fixed in GTK, not worked around in every application separately.

Comment 18 Ali Akcaagac 2015-06-03 11:12:17 UTC
(In reply to Martin Kolman from comment #17)
> Such a huge performance issue affecting *any* application using the GTK
> spinner should be fixed in GTK, not worked around in every application
> separately.

I am with you here. Unfortunately if such a huge performance issue is known (and in this case it's known for over one year now), then application developers should avoid using it for the time being. Specially if it affects installation of VirtualMachines in general.

I used to work in a large enterprise company for a couple of years and we are regulary been instructed to use VirtualMachines on our notebooks to set up systems for customers, doing systemintegrations and even development environments. I can assure you that the notebooks are not always the newest brands and usually not best fit with ram, cpu and harddrive space.

Management usually want to see results in a short time (best yesterday). How would you explain, that the distribution you have to set up (because of some specifications set up by the customers) take half a workday to get installed ?

Comment 19 Ali Akcaagac 2015-06-03 11:27:25 UTC
Large company == 100.000 people
Reason for VMs == The notebooks are set up with GIS images from the company. A paid subdivision of the company is hired to create running images for the notebooks so consultants are always set up correctly wherever they go. This is a mandatory rule. Other bigger companies are doing the same iirc. Therefore you can't simple go ahead and make rudimentary changes to the images. So to bypass this issue, you are instructed to set up and work with virtual machines. Once the work or project ends, you can either archive or remove the VM and go on with a new one.

Only a brief explaination for the use case.

At the end of the day I open my electronic work time tracker and enter something like this:

08:00 - 11:30 Installing Fedora on a Virtual Machine
11:30 - 12:00 Lunch
12:00 - 17:00 Setting up customer requirements on the Fedora Virtual Machine

End of the week (once the work tracker has been send via email) my phone rings up and some angry voice is directing a pissed off tone towards my direction because of 08:00 - 11:30.

:)

Comment 20 Fedora End Of Life 2016-07-19 14:10:27 UTC
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 21 Ali Akcaagac 2016-07-19 17:45:55 UTC
Reopened because missing information about actual state.

Comment 22 Michal Schmidt 2017-01-30 13:39:57 UTC
Does the version bump mean you are still seeing the bug with Fedora 25? The upstream GTK+ bug has been marked as fixed since December 2015.

Comment 23 Fedora End Of Life 2017-12-12 10:08:17 UTC
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


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