Bug 1013586
Summary: | SizeNotPositiveError: spec= param must be >=0 | ||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Kamil Páral <kparal> | ||||||||||||||||||||||
Component: | anaconda | Assignee: | Vratislav Podzimek <vpodzime> | ||||||||||||||||||||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||||||||||||
Severity: | unspecified | Docs Contact: | |||||||||||||||||||||||
Priority: | unspecified | ||||||||||||||||||||||||
Version: | 20 | CC: | awilliam, bugzilla, collura, dshea, g.kaviyarasu, jonathan, mkolman, mruckman, pschindl, robatino, sbueno, vanmeeuwen+fedora, vpodzime | ||||||||||||||||||||||
Target Milestone: | --- | Keywords: | CommonBugs | ||||||||||||||||||||||
Target Release: | --- | ||||||||||||||||||||||||
Hardware: | x86_64 | ||||||||||||||||||||||||
OS: | Unspecified | ||||||||||||||||||||||||
Whiteboard: | abrt_hash:267490d8b33741741827b8ee14030788e7f1e8bbdf5c2f5120f4201a0bf6385b AcceptedBlocker https://fedoraproject.org/wiki/Common_F20_bugs#resize-bugs | ||||||||||||||||||||||||
Fixed In Version: | python-blivet-0.23.7-1.fc20 | Doc Type: | Bug Fix | ||||||||||||||||||||||
Doc Text: | Story Points: | --- | |||||||||||||||||||||||
Clone Of: | Environment: | ||||||||||||||||||||||||
Last Closed: | 2013-11-29 13:55:33 UTC | Type: | --- | ||||||||||||||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||||||||||||||
Documentation: | --- | CRM: | |||||||||||||||||||||||
Verified Versions: | Category: | --- | |||||||||||||||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||||||||||||
Embargoed: | |||||||||||||||||||||||||
Bug Depends On: | |||||||||||||||||||||||||
Bug Blocks: | 980656 | ||||||||||||||||||||||||
Attachments: |
|
Description
Kamil Páral
2013-09-30 11:57:53 UTC
Created attachment 805138 [details]
File: anaconda-tb
Created attachment 805139 [details]
File: anaconda.log
Created attachment 805140 [details]
File: environ
Created attachment 805141 [details]
File: lsblk_output
Created attachment 805142 [details]
File: nmcli_dev_list
Created attachment 805143 [details]
File: os_info
Created attachment 805144 [details]
File: program.log
Created attachment 805145 [details]
File: storage.log
Created attachment 805146 [details]
File: ifcfg.log
On Fedora-20-Alpha Live CD. I have one NTFS partition on GPT. Exception is raised after I choose ntfs partition and click on shrink in 'reclaim disk space'. Everything works fine with MBR. cmdline: /usr/bin/python /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-osimg-min --lang en_US.UTF-8 cmdline_file: BOOT_IMAGE=/isolinux/vmlinuz0 root=live:LABEL=Fedora-Live-Desktop-x86_64-20-Al ro rd.live.image quiet rhgb hashmarkername: anaconda kernel: 3.11.0-300.fc20.x86_64 other involved packages: python-blivet-0.20-1.fc20.noarch package: anaconda-20.18-1.fc20.x86_64 packaging.log: product: Fedora reason: SizeNotPositiveError: spec= param must be >=0 release: Fedora release 20 (Heisenbug) version: 20 This happens when you select a partition in the guided dialog and click on Shrink button. It happens for both NTFS and Ext4 partitions. It happens only with GPT, not with MBR. It doesn't seem to happen with custom partitioning dialog. Strangely enough, if I do a default Win8 UEFI (i.e. GPT) installation, I can resize its NTFS partition just fine. Maybe our tools create broken partition tables (protective MBR?) somehow? Reproducer: 1. Boot F20 Alpha Live 2. Format the disk with GPT, create a single NTFS/ext4 partition covering the whole disk. 3. Run anaconda, click on Reclaim space, click on the partition, click on Shrink. Reproduced both on bare metal and in VM, by several people. I guess this could fall into Beta criteria: " 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 " https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria It says remove, but it should say shrink as well, probably, because we don't have that covered in Final criteria. (In reply to Kamil Páral from comment #11) > 2. Format the disk with GPT, create a single NTFS/ext4 partition covering > the whole disk. Just a note, I used gnome-disks for this. For OP: The failure occurs if the target is produced by gnome-disks (both creating the GPT and the NTFS volume); but does not occur if the Windows installer creates them? For dlehman: Some size parameter has a negative value and it should be positive? Is this possibly related to how the file system was created, maybe due to a bug in ntfs-3G? Interestingly enough, if I create the layout with gparted, it doesn't crash. It's not important which tools creates the gpt table, the important thing is the partition creation. If gparted creates it, everything works. If gnome-disks creates it, anaconda crashes. Please note that gparted creates a smaller partition (by 1MB) than gnome-disks: gdisk output: gparted: Disk /dev/vda: 20971520 sectors, 10.0 GiB Logical sector size: 512 bytes Disk identifier (GUID): AE2D9C61-6F59-47FB-8FE9-4C09ABF9B246 Partition table holds up to 128 entries First usable sector is 34, last usable sector is 20971486 Partitions will be aligned on 2048-sector boundaries Total free space is 2014 sectors (1007.0 KiB) Number Start (sector) End (sector) Size Code Name 1 2048 20971486 10.0 GiB 8300 gnome-disks: Disk /dev/vda: 20971520 sectors, 10.0 GiB Logical sector size: 512 bytes Disk identifier (GUID): AE2D9C61-6F59-47FB-8FE9-4C09ABF9B246 Partition table holds up to 128 entries First usable sector is 34, last usable sector is 20971486 Partitions will be aligned on 2048-sector boundaries Total free space is 4029 sectors (2.0 MiB) Number Start (sector) End (sector) Size Code Name 1 2048 20969471 10.0 GiB 0700 Also the Code is different, but I don't know what that means. Please note once again: This is _not_ related to NTFS. It happens with ext4 as well. Partition size shouldn't matter, nor the code. 8300 maps to the partition type GUID for Linux volumes, and 0700 maps to the partition type GUID for Microsoft basic data which is what parted has been using for GPT disks since day 1 for some reason. So that shouldn't matter either. Discussed this in the 2013-10-02 Blocker Review Meeting [1]. We need more information and testing to figure out how common this failure mode is. Will re-visit once more testing has been done. [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-10-02/ In comment 15 I have swapped the output of gparted and gnome-disks, I'm sorry. Gparted creates a smaller partition (there is a small space at the end of the disk), gnome-disks creates a fully-sized partition. I reproduced the issue with gdisk. I used gdisk to create a partition with end sector 20969471 -> no crash. Then I deleted the partition and created a new one with end sector 20971486 (last usable sector) -> crash. This seems to be a problem anaconda, it crashes when the partition occupies a completely full size of the disk. Can someone post a URL pointing to (or exact instructions for creating) a disk image file that causes this failure reliably? Created attachment 809836 [details]
bug demonstration video
This is reproduced with F20 Beta TC2 Live x86_64.
Discussed this in 2013-10-09 Blocker Review Meeting [1]. Voted an AcceptedBlocker as it violates the following F20 beta release criterion for partitions not created using parted: "When using the guided partitioning flow, the installer must be able to ... Complete an installation using any combination of disk configuration options it allows the user to select" [2] [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-10-09/ [2] https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria#Guided_partitioning Discussed at 2013-10-16 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-10-16/f20beta-blocker-review-4.2013-10-16-16.02.log.txt . We agreed to move this to be a Final blocker. The criterion cited in c#22 was not intended to cover shrinking from the 'reclaim space' screen, it is more about the 'installation options' screen: the criteria were in fact intended to specifically exclude shrinking from being required to work at Beta, and require it to work to a certain degree at Final. https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria#Storage_volume_resize "Any installer mechanism for resizing storage volumes must correctly attempt the requested operation." Weird bug. I can reproduce this in qemu/kvm. If crash will occur, it happens within a few seconds of clicking the shrink button, the slider UI does not appear. With gparted, no crash. With gdisk created partition + mkfs.ext4 = crash. If I start with the working gparted result, and change the partitiontypeGUID from 0700 to 8300, no crash. If I reformat using mkfs.ext4, no crash. So there's something specific about the partition size I think; possibly the fact gnome-disk and gdisk are leaving some space at the end of the block device before the backupt GPT? Odd bug. Status reviewed at 2013-11-20 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-11-20/f20-blocker-review.2013-11-20-17.00.log.txt . This bug seems to be clearly defined and reproducible and is now just waiting in the queue to be fixed by anaconda devs. Based on the data from comment 15 gnome-disks aligns the end of the partition, while gparted does not. From what I can tell it has nothing to do with the contents of the partition -- only the partition itself. I am interested to see if the fix for bug 1034232 also resolves this one, so someone please try it once that fix becomes available. Vratislav created http://vpodzime.fedorapeople.org/1008965_updates.img which should contain the fix from bug 1034232 against TC3. With that applied, I was able to create a new ext4 partition in gnome-disks, shrink it in anaconda and proceed in installation. Please push to f20 branch. python-blivet-0.23.7-1.fc20, anaconda-20.25.12-1.fc20, pykickstart-1.99.48-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/FEDORA-2013-21928/pykickstart-1.99.48-1.fc20,python-blivet-0.23.7-1.fc20,anaconda-20.25.12-1.fc20 python-blivet-0.23.7-1.fc20, anaconda-20.25.12-1.fc20, pykickstart-1.99.48-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report. I used TC3, updated anaconda to 20.25.12-1 and reproduced the steps. The problem is fixed. Possible dup bug 1038847 has appeared proposed as blocker, same summary different abrt hash. Regression or different entirely? (In reply to Chris Murphy from comment #31) > Possible dup bug 1038847 has appeared proposed as blocker, same summary > different abrt hash. Regression or different entirely? In my completely uninformed point of view this is entirely different. (In reply to Kamil Páral from comment #32) > (In reply to Chris Murphy from comment #31) > > Possible dup bug 1038847 has appeared proposed as blocker, same summary > > different abrt hash. Regression or different entirely? > > In my completely uninformed point of view this is entirely different. Agreed, that's an entirely different thing. |