Red Hat Bugzilla – Bug 888946
netinst, installer hangs
Last modified: 2013-04-15 09:14:38 EDT
Since I didn't find these problems reported, I'll list them here.
1. from 3 attempts to install with netinst through wireless connection, only 1 detected install repo. I think that if network is not up fast enough, the "closest mirror" fails and one can't make it try again.
2. if closest mirror fails, one can try setting a http URL. If the url is wrong (e.g. aaa.fff.com or whatever, it doesn't seem to matter), intstaller hangs forever
3. so eventually I selected packages to install, storage to auto-partitioning and clicked on continue. A screen is shown with an option to set root password and at the same time "preparing to install" on the bottom of the screen. Well I set root password (altough the thing complained it is simple). But intall process was just frozen on "preparing to install".
Let me know if I can tell anything more.
Please switch to tty2 and copy all the /tmp/*log files someplace that you can attach them to this bug as individual plain/text files.
sorry, logs are lost already. I think though there was some problem reclaiming space. This morning I started installer again and repeated all steps like I did last 3 attempts.
When I had to configure partitioning I noticed that partitions were modified from last time but not all original partitions were removed. I guess one can replicate by
1. create 3 primary partitions.
1.1. 2 with ext# and one as a lvm phy volume
2. create an extended partition with 2 sub-partitions, both lvm phy volumes
3. I think actually creating a LVM vg spanning over the 3 phy volumes can matter
4. try installing by selecting all partitions for removal
Created attachment 666527 [details]
logs from the problems with source repo
I had to start installting for the fifth time (this time my mistake, power lost). Now I did setup wireless network immediately after network config window showed up. When connected I clicked continue. But source repo was not found. Attaching the logs in a tgz archive. If I hit any of the other bugs again, I'll attach logs for them as well.
Created attachment 666535 [details]
logs from time graphical installer could not start
After so many installation attempts now I got a problem running the installation process. Attaching logs from that attempt. /logs_from_x_failure.tgz/
One more thing I notice is that all parts of setup are very fragile. Now if I setup storage for deleting all partitions and automatic partitioning, and then if I click on storage config again, it behaves crazy. Clicking somewhere blocks every other click as if a background window is on focus. Clicking Esc allows you to click again but the only place that does not block is clicking on done. Where you click and see that storage has problems saving configuration. To recover I went to console, removed all partitions with fdisk and then after a minute or so, the sotrage config screen picked up that drive is empty and clicking ok resulted in success. I still can't click any other button than "done" to work sane (like if I wanted to do partitioning myself).
Storage config is one place that many users mess with, to allow for multi-os boot and such. Being so fragile will produce big pushback IMO if not fixed for GA.
As comment #1 explained, please attach logs as individual files, uncompressed. Doing anything else prevents us from going through and searching bugzilla in the future. Thanks.
how do you want them named to avoid confusion? If you like, please see what files you actually need from the attached tarballs and I can upload them.
Created attachment 696428 [details]
source repo problem - boot.log
Created attachment 696429 [details]
source repo problem - wpa_supplicant.log
Created attachment 696430 [details]
source repo problem - wtmp
Created attachment 696432 [details]
GUI problem - boot.log
Created attachment 696435 [details]
GUI problem - wtmp
Ok, here you go, attached plain text files. I hope you fix these bugs. Today I chatted with a guy on freenode with similar problem trying to install with a proxy. Perhaps if source selection fails once it cannot recover ever again? Fortunately he was able to workaround passing anaconda proxy parameter.
He didn't hit the GUI issue though.
Are those all the logs that were in /tmp? There should've been a storage.log, anaconda.log, program.log, packaging.log, X.log, ifconfig.log
Also, please mark your attachments as "plain text (text/plain)".
I think these were from /var/log so it seems they are useless. But the problem is very easy to reproduce (the install source selection problem). So if you care to fix, then just try it out. I don't have any more time for this as well I don't have a test setup handy.
I am thinking based on comment 12 that the only thing necessary to reproduce is to delay network connectivity for whatever reason. It doesn't have to be wifi.
I think this should be better in F19.