Bug 890302
Summary: | installer does not also try non-default device types when trying to create new /boot with full disk(s) | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Chris Murphy <bugzilla> | ||||||||||||||||||
Component: | anaconda | Assignee: | David Lehman <dlehman> | ||||||||||||||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||||||||
Severity: | unspecified | Docs Contact: | |||||||||||||||||||
Priority: | unspecified | ||||||||||||||||||||
Version: | 18 | CC: | anaconda-maint-list, awilliam, dlehman, g.kaviyarasu, jonathan, robatino, sbueno, vanmeeuwen+fedora | ||||||||||||||||||
Target Milestone: | --- | ||||||||||||||||||||
Target Release: | --- | ||||||||||||||||||||
Hardware: | Unspecified | ||||||||||||||||||||
OS: | Unspecified | ||||||||||||||||||||
Whiteboard: | RejectedBlocker | ||||||||||||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||||||||
Doc Text: | Story Points: | --- | |||||||||||||||||||
Clone Of: | Environment: | ||||||||||||||||||||
Last Closed: | 2013-12-21 19:33:40 UTC | Type: | Bug | ||||||||||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||||||||||
Documentation: | --- | CRM: | |||||||||||||||||||
Verified Versions: | Category: | --- | |||||||||||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||||||||
Embargoed: | |||||||||||||||||||||
Attachments: |
|
Description
Chris Murphy
2012-12-26 09:16:01 UTC
Created attachment 669142 [details]
anaconda.log
Created attachment 669143 [details]
program.log
Created attachment 669144 [details]
storage.log
Created attachment 669145 [details]
storage.state
Can you please try again with Fedora 19 alpha? anaconda-19.1 included a patch that allowed /boot as a btrfs subvolume. Thanks. This seems to be working for me with 19.30.2, can you retest with TC1? At least with beta, I get no errors like with F18, but it doesn't add anything. It says it's adding a new subvolume but it isn't actually added. I'll retest with TC1 and then report back. Testing with F19 Beta, yum updated anaconda to 19.30.3-1, python-blivet 0.15-1. I can add a root subvolume to an existing full disk btrfs file system. When I try to add /boot, nothing happens, no error message. I can attach logs but they're totally unrevealing as if I hadn't even chosen a /boot mount point. Created attachment 758635 [details]
anaconda.log, 19.30.3-1
17:50:58,424 DEBUG anaconda: old mountpoint: /
17:50:58,424 DEBUG anaconda: new mountpoint: /
I don't understand this. I didn't ask for / in the Add New Mount Point dialog. I asked for /boot, without specifying a Desired Capacity value (left it blank.).
17:51:08,253 DEBUG anaconda: info bar clicked: not enough free space on disks ((<SpokeWindow object at 0x5c7ac30 (AnacondaSpokeWindow at 0x52fb770)>,))
This I asked for /boot with a Desired Capacity value of 500MB, and I get a bogus error message saying there isn't enough space for it, but at least there's an error message, rather than the earlier case where nothing happens at all.
Created attachment 758636 [details]
program.log, 19.30.30-1
Created attachment 758637 [details]
storage.log, 19.30.3-1
Created attachment 758638 [details]
program.log, 19.30.3-1
Proposing as a final release blocker: "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." Discussed at 2013-06-10 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-10/f19final-blocker-review-4.2013-06-10-16.01.log.txt . Rejected as a blocker: the behaviour seems inelegant and contrary to user expectations, but can at least be worked around easily (by creating a different mount point and then changing it to /boot). The question of whether this is a bug to be fixed or not can be considered separately. This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. heh, look, another thing that disallowing /boot on LVM or btrfs fixes! they're everywhere! |