Red Hat Bugzilla – Bug 872849
Last modified: 2012-12-18 12:56:09 EST
Description of problem:
a previous F18 instance, using automatic partitioning type BTRFS of 2 disks.
i selected these 2 disks, and tried automatic partitioning again but with LVM, in the reclaim space
dialog, i set all to 'delete' but for the last disks i choose 'shrink' wich does not make sense.
if you are swiching from BTRFS to LVM you cannot shrink and most likely no preserve too, since the btrfs previously created spans the two disks and so will be the LVM that will be created.
Version-Release number of selected component:
libreport version: 2.0.17
cmdline: /usr/bin/python /sbin/anaconda
:The following was filed automatically by anaconda:
:anaconda 18.24 exception report
:Traceback (most recent call first):
: File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devicelibs/btrfs.py", line 46, in btrfs
: raise BTRFSError(ret)
: File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devicelibs/btrfs.py", line 95, in delete_subvolume
: return btrfs(args)
: File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devices.py", line 4115, in _destroy
: btrfs.delete_subvolume(mountpoint, self.name)
: File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devices.py", line 819, in destroy
: File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/deviceaction.py", line 286, in execute
: File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devicetree.py", line 323, in processActions
: File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 293, in doIt
: File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 131, in turnOnFilesystems
: File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 113, in doInstall
: File "/usr/lib64/python2.7/threading.py", line 504, in run
: self.__target(*self.__args, **self.__kwargs)
: File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 91, in run
: threading.Thread.run(self, *args, **kwargs)
Created attachment 637612 [details]
Created attachment 637613 [details]
Created attachment 637614 [details]
Created attachment 637615 [details]
Created attachment 637616 [details]
Created attachment 637617 [details]
Created attachment 637618 [details]
Created attachment 637619 [details]
Created attachment 637620 [details]
Created attachment 637621 [details]
Created attachment 637622 [details]
Created attachment 637623 [details]
Created attachment 637624 [details]
Created attachment 637625 [details]
Created attachment 637626 [details]
In another new guest selecting several disks, i installed with automatic partitioning type btrfs ok.
Then i tried to install over with automatic partitioning type plain and set all partitions to 'delete'. Anaconda could not delete the previously created btrfs setup.
Created attachment 637685 [details]
storage.log of the previous comment
Created attachment 637687 [details]
storage.log of the previous comment
I can't recall precisely what happened, but I think this is the result of something odd that happened while I was removing existing partitions - a previous btrfs install of F18 - in custom partitioning. I think I clicked on the root partition, then did some stuff to it in the right hand pane, then clicked on it in the left hand pane again, and it disappeared from the list; I clicked the '-' button to delete it, and the message that popped up suggested either that the partition was called '5' or it was part of a group called '5' or something like that. I fiddled about some more, then went to complete the install, and this crash happened during partitioning. I'll try and reproduce more precisely.
OS Release: Fedora release 18-Beta-TC7
So this is definitely to do with removing existing btrfs partitions.
I can actually hit it simply by using guided partitioning on a certain btrfs layout I have in a VM. No entry into custom part is needed. All I have to do is tell the 'guided freeing up space' dialog to delete all the existing partitions, and continue with install, and it explodes. It's really choking on this existing layout somehow.
Here's some info on the layout:
btrfs subvol list:
ID 256 gen 12 top level 5 path home
ID 258 gen 26 top level 5 path root
btrfs filesystem show:
Label: 'fedora' uuid: 5b678d48-5fc8-492a-9ce2-d99112a692b4
Total devices 1 FS bytes used 596.00MB
devid 1 size 12.54GB used 3.04GB path /dev/vda2
Btrfs Btrfs v0.19
parted -s /dev/vda p:
Model: Virtio Block Device (virtblk)
Disk /dev/vda: 16.1GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 1049kB 525MB 524MB primary boot
2 525MB 14.0GB 13.5GB primary
I'll also attach the logs from my cleanest reproducer.
Created attachment 639625 [details]
traceback from my 18.24 cleanish reproducer
Created attachment 639626 [details]
storage.log from my reproducer
Created attachment 639627 [details]
program.log from my reproducer
*** This bug has been marked as a duplicate of bug 868468 ***
Hit this in TC3, but did not save logs so can't contribute meaningfully except to note that I had created a btrfs subvolume in running TC2 system. Had to deleted all partitions when I tried to reinstall using TC3.