Red Hat Bugzilla – Bug 1264943
Anaconda hangs at package installation
Last modified: 2015-10-21 09:54:13 EDT
Created attachment 1075544 [details]
Configuration screen at hang
Description of problem:
I was doing a network install of 'Fedora Workstation', to a UEFI machine, over an existing set of standard partitions which currently hold F20 using the iso, Fedora-Workstation-netinst-x86_64-22.iso.
The process proceeded smoothly, through to the 'Configuration' screen, with all 1926 packages selected downloaded to dnf.package.cache on the home partition.
Unfortunately, the process did not proceed any further.
The GUI was still active. The activity indicator was spinning and I could press the 'Help' button and invoke yelp. I could also switch to a root shell prompt and back to the GUI.
I have uploaded a screenshot of the GUI at this point.
The partitions sda10 (/boot), sda12 (/), sda14 (/var) and sda16 (/tmp) have been reformatted.
boot dev etc home lost+found mnt opt proc root run sys tmp var
crypttab fstab mtab resolv.conf
with fstab correctly filled out
The other directories on sda12 are empty.
The partitions sda11 (/mnt/distro), sda15 (/opt) and sda17 (/home) have been left untouched, as intended, with the exception of the packages being written to /home/dnf.package.cache.
I saved /tmp of the installer, which contains:
anaconda.log dnf.rpm.log packaging.log storage.state
anaconda-screenshots hawkey.log program.log syslog
dnf.cache ifcfg.log sensitive-info.log tmux-0
dnf.log libuser.FJf09c storage.log X.log
and have uploaded the log files
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Please attach the log files /tmp at the time of the hang.
Created attachment 1075545 [details]
Created attachment 1075546 [details]
Created attachment 1075547 [details]
Created attachment 1075548 [details]
Created attachment 1075549 [details]
Created attachment 1075550 [details]
Created attachment 1075551 [details]
Created attachment 1075552 [details]
Created attachment 1075553 [details]
Created attachment 1075554 [details]
As far as anaconda can tell dnf is still downloading packages, so moving to dnf.
I reran the installation making the same selections as the original. The downloaded packages were found, and not downloaded again, and the package installation proceeded. Then the following error appeared:
The following error occurred while installing the boot loader.
The system will not be bootable.
Would you like to ignore this and continue with installation?
failed to remove old efi boot entry. This is most likely a kernel or firmware bug.
I took a screenshot of this and saved /tmp. I can upload the screenshot and log files of this run, if that would be usefull.
After examining the log files in the root shell, I selected 'Yes' and continued with the installation. Contrary to the warning, this resulted in a successful and bootable installation.
(In reply to Keith Dixon from comment #13)
> I took a screenshot of this and saved /tmp. I can upload the screenshot and
> log files of this run, if that would be usefull.
Yes, please do. The logs in particular, the screenshot isn't necessary.
Created attachment 1075853 [details]
Created attachment 1075854 [details]
Created attachment 1075855 [details]
Created attachment 1075856 [details]
Created attachment 1075857 [details]
Created attachment 1075858 [details]
Created attachment 1075859 [details]
Created attachment 1075860 [details]
Created attachment 1075861 [details]
Created attachment 1075862 [details]
Seems like connection issue. Can you attach dnf.librepo.log, please?
I do not have dnf.librepo.log from the two runs of the installer so I presume you mean /var/log/dnf.librepo.log from the installed system. I am uploading two such files, dnf.librepo.log and dnf.librepo.log-20150927
Created attachment 1078639 [details]
Created attachment 1078640 [details]
Unfortunately, we need those logs from installer run. If you are not able to provide a reproducer or logs, we will have to close your report as insufficient_data.
I suspect that the hang is an intermittent problem, possibly a race condition, and might be difficult to reproduce.
I fired up the installer. At the 'Installation Summary' hub, after the package and group metadata have been downloaded, there is no /var/log/dnf.librepo.log. I presume it is created at a later time when the packages are downloaded.
I refer to:
May I suggest that dnf.librepo.log is put in /tmp for the Fedora 23 installer. I was unaware of its existence, The documentation states that the log files are in /tmp so I did not think to search the whole filesystem for things that might be log files.
I am happy to have the bug closed as insufficient_data
(In reply to Keith Dixon from comment #30)
> May I suggest that dnf.librepo.log is put in /tmp for the Fedora 23
> installer. I was unaware of its existence, The documentation states that the
> log files are in /tmp so I did not think to search the whole filesystem for
> things that might be log files.
If it is being created it should be in /tmp/, anaconda redirects all the dnf logging to /tmp/ when it configures it.
I listed the contents of /tmp, at the time of the hang, in my original post.
In comment 13, I saved /tmp of the second run of the installer at the boot loader installation error. The contents were the same as the original run.
In comment 30, when I tried the installer again, the contents were the same. There is also no dnf.librepo.log in /var/log/anaconda of the installed system.
It would appear that it is not being created. Perhaps this is diagnostic or a bug in itself.
We have insufficient data to solve problem. We need dnf.librepo.log that Anaconda support can probably provide.