Bug 808970

Summary:	needlessly requires new filesystem on freshly prepared / device
Product:	[Fedora] Fedora	Reporter:	Felix Miata <mrmazda>
Component:	anaconda	Assignee:	Anaconda Maintenance Team <anaconda-maint-list>
Status:	CLOSED WONTFIX	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	17	CC:	anaconda-maint-list, g.kaviyarasu, jonathan, vanmeeuwen+fedora
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	i686
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-04-04 19:59:35 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:

Description Felix Miata 2012-04-02 04:17:12 UTC

Description of problem:
All my systems are multiboot. I always partition (if necessary) and format (when necessary) and give partitions labels (always) prior to beginning any installation. This I did prior to attempting to HTTP install minutes ago via Grub loading of kernel and initrd currently on the mirrors for Fedora 17. Anaconda allows me to select the desired (sda14 4800MiB EXT3) partition to be used as /, but requires a "new" filesystem, even though it has a brand new supported filesystem meeting my specifications. Exact message "you must create a new filesystem on the root device" appears after selecting / from the mount point list, under which are the original filesystem type and label, and, with format and resize boxes unchecked, clicking on OK.

Comment 1 David Lehman 2012-04-02 17:09:12 UTC

This is working as designed. See bug 629311 for some discussion on the topic of preexisting root filesystems.

Comment 2 Felix Miata 2012-04-02 17:34:18 UTC

I saw that bug when it was fresh, and thought by now it would have been reversed. It's rudely designed to cut into dev test time. The target is empty but for lost+found. Anaconda should see that the create time is less than 24 hours old, and that there are no files or directories, and accept it as a / target. That should be good enough to avoid the issues that lead to the current policy. Now I have to install elsewhere, then copy to the desired target prepared with specifications meeting my requirements. It means I do far less Anaconda testing than I would otherwise.

Comment 3 David Lehman 2012-04-02 17:59:04 UTC

(In reply to comment #2)
> I saw that bug when it was fresh, and thought by now it would have been
> reversed. It's rudely designed to cut into dev test time. The target is empty
> but for lost+found. Anaconda should see that the create time is less than 24
> hours old, and that there are no files or directories, and accept it as a /
> target. That should be good enough to avoid the issues that lead to the current

Patches are welcome. I have more pressing issues to deal with. If saving time is your goal you should look into kickstart, where you can use --fsprofile to select an ext[234] profile (potentially one you added in %pre).

Comment 4 Chris Lumens 2012-04-04 19:59:35 UTC

I really can't see us doing this, though.  This is a lot of potentially very buggy code to kind of halfway support a case we don't even want to support.