Bug 1856496 - Anaconda cannot reclaim space from swap partition
Summary: Anaconda cannot reclaim space from swap partition
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Vendula Poncova
QA Contact: Fedora Extras Quality Assurance
Whiteboard: AcceptedBlocker
Depends On:
Blocks: BetaBlocker, F33BetaBlocker
TreeView+ depends on / blocked
Reported: 2020-07-13 18:47 UTC by Brandon Nielsen
Modified: 2020-07-30 08:48 UTC (History)
13 users (show)

Fixed In Version: anaconda-33.24-1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed:
Type: Bug

Attachments (Terms of Use)
Log provided by Anaconda after the error occurs (1.19 MB, text/plain)
2020-07-13 18:47 UTC, Brandon Nielsen
no flags Details

Description Brandon Nielsen 2020-07-13 18:47:36 UTC
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

Comment 1 Brandon Nielsen 2020-07-13 19:35:32 UTC
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.

Comment 2 Brandon Nielsen 2020-07-13 20:28:34 UTC
Reclaiming ext4 and swap partition also fails, so the problem seems to be from reclaiming swap.

Comment 3 Brandon Nielsen 2020-07-13 20:34:39 UTC
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.

Comment 4 Brandon Nielsen 2020-07-14 12:04:34 UTC
Cannot reproduce using KVM with a single-boot configuration. Have not tested KVM with dual-boot.

Comment 5 Brandon Nielsen 2020-07-14 18:24:26 UTC
I can reproduce using KVM in a dual-boot configuration alongside Windows 10, ruling out hardware.

Comment 6 Brandon Nielsen 2020-07-14 18:29:04 UTC
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                                                            
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

Comment 7 Chris Murphy 2020-07-14 19:27:12 UTC
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.

Comment 8 Fedora Blocker Bugs Application 2020-07-14 19:34:40 UTC
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.

Comment 9 Brandon Nielsen 2020-07-14 19:49:13 UTC
Still seeing the issue with Anaconda 33.22.

Comment 10 Geoffrey Marr 2020-07-20 18:55:05 UTC
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

Comment 11 Brandon Nielsen 2020-07-21 11:58:22 UTC
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

Comment 12 Vendula Poncova 2020-07-28 10:23:18 UTC
Fixed in a pull request: https://github.com/rhinstaller/anaconda/pull/2755

Note You need to log in before you can comment on or make changes to this bug.