Bug 741587
Summary: | going back in partitioning reports "you have not created a bootloader stage1" every second time | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Kamil Páral <kparal> | ||||||||||
Component: | anaconda | Assignee: | David Lehman <dlehman> | ||||||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||
Severity: | unspecified | Docs Contact: | |||||||||||
Priority: | unspecified | ||||||||||||
Version: | 16 | CC: | akozumpl, anaconda-maint-list, bugzilla, jonathan, me, stanley.king, vanmeeuwen+fedora | ||||||||||
Target Milestone: | --- | ||||||||||||
Target Release: | --- | ||||||||||||
Hardware: | Unspecified | ||||||||||||
OS: | Unspecified | ||||||||||||
Whiteboard: | |||||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
Doc Text: | Story Points: | --- | |||||||||||
Clone Of: | Environment: | ||||||||||||
Last Closed: | 2012-02-29 15:30:56 UTC | Type: | --- | ||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||
Documentation: | --- | CRM: | |||||||||||
Verified Versions: | Category: | --- | |||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
Embargoed: | |||||||||||||
Bug Depends On: | |||||||||||||
Bug Blocks: | 713565 | ||||||||||||
Attachments: |
|
Description
Kamil Páral
2011-09-27 11:23:01 UTC
Created attachment 525090 [details]
bug demonstration video
Created attachment 525094 [details]
anaconda.log
Created attachment 525095 [details]
program.log
Created attachment 525096 [details]
storage.log
Not sure whether this is a blocker, the workaround is pretty easy. Proposing as Beta NTH. I can reproduce this, assigning to myself. what I think is happening: the first time through the loop bootloader.stage1_device is None. This acts well with _schedulePartitions in autopart because it causes new biosboot partition to be requested. During sanityCheck() the stage1_device is queried and the automatic property mechanism finds it is now possible to have a stage1_device and returns non-none. This value is stored and, unlike the rest of the storage subsystem, not reset upon the next attempt: the _schedulePartitions() does not allocate a biosboot, stage1_drive is set to None during doPartitioning and a new one is not set, there's no biosboot partition now. Kamil, can you please retest with http://akozumpl.fedorapeople.org/bz741587.img ? Thanks. Also, patch is awaiting review: https://www.redhat.com/archives/anaconda-devel-list/2011-September/msg00227.html I am withdrawing the patch, dlehman has a more general solution to this coming shortly. A fix will be in anaconda-16.21-1, which is post-beta. Is this bug related to the following behavior I get from the SEP 28 LiveCD beta? 3967MB flash drive with 3400MB free unallocated. Choose "Use Free Space" installation type, move it to the "Install Target Devices" column, check bootloader circle, and then next. Error message: Your / partition is less than 2282.0MB which is lower than recommended for a normal Fedora Live install. you have not created a bootloader stage1 target device. If I repartition this drive so that all of the space is completely free and unallocated (GPT scheme) and choose again the "Use Free Space" option, I get the same error message but without the "you have not created a bootloader stage1 target device." If I start yet again and choose "Use All Space" I get the same message, minus the "bootloader stage1" message. So in no case am I able to install from the LiveCD to a 4GB flash drive using any automatic option. If I go into custom partitioning, and manually create BIOS boot, /boot, and / then the installation proceeds. Seems like the installer is incorrectly estimating disk requirements using either "Use All Space" or "Use Free Space" options. This is presumably fixed in F16 and I can't reproduce it in F17, closing. |