Created attachment 517561 [details] gzipped tar file containing: anaconda traceback, anaconda.log and abrt.log Description of problem: I booted the F16/alpha/rc2/live cd (x86_64, selinux=0) and tried to "install to harddisk". Selecting "custom install" to an existing extended ext4 partition which should to be overwritten: crash! Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
When you hit a traceback, there's really no need to do anything besides attach /tmp/anaconda-tb-* as a text file to this bug. By attaching things as tarballs, you are making it more difficult for us to search attachments in the future and that's something I do pretty much all the time.
Created attachment 517617 [details] traceback anaconda 16.14.3 exception report Traceback (most recent call first): File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 418, in doIt ped_partition.set_name(dev.format.name) File "/usr/lib64/python2.7/site-packages/pyanaconda/packages.py", line 122, in turnOnFilesystems anaconda.storage.doIt() File "/usr/lib64/python2.7/site-packages/pyanaconda/dispatch.py", line 348, in dispatch self.dir = self.steps[self.step].target(self.anaconda) File "/usr/lib64/python2.7/site-packages/pyanaconda/dispatch.py", line 235, in go_forward self.dispatch() File "/usr/lib64/python2.7/site-packages/pyanaconda/gui.py", line 1198, in nextClicked self.anaconda.dispatch.go_forward() PartitionException: msdos disk labels do not support partition names.
Created attachment 517649 [details] anaconda.log
Created attachment 517650 [details] ifcfg.log
Created attachment 517651 [details] programlog
Created attachment 517652 [details] storage.log
same problem with the f16-alpha-rc3-install (not live!!) dvd. See attachments anaconda.log, ifcfg.log, programlog, storage.log
(In reply to comment #1) > When you hit a traceback, there's really no need to do anything besides attach > /tmp/anaconda-tb-* as a text file to this bug. By attaching things as > tarballs, you are making it more difficult for us to search attachments in the > future and that's something I do pretty much all the time. I started a second test, now with F16/RC3 install DVD (not live!), using the same extended partition (ext4) which I formatedd outside anaconda in F15. I declared it as "/"-partition. Then proceeding (next), anaconda works a little bit, then crashes. I posted some files to http://www-user.rhrk.uni-kl.de/~backes/UL/anaconda.log http://www-user.rhrk.uni-kl.de/~backes/UL/program.log http://www-user.rhrk.uni-kl.de/~backes/UL/storage.state http://www-user.rhrk.uni-kl.de/~backes/UL/storage.log http://www-user.rhrk.uni-kl.de/~backes/UL/anaconda-tb-zQc0f2 http://www-user.rhrk.uni-kl.de/~backes/UL/syslog You can download them from there. Kind regards Joachim Backes
*** Bug 729927 has been marked as a duplicate of this bug. ***
Just for the record (workaround): I manage to install Live anyway by "tricking" anaconda into continuing the install "somehow" (something like pressing Debug and then quickly Next/Continue - sorry I don't remember quite remember): perhaps it is only possible from the Live desktop?
Discussed in the 2011-08-12 blocker review meeting. Since a custom layout was used for this bug, it doesn't hit any of the alpha blocker criteria. However, it does hit the following Fedora 16 final release criteria [1]: The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above. Re-proposing as a final blocker. [1] https://fedoraproject.org/wiki/Fedora_15_Final_Release_Criteria
As an additional point of data, I hit this bug on an upgrade where I wanted to keep /home, so it was not really a "custom" partitioning (in the sense that the layout is the same the installer would do if I'd let it "Remove all linux partitions" Sadly, in the end I had to install F15 on that PC but hoped to try it again for Alpha. Looks like I'll need to wait for final
People will hit this when /boot is on a disk with a msdos label, eg. when upgrading. The fix it on master, it was a matter of making sure we check for the PARTITION_NAME support before writing the partition label.
(In reply to comment #13) > People will hit this when /boot is on a disk with a msdos label, eg. when > upgrading. The fix it on master, it was a matter of making sure we check for > the PARTITION_NAME support before writing the partition label. Upgrading is not covered by the alpha release criteria [1] but is covered by the beta release criteria [2] as: The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria. If a user would hit this by using one of the default partitioning options on a fresh install, it could be considered an alpha blocker: The installer must be able to complete an installation using the entire disk, existing free space, or existing Linux partitions methods, with or without encryption or LVM enabled. I suppose that alpha NTH would also be possible if msdos disk labels are common and a tested fix was available. [1] http://fedoraproject.org/wiki/Fedora_16_Alpha_Release_Criteria [2] http://fedoraproject.org/wiki/Fedora_16_Beta_Release_Criteria
After talking with Brian in IRC, it turns out that any install on a disk with MSDOS disk labels and not being completely wiped would hit this. Re-proposing as Fedora 16 NTH. I'm +1 NTH on this since the impact is greater than we thought at first.
+1 NTH, that's a nasty impact which affects quite a range of scenarios.
Thank you very much. I take this chance to thank all the anaconda developers and QA team for the amazing amount of work poured into each and every Fedora release; I'm proud to be part of this community
anaconda-16.14.5-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/anaconda-16.14.5-1.fc16
Discussed at the weekly QA meeting of 2011-08-15 (with anaconda team and releng in attendance). Accepted as NTH due to potential impact on clean installs (I could not reproduce in an artificial test, but there's someone on test@ who may be hitting this).
Package anaconda-16.14.5-1.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing anaconda-16.14.5-1.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/anaconda-16.14.5-1.fc16 then log in and leave karma (feedback).
Live install of Alpha RC4 looks good to me now.
I can confirm that anaconda-16.14.5-1.fc16 installs F16 from the Alpha-RC4-live if "installing to harddisk". But the bootloader could not be written (I will open a new BZ for that), so this F16 is not bootable.
This time netboot install got past this issue, well done. I hit another roadblock because it now says it can't mount my existing /home LV; of course that's for another BZ
anaconda-16.14.6-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/anaconda-16.14.6-1.fc16
anaconda-16.14.6-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.