Created attachment 1700886 [details] Log provided by Anaconda after the error occurs Description of problem: Anaconda fails with "An unknown error has occurred" when attempting to reclaim space from a btrfs partition. Version-Release number of selected component (if applicable): anaconda as included in Fedora 33 Rawhide 20200713.n.0 compose (Workstation Live)[0]. How reproducible: Every time Steps to Reproduce: 1. Somehow get a system with a btrfs partition configured (I used the Fedora btrfs test day Workstation Live compose[1], default partition options) 2. Reboot into the above compose 3. Attempt to reclaim space as described in "Testcase partitioning guided delete partial"[2], including a btrfs partition as one to reclaim space from Actual results: "An unknown error has occurred", installation does not continue. Expected results: Installation to continue normally, including the space from the reclaimed btrfs partition in the resulting partition layout. Additional info: I have attached the resulting log. This is on a BIOS system, dual booting alongside Windows 10. 0 - https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20200713.n.0/compose/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-Rawhide-20200713.n.0.iso 1 - https://fedorapeople.org/groups/qa/test_days/Fedora-Workstation-Live-x86_64-20200708-btrfsdefault.iso 2 - https://fedoraproject.org/wiki/QA:Testcase_partitioning_guided_delete_partial
I was in error, but there is definitely something weird here. I blindly assumed that because the log gave the btrfs partition, it was the reason for the failure. In further testing: The following work: 1: Reclaiming just the btrfs partition 2: Reclaiming an ext4 and btrfs partition The following does not: 1: Reclaiming a swap and btrfs partition Will test again with ext4 and swap shortly.
Reclaiming ext4 and swap partition also fails, so the problem seems to be from reclaiming swap.
Simply reclaiming a single large swap partition large enough to allow the install to continue seems to work. So to recreate the issue, deleting two partitions, one of which is swap, seems to be necessary.
Cannot reproduce using KVM with a single-boot configuration. Have not tested KVM with dual-boot.
I can reproduce using KVM in a dual-boot configuration alongside Windows 10, ruling out hardware.
Last bit of information I can think to add, this is the partition layout I'm testing with: [test@localhost ~]$ sudo parted /dev/sda GNU Parted 3.3 Using /dev/sda Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) print Model: ATA QEMU HARDDISK (scsi) Disk /dev/sda: 42.9GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1049kB 577MB 576MB primary ntfs boot 2 577MB 23.0GB 22.4GB primary ntfs 3 23.0GB 24.1GB 1074MB primary ext4 4 24.1GB 42.9GB 18.9GB extended 5 24.1GB 26.0GB 1998MB logical linux-swap(v1) 6 26.1GB 42.9GB 16.9GB logical btrfs
Thanks for sticking with this bug! Attached log shows this is anaconda 33.21. Anaconda 33.22 just landed today in koji and likely can be updated just by 'dnf update anaconda' in the live environment and see if it's still a bug. In the meantime i'll propose as a blocker.
Proposed as a Blocker for 33-beta by Fedora user chrismurphy using the blocker tracking app because: Basic: The installer must be able to complete an installation to a single disk using automatic partitioning. Beta: Remove existing storage volumes to free up space, at the user's direction It's probably more the second case than the former.
Still seeing the issue with Anaconda 33.22.
Discussed during the 2020-07-20 blocker review meeting: [0] The decision to classify this bug as an "AcceptedBlocker" was made as it violates the following Beta criterion: "When using the guided partitioning flow, the installer must be able to: ... Remove existing storage volumes to free up space, at the user's direction" [0] https://meetbot.fedoraproject.org/fedora-blocker-review/2020-07-20/f33-blocker-review.2020-07-20-16.18.txt
Still seeing this in the 20200721.n.0 Workstation Live compose [0]. [0] - https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20200721.n.0/compose/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-Rawhide-20200721.n.0.iso
Fixed in a pull request: https://github.com/rhinstaller/anaconda/pull/2755
33.24-1 was built a week ago, so this should be fixed by now. Brandon, can you confirm? Thanks!
(In reply to Adam Williamson from comment #13) > 33.24-1 was built a week ago, so this should be fixed by now. Brandon, can > you confirm? Thanks! I can confirm this appears fixed with anaconda 33.24-1. Tested with both a VM (BIOS), and bare metal (BIOS). Have not tested on a UEFI setup.
Awesome, thanks. Closing.
*** Bug 1874130 has been marked as a duplicate of this bug. ***