Bug 981358 - anacondo hangs at "installing bootloader"
anacondo hangs at "installing bootloader"
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-04 10:27 EDT by Emmett Culley
Modified: 2013-10-08 13:07 EDT (History)
16 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-08 13:07:11 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
First file written to /root by anaconda (I assume) (1.87 MB, text/plain)
2013-07-04 10:27 EDT, Emmett Culley
no flags Details
Last file written to /root by anaconda (2.01 MB, text/plain)
2013-07-04 10:29 EDT, Emmett Culley
no flags Details
anaconda.log (1.31 KB, text/plain)
2013-07-18 04:58 EDT, Marc Garcia
no flags Details
anaconda.log (11.23 KB, text/plain)
2013-07-18 06:30 EDT, Marc Garcia
no flags Details
ifcfg.log (1.04 KB, text/plain)
2013-07-18 06:30 EDT, Marc Garcia
no flags Details
packaging.log (201 bytes, text/plain)
2013-07-18 06:31 EDT, Marc Garcia
no flags Details
program.log (32.88 KB, text/plain)
2013-07-18 06:31 EDT, Marc Garcia
no flags Details
storage.log (171.65 KB, text/plain)
2013-07-18 06:32 EDT, Marc Garcia
no flags Details
kernel error (5.03 MB, image/jpeg)
2013-07-18 12:45 EDT, Marc Garcia
no flags Details

  None (edit)
Description Emmett Culley 2013-07-04 10:27:32 EDT
Created attachment 768839 [details]
First file written to /root by anaconda (I assume)

Description of problem:
I usually install a new OS into two "new" root and var partitions, leaving home as is.

I skipped Fedora 18 as the new GUI gave me no confidence I could install the new OS as I wanted it.

In this case the current OS (Fedora 17) was installed in /dev/mapper/ws1-root1 as "/", /dev/mapper/ws1-var1 as "/var" and /dev/mapper/ws1-home as "/home".  Prior to installation, I reformatted (ext4) two logical volumes, /dev/mapper/ws1-root as "/" and /dev/mapper/ws1-var as "/var" from the previous OS (Fedora 16) before attempting to install Fedora 19 from an NFS share of the Fedora 19 ISO.  I do not reformat or replace the home volume.

I chose to install KDE and most of the package groups (1722 files).  The installation went along well as far as I know as I didn't stick around to watch, but when I returned to the machine it appeared to be stuck on "something bootloader".  I don't remember if it was "configuring" or "installing" the bootloader.  I noted that the action indicator was not turning, but as I didn't know how long it had been doing that I gave it another hour or so.

In the end I had to physically reset the machine as it ignored the keyboard.  I did that with a bit of trepidation, as I feared my system was not going to reboot.  However it did boot, though into Fedora 17 (yeah), which is the best "failed" installation I ever experienced :-)


Version-Release number of selected component (if applicable):
Fedora 19 release

How reproducible:
Only tried once.

Steps to Reproduce:
1. create or initialize two logical volumes for new OS, from current OS
2. boot from Fedora 19 installition DVD, then use NFS share as source
3. Select to install new OS into new root and var logical volumes and current home (without formating home).

Actual results:
anaconda hangs at "installing bootloader" and hard reset required to restart machine.  When restarted machine boots to previous OS.

Expected results:
Booloader gets installed or updated to allow booting the newly installed OS, and it is properly set up to allow me to select to boot either the new OS or the previous OS.

Additional info:
I found 71 files named anaconda-tb-****** in the /root directory created by the installer, I assume.  I will attach first written here, the add the last written later.
Comment 1 Emmett Culley 2013-07-04 10:29:40 EDT
Created attachment 768840 [details]
Last file written to /root by anaconda
Comment 2 Marc Garcia 2013-07-12 04:38:38 EDT
Same problem here, using the Fedora 19 MATE live cd, and an acer aspire 3810t.

I used automatic partitioning, which created /boot and /boot/efi partitions, and keeping /home (xfs) from previous installation.

Installation hangs at the mentioned point, and laptop failed to shut down by pressing the power switch (for a while), so I had to unplug it and remove the battery.
Comment 3 Marc Garcia 2013-07-15 09:04:38 EDT
I also tried with netinst version, and not keeping the /home partition, using the default installer partitioner. And the same problem occur.

I even recreated the partition table of my hard disk using gdisk, and trying to install with all default settings, and exactly the same thing happen, it works well until the "installing bootloader" part, when the computer stops responding.

I had a Fedora 16 working on that same computer and hard drive, so it looks like a bug in the installer.

Does anyone know what can be wrong? I have no idea on how to fix that, after failing with a clean system and default installation, and I guess more people should be experiencing this same problem.

Thanks
Comment 4 Wolfgang Ulbrich 2013-07-15 09:39:00 EDT
I run also this weekend in this issue with netiso and dvd.
The only way to solve it was to
1. disable bootloader installation in anaconda.
2. boot again the iso and choose rescue an installation.
3. follow the steps and chroot into /mnt/sysimage
4. grub2-install /dev/sda (or another partition where you want to install grub2)
5. grub2-mkconfig -o /boot/grub2/grub.cfg
6. reboot

I had also to set a password for root and user account in rescue mode.
passwd -f <accountName>
Comment 5 Emmett Culley 2013-07-15 23:19:04 EDT
I was able to add an entry to /boot/grub2/grub.cfg pointing to the new installation on /dev/mapper/ws1-root and boot into the new installation.

However there seemed to be some files missing as my KDE desktop (from the previous and unformated home partition), as my desktop was somewhat messed up.  Like the Oxygen theme seemed to be missing.

So I decided to try fedup, and that worked without issue.  Except, as reported elsewhere, it required a hardware reset to start the upgrade.

I probably will not be installing from DVD again anytime soon.
Comment 6 Brian Lane 2013-07-17 20:12:54 EDT
When this happens please switch to tty1 (ctrl-alt-f1) and the shell (ctrl-b 1) and copy the logs from /tmp/ to someplace where you can attach them to this bug as individual text/plain attachments.
Comment 7 Marc Garcia 2013-07-18 04:57:52 EDT
Problem is that the system hangs during installation, and it can't be used anymore, so it's not that easy. But I got the anaconda.log file. Attaching it.
Comment 8 Marc Garcia 2013-07-18 04:58:36 EDT
Created attachment 775203 [details]
anaconda.log
Comment 9 Marc Garcia 2013-07-18 06:28:12 EDT
I add all the logs in /tmp/

The procedure I used to generate them was next:
- Boot with MATE Live CD Image, got these boot messages:
  * Secure boot not enabled
  * kvm: disabled by bios
- Change keyboard layout to Spanish in the live OS, and connect to the wifi
- Create a new GUID table on /dev/sda (target installation disk) using gdisk. Got this message:
  * This option deletes all partitions and creates a new protective MBR.
- Run the installer, selecting /dev/sda as installation target, and all default options (including automatic partitioning)
- Installation installed software, did post-installation tasks, and system hangs (mouse or keyboard events does nothing to the system, pressing power switch does nothing either).

This was done in a Acer Aspire 3810t with a 500gb disk.

Let me know if I can provide further information.
Comment 10 Marc Garcia 2013-07-18 06:30:12 EDT
Created attachment 775245 [details]
anaconda.log
Comment 11 Marc Garcia 2013-07-18 06:30:48 EDT
Created attachment 775246 [details]
ifcfg.log
Comment 12 Marc Garcia 2013-07-18 06:31:17 EDT
Created attachment 775247 [details]
packaging.log
Comment 13 Marc Garcia 2013-07-18 06:31:46 EDT
Created attachment 775248 [details]
program.log
Comment 14 Marc Garcia 2013-07-18 06:32:22 EDT
Created attachment 775249 [details]
storage.log
Comment 15 Marc Garcia 2013-07-18 12:45:59 EDT
Created attachment 775371 [details]
kernel error
Comment 16 Marc Garcia 2013-07-18 12:56:47 EDT
I tried two different things regarding this bug. I installed Fedora 19 without bootloader, and then executed in a rescue terminal "gnome2-install /dev/sda", and also tried to install Fedora 18.

In both cases, I get the error from the previous attached file (the file is indeed for the error in Fedora 18, but in 19 looked exactly the same). Sorry, but I couldn't find a way to get the trace in a file.

Summarizing the trace in the picture:

BUG: unable to handle kernel paging request at [...]
[...]
Pid: 7130, comm: efibootmgr Tainted: G    I 3.6.10-4.fc18.x86_64 #1 Acer Acer Project/Acer Project
[...]
Process efibootmgr (pid: 7130, [...]
Call Trace:
  mls_level_invalid
  mntput
  path_put
  cred_has_capability
  efi_call
  mntput_no_expire
  virt_efi_set_variable
  efivar_create
  write
  vfs_write
  sys_write
  system_call_fastpath
[...]
[sched_delayed] sched: RT throttling activated
Comment 17 Marc Garcia 2013-07-19 04:37:13 EDT
I finally could install normally, converting the disk partition table to MBR (using gdisk), and using the kernel parameters "noefi" and "nogpt" on the installer.
Comment 18 Josh Boyer 2013-09-18 16:28:10 EDT
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs.

Fedora 19 has now been rebased to 3.11.1-200.fc19.  Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.
Comment 19 Josh Boyer 2013-10-08 13:07:11 EDT
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 2 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.

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