Created attachment 672994 [details] screenshot showing the issue Description of problem: I have the following issue: I installed a guest with automatic partitioning setting the scheme to btrfs and that worked ok. It created a /boot (ext) and swap and / and /home on same btrfs partition (using subvols). Then i tried to install over to such system. The ida was to reformat all partitions except for /home (which would contain data). I have found that anaconda does not offer the option to 'reformat' the previous / partition. Anaconda asks to delete and create it again. But there is a problem, since both / and /home do use the same btrfs partition, there will be no free space to do so once one deletes the current /. So, one needs to delete the previous /home too!! :-( Version-Release number of selected component (if applicable): TC4 (18.37.8) How reproducible: always Steps to Reproduce (PRE-REQUISITE): 0. Install F18 on a one disks system with automatic partitioning setting the scheme to btrfs. I selected minimal. Steps to Reproduce (ISSUE): 1. boot anaconda on the same system without kernel parameters. 2. select the disk and do a manual partitioning setting the scheme to btrfs. 3. 'reformat' /boot and set the mount point also to /boot, then apply. OK. 4. 'reformat' swap and apply. OK. 5. Set mount point for /home and apply. OK. 6. For /, the only acion is to DELETE it. Actual results: It is not possible to 'reformat' / without deleting /home. Expected results: Anaconda should be able to 'reformat' / without deleting /home, even if it means doing a recursive rm on said filesystem. Additional info: I believe that this is a NTH at least, since it forces one to delete /home to being able to install. And the intention was to preserve /home and 'reformat' all other partitions. Additionally, i am installing over a previous setup made with automatic partitioning with scheme set to btrfs.
Created attachment 672995 [details] anaconda.log
Created attachment 672996 [details] program.log
Created attachment 672997 [details] storage.log
-1 blocker, this is somewhat annoying, but just not serious enough to be a blocker, esp. given we didn't have interactive btrfs support in F17. +1 NTH, though.
-1 blocker, and -1 NTH. You can delete a root subvol and/or create a new one, which in effect creates a new file system on Btrfs.
The and/or is confusing. I should have said you must create a new root subvol (which is done by adding a new root mount point as Device Type Btrfs), you can optionally delete the previous root subvol.
-1/-1 nth as I'd like to avoid touching anaconda now as much as possible
Created attachment 673499 [details] anaconda-tb I tried with RC1 (18.37.10): Steps to Reproduce (ISSUE): 1. boot anaconda on the same system without kernel parameters. 2. select the disk and do a manual partitioning setting the scheme to btrfs. 3. 'reformat' /boot and set the mount point also to /boot, then apply. OK. 4. 'reformat' swap and apply. OK. 5. Set mount point for /home and apply. OK. 6. For the / subvol at this poit i can do: A. DELETE all subvols and recreate them all. Wiping /home. * This works, but the user might be force to do a backup of its belongings. B. Create another / subvol as proposed in comment #1 (For 'size' i used 4983mb) * But it crashes with: Bug 892046 (but not the original description but comment #9) C. Create a /a subvol (For 'size' i used 4983mb) * But it crashes with: Bug 892046 (but not the original description but comment #9) D. DELETE / subvol and add a /a subvol (For 'size' i used 4983mb) (a workaround,since i would change it to / if it does not crash). * But it crashed with: Bug 892046 (but not the original description but comment #9) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Basically i am unable to do what Chris suggested in comment #6. The only thing i can do is A. So Bug 892046 Comment #9 is basically this bug-report.
Bingo. OK I can reproduce the crash for 892046. It happens when specifying capacity for what will become a subvolume. Subvolumes don't have capacities so we shouldn't even be asked for such a thing. If you leave it blank, you won't get a crash. The UI is confusing. What you have to do is in Installation Options, choose Partition Scheme Configuration > BTRFS, check "let me customize". If you don't do this, and the disks are full, Manual Partition wants to create a new partition for Root, because the default is set to LVM and hidden in Installation Options. So to get Manual Partitioning to add Root as a subvol, you must have earlier specified BTRFS in Installation Options. And you must not choose a capacity value for the mountpoint. So try it again without a value. And in any case, I think this bug is not a bug, because the reformatting a Btrfs volume is untenable. We should create subvols instead, and we can, it's just clunky figuring it out right now.
I works as Chris described, no crash and it is possible to start installing. A light-yellow banner will indicate that the new subvol was added. > And in any case, I think this bug is not a bug, because the > reformatting a Btrfs volume is untenable. We should create > subvols instead [...] Agreed, but in that case the mount point dialog should refuse any value other than zero for btrfs subvolumes. And maybe an error message. I do believe that even if it is not a bug, it will be hit frequently and it will be better to stop it at the mount point dialog level. Cheers.
(In reply to comment #10) > Agreed, but in that case the mount point dialog should refuse any value > other than zero for btrfs subvolumes. And maybe an error message. I do > believe that even if it is not a bug, it will be hit frequently and it will > be better to stop it at the mount point dialog level. I think you're referring to your bug 892046, which I agree is a bug and a blocker because of the crash. As for this bug 892188, I think it's not a bug, based on your "expected results". The way to do this is create a new root subvol, not reformat or recursive rm. The related problem is simply UI maturation is needed to handle Btrfs volumes and subvolumes better.
Yeah. The current UI obviously needs some tweaking to be a sane representation of actual plausible btrfs-related operations, but I don't think we can block on that at this stage, esp. since F17 had no btrfs UI at all. I concur with Chris that this specific bug should probably be closed as notabug, and we should concentrate on 892046.
Agreed to close as notabug, I commented on 892046 based on my understanding of the issue.
Discussed at 2013-01-07 QA meeting acting as a blocker review meeting: http://meetbot.fedoraproject.org/fedora-meeting/2013-01-07/fedora-qa.2013-01-07-16.01.log.txt . As we understand it, this specific bug is definitely not a blocker or NTH - the behaviour of anaconda as regards volumes and subvols is a bit confusing, but it's not a blocker issue. See Chris Murphy's comments for more detail. It may be appropriate to close this as NOTABUG, but we'll leave that determination up to the anaconda team. In general terms, the user interaction with regard to volumes vs. subvols could definitely use some work.
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.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.