Bug 892196

Created attachment 673023 [details]
anaconda-tb

Created attachment 673024 [details]
anaconda.log

Created attachment 673025 [details]
program.log

Created attachment 673026 [details]
storage.log

Created attachment 673027 [details]
storage.state

Regression testing reveals this is a problem specifically with multiple device Btrfs volumes. Crash does not occur when creating subvols on single device Btrfs volumes.

Crash, with multiple device Btrfs volume, is reproducible with all data/metadata profiles: single, dup, raid1, raid0, raid10; with anaconda 18.37.8-1 and 18.37.10-1 so this is not a regression in anaconda, it's a new bug.

Step by step example:
1. Two disks (new or used) selected in Installation Destination.
2. Use either "guided" autopart with Btrfs chosen; or use Manual Partitioning to create at least one Btrfs device with any or no options checked.
3. Installs fine.
4. Reboot to installer to either reinstall or add a new installation to the existing Btrfs volume.

Crash upon adding Root mountpoint (subvolume) to existing Btrfs volume.

Consequence is additional or new installs of F18 to an existing multiple device pool, are not possible. No work around. (Equivalent LVM2 behavior would be failure to create new LV from a multiple disk VG.)

Proposing as blocker, Fedora 18 beta release criterion #10: "The installer's custom partitioning mode must be capable of... creating/assigning mount points to partitions of any specified size using most commonly-used filesystem types... rejecting obviously invalid operations without crashing."

Couldn't reproduce this.

I tested in a VM with one 15GB and one 10GB disk. Selected both, did custom partitioning, created / and /boot as btrfs, size 15GB swap as ext4, size 2GB, completed install. Tested installed system boots, rebooted back to installer, selected both disks again, went back to custom partitioning, added a 5GB / partition as type btrfs, no crash, worked fine. Added a 500MB ext4 /boot for the new install, re-using the existing swap, new install boots.

I may be missing something here - btrfs confuses the hell out of me, I've no idea how to tell if it's in the same btrfs volume as the previous install - but I don't see any way to *change* that. I don't see any way to specify what volume a given btrfs subvol is a part of. If I'm missing something, please provide better repro instructions, those are nowhere close to 'step by step'.

When I try to do what you did I get a crash trying to change swap from 10G to 2G, Bug 892255.

After getting past that, I can't reproduce the crash with your 15GB and 10GB setup either. But if I use two 80GB virtual disks, use "guided" BTRFS to initially create; and then
1. select both disks, click continue
2. installation options modal dialog, choose btrfs as scheme; check let me customize, click reclaim space.
3. click + button, type /, do not insert a capacity value, click add mount point.

Crash.

well, aren't you then attempting to add a subvol to an already full volume? you didn't reduce the size of any existing subvol first? I'm not sure about that, but that's what it sounds like.

OK, I can reproduce with that procedure. Still not sure how bad a bug this is, be good to get a call from bcl/clumens/dlehman. I think I'm missing something about how btrfs sizing works; is it that you only actually define the size of the container (volume) and subvols are always dynamically sized?

Subvolumes don't have a size, they're like creating folders. That's why all Mount Points set as Device Type BTRFS have the same size no matter how many there are. If you change the size of one, you change the size of all, because the size is the size of the volume, not the subvolume. (This is bug one of the reasons the UI is beyond confusing for Btrfs IMO).

This bug means using existing multiple device Btrfs is a show stopper. It would be the same thing if people couldn't install Fedora 18 to a multiple disk VG, with no work around.

As for why your original 15GB and 10GB did not crash, I'm thinking it's because your / and /boot were 15GB out of 25GB, and swap was 2GB. That's only 17GB allocated. You had 8GB of unallocated space. So on your 2nd go around, when you added another Root as type Btrfs it actually created another partition and a whole new Btrfs volume in that free space. It wasn't actually adding a Root subvolume to the existing Btrfs volume.

When I redo your 15GB and 10GB disk test, but ensure that I put 5GB swap on the 15GB disk, then 20GB Btrfs on both disks for / and /boot, such that there's no more free space; on the 2nd go around I get a crash when creating a new Root mount point as type Btrfs.

Works for single disk. Should work for 2+.

