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: anacondaAssignee: David Lehman <dlehman>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 18CC: 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 Flags
anaconda.log
none
program.log
none
storage.log
none
storage.state
none
anaconda.log, 19.30.3-1
none
program.log, 19.30.30-1
none
storage.log, 19.30.3-1
none
program.log, 19.30.3-1 none

Description Chris Murphy 2012-12-26 09:16:01 UTC
Description of problem:
On a disk with existing Btrfs, installer refuses to allow Boot mount point to be created (Home and Root can be); probably because it expects Boot to be created by default as ext4, and there is no space on the destination disk for an ext4 volume.

Version-Release number of selected component (if applicable):
anaconda-18.37.8-1

How reproducible:
Always

Steps to Reproduce:
1. Create a single partition disk, as Btrfs.
2. Manual Partitioning, click plus and add Root and/or Home.
Success.
3. Click plus and add Boot mount point.

  
Actual results:
Error not enough free space on disks.

Expected results:
Boot should be created as a Btrfs subvolume by default on Btrfs disks.

Additional info:

Comment 1 Chris Murphy 2012-12-26 09:16:44 UTC
Created attachment 669142 [details]
anaconda.log

Comment 2 Chris Murphy 2012-12-26 09:17:14 UTC
Created attachment 669143 [details]
program.log

Comment 3 Chris Murphy 2012-12-26 09:17:44 UTC
Created attachment 669144 [details]
storage.log

Comment 4 Chris Murphy 2012-12-26 09:18:14 UTC
Created attachment 669145 [details]
storage.state

Comment 5 Chris Lumens 2013-05-01 18:51:00 UTC
Can you please try again with Fedora 19 alpha?  anaconda-19.1 included a patch that allowed /boot as a btrfs subvolume.  Thanks.

Comment 6 Brian Lane 2013-06-05 23:20:28 UTC
This seems to be working for me with 19.30.2, can you retest with TC1?

Comment 7 Chris Murphy 2013-06-06 03:13:17 UTC
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.

Comment 8 Chris Murphy 2013-06-08 21:50:15 UTC
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.

Comment 9 Chris Murphy 2013-06-08 21:57:51 UTC
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.

Comment 10 Chris Murphy 2013-06-08 22:00:36 UTC
Created attachment 758636 [details]
program.log, 19.30.30-1

Comment 11 Chris Murphy 2013-06-08 22:01:15 UTC
Created attachment 758637 [details]
storage.log, 19.30.3-1

Comment 12 Chris Murphy 2013-06-08 22:06:22 UTC
Created attachment 758638 [details]
program.log, 19.30.3-1

Comment 13 Chris Murphy 2013-06-08 22:16:33 UTC
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."

Comment 14 Adam Williamson 2013-06-10 16:55:44 UTC
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.

Comment 15 Fedora End Of Life 2013-12-21 10:05:06 UTC
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.

Comment 16 Adam Williamson 2013-12-21 19:33:40 UTC
heh, look, another thing that disallowing /boot on LVM or btrfs fixes! they're everywhere!