Created attachment 1702420 [details] screencast Description of problem: Boot the installer,set / partition'Device type to Lvm,then change it to Lvm thin provisioning, then change the size of the partition,and you will find the cursor keep rotating Version-Release number of selected component (if applicable): always How reproducible: always Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 1702421 [details] storage.log
Created attachment 1702422 [details] anaconda.log
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle. Changing version to 33.
Inie, thank you for the report! I can't reproduce using both latest master and 33.25, but that's on a everything pxe boot while you had a live cd. I'd like to try reproducing what you had and verifying it's fixed as well. Can you please tell me what version/build/date of live cd you used? FWIW, I really like the videos you make, they make it really easy to see "your perspective".
I can't believe that I have forgotten to put the compose information,sorry about that. Anyway,I reported the bug in 07-26,and I reproduced the bug with Fedora-Workstation-Live-x86_64-Rawhide-20200717.n.0.iso, which is the best media I still keep on my local machine,and I'm gonna to attach a longer video for the reproducer. Btw,the symptom seems get worse with Fedora-Workstation-Live-x86_64-Rawhide-20200811.n.0.iso(and Fedora-Server-dvd-x86_64-Rawhide-20200811.n.0.iso), and guess I need to report a new bug.
Created attachment 1711671 [details] screencast
Created attachment 1711678 [details] screenshot of the pxe boot crash
> I can't reproduce using both latest master and 33.25, but that's on a everything pxe boot while you had a live cd I've tested Fedora-Server(and everything)-x86_64-Rawhide-20200811.n.0,which has 33.25-1 on a beaker server, which performs installation with pxe boot,and it affected by this bug
Created attachment 1711681 [details] everything screenshot
Vojto, I think you return only positive sizes now? Or is this another instance of bug 1853071 and bug 1868623 as you predicted somewhere? --- I managed to reproduce this with latest anaconda. For me the first resize did not break because it was to a smaller size. Resizing to a larger size did crash. I get two error dialogs, like the reporter's screenshots show. What's funny is that resizing down and then incrementally up did not crash, but resizing again down and then back up to the last reached amount did. That is repeatable too. As a precise example, 15.17 -> 13 -> 15 caused the crash in another attempt. I tried to include blivet master in the updates image, which should include the recent fix. But currently that always ends for me in an error popup about broken module dependencies for ***:el :-/ --- The interesting part of the logs (first anaconda-tb-***) that matches the error in reporter's storage.log is probably this: > WARNING org.fedoraproject.Anaconda.Modules.Storage:DEBUG:blivet:vg fedora_fedora has -4 MiB free > WARNING org.fedoraproject.Anaconda.Modules.Storage:WARNING:dasbus.server.handler:The call org.fedoraproject.Anaconda.Modules.Storage.DeviceTree.Scheduler.GetContainerFreeSpace has failed with an exception: > (...) > WARNING org.fedoraproject.Anaconda.Modules.Storage:OverflowError: -4194304 not in range 0 to 18446744073709551615 The second traceback just adds another repetition of the exact same message sequence, it's probably the same error coming through a different module. I think it's interesting that the error always mentions 4 MiB. I read that as the size being off by a single extent. Maybe there's some rounding error somewhere, such as using round instead of math.floor? --- Also related: https://github.com/rhinstaller/anaconda/pull/2748
(In reply to Vladimír Slávik from comment #10) > Vojto, I think you return only positive sizes now? Or is this another > instance of bug 1853071 and bug 1868623 as you predicted somewhere? > I think this is a duplicate of 1868623. The -4 MiB free space appears immediately after recalculating thin metadata size, same as in 1868623. DEBUG:blivet:Recommended metadata size: 8.5078125 MiB DEBUG:blivet:Rounded metadata size to extents: 12 MiB DEBUG:blivet:Adjusting size from 16364 MiB to 16360 MiB ... DEBUG:blivet:fedora_localhost-live size is 20 GiB DEBUG:blivet:vg fedora_localhost-live has -4 MiB free We still consider a negative size to be a valid value. 1868623 was a bug in metadata size calculation, but that doesn't mean it is the only bug or that all negative sizes are bugs.
I am not unable to reproduce using anaconda and blivet master. So I guess this is resolved by the blivet changes Vojta linked - thank you! Thus closing. Please feel free to reopen if needed. *** This bug has been marked as a duplicate of bug 1868623 ***