Yes, I know. I did that on purpose, to see if having free space or not matters.

Are you sure it's actually capable of adding new subvols to an existing volume? I have yet to be able to catch it doing that. If I tweak it so the existing btrfs volume is using 24 out of 25 GB, and then create a new / partition as type btrfs, it only lets me make it 1 GB big. I cannot find any way to tell it to make the new / partition a subvol of the existing volume. I'm not convinced that in the 'failure' case it's trying to make the / partition a subvol of the existing volume and crashing; I think it's trying to create a new, very very tiny or 0-size btrfs volume, and crashing.

I'll poke the single-disk case a bit, though. Are you saying it _is_ capable of creating new subvols of an existing volume in the single disk case?

(why aren't you on IRC, btw?)

OK, I can confirm the different behaviour in the single-disk case: anaconda can add new subvols to the existing volume ('container') when doing a very similar process with only one disk. So:

 * Install to a single disk using guided partitioning, BTRFS
 * Reboot, go to disk cart, change volume type to BTRFS, check custom part, go into custom
 * Create a new / partition: anaconda will pop up 'Added new BTRFS to existing container fedora'. And it does. And it works.

Same test case but with a multi-disk BTRFS volume results in anaconda trying to create a new volume, not adding the subvol to the existing volume. Even if you selected all disks of the volume.

So I think this bug is really as simple as: anaconda can't add subvols to an existing multi-disk btrfs volume. I think the crash is really just a special case of this more general bug, where it results in anaconda trying to create a 0-sized or extremely small btrfs volume.

Whether 'anaconda can't add subvols to an existing multi-disk btrfs volume' is serious enough to be a blocker bug...eh. Judgement call. I am very much in 'just ship the damn thing already' mode right now, so maybe I'd better not vote yet.

(In reply to comment #14)
> Are you sure it's actually capable of adding new subvols to an existing
> volume?

Yes because I have been doing exactly that for almost two weeks since .8 came out. That's why today I thought it was a .10 regression before thinking maybe it was a single disk vs multidisk problem.

> partition as type btrfs, it only lets me make it 1 GB big. I cannot find any
> way to tell it to make the new / partition a subvol of the existing volume.

Nope it's assumed. This area will need a rethink for F19 if there isn't one already in the works. Because this is like being required to make new VGs if there's free space rather than adding an LV to an existing VG, or growing a VG.

> I'm not convinced that in the 'failure' case it's trying to make the /
> partition a subvol of the existing volume and crashing; I think it's trying
> to create a new, very very tiny or 0-size btrfs volume, and crashing.

Seems reasonable. Below a certain size btrfs-progs pops up various messages about doing mixed data and metadata, which requires their profiles to be the same; and anaconda's default is not btrfs default. The data profile is single, and metadata is raid1; so mixed isn't possible so I bet btrfs is saying "I can't do that".

> I'll poke the single-disk case a bit, though. Are you saying it _is_ capable
> of creating new subvols of an existing volume in the single disk case?

Yes. As long as there's no free space on the disk.

Try:

 updates=http://dlehman.fedorapeople.org/updates/updates-892196.0.img

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 . Rejected as a blocker but accepted as NTH: we felt that installs to existing multi-disk btrfs volumes are too much of a corner case to block release over (though note, dlehman thinks the issue should also affect single-disk volumes: myself and cmurf both tested that case and found it to work, but we will re-check). It is possible this bug is effectively the same as 892046 - that you can only hit that traceback via the conditions described in this bug. Either way, the problem is RejectedBlocker, AcceptedNTH for now.

My suspicion is this is a duplicate of 892046, but let's see if the patch fixes both of them before closing this one as such.

This looks pretty good in basic testing. I still can't reproduce the problem with a single-disk volume, though dlehman says he can, but either way, using the updates.img , both single-disk and multi-disk cases work okay here, and I couldn't catch any other failures (I did all my 'prep' installs using the updates.img just to see if I could catch it breaking anywhere else).

No patch single disk, I can add / or any other subvol if I leave capacity blank. If I enter a capacity. I get a crash. No patch dual disk, I get a crash adding a subvol with or without capacity being blank.

With patch, both crash cases are fixed.

anaconda-18.37.11-1.fc18 fixes this bug.