I have a test VM with a typical Fedora volume group, containing a root and a swap LV on a single disk. For some reason, the PV/VG is as big as it can be (~19.7GiB on a 20GiB disk), but the root LV is only 3GiB. I don't recall why that would be. Anyhow, if I boot Fedora-Workstation-netinst-x86_64-25-20160912.n.0.iso and go to the 'reclaim space' screen, and choose to delete the PV, it (correctly) calculates that this will reclaim 19.71GiB of space. However, if I boot Fedora-Workstation-netinst-i386-25-20160912.n.0.iso, go to the 'reclaim space' screen, and choose to delete the PV, it (incorrectly) calculates that this will reclaim 3.71GiB of space. This looks like it might be some kind of integer size problem, but I'm guessing. I'm not sure if the exact layout of the VG really matters, just trying to describe the scenario accurately. I don't see much useful in the logs, but I'll attach 'em. I don't know when this problem started happening - unfortunately we don't run the relevant openQA tests on 32-bit. I'm guessing blivet is to blame, but reassign as appropriate. This would be a blocker, but we don't block on i386 any more...
Created attachment 1200618 [details] anaconda.log
Created attachment 1200622 [details] program.log
Created attachment 1200627 [details] storage.log
Created attachment 1200628 [details] lvm.log
I hit this with 25 Final Gold 32-bit, preventing me from installing due to my need for custom partitioning (to get rid of the default /home partition). Maybe a candidate for CommonBugs?
Hi, Old HP Pavilion Laptop, I think 64bit. Tried to install from DVD iso to install F25 i386 LXDE. Reaching in Anaconda the step "Speicherplatz Freigeben (reclaim space in English)" the button "reclaim space" is not lightened, therefore no action on hitting on it. Worthwhile for a bug report? Kind regards - copy from my comment in the lists. is it useful to try to get logs? If yes, please tell which logs.
joerg: I don't think logs are really needed, it's a pretty trivial bug to reproduce. I think it's just not a high priority as i386 isn't release blocking any more. If your system can support x86_64, it's really a good idea to do an x86_64 install, all kinds of upstreams are caring less and less about i386 these days.
Adam: Thanks for adding this to the Common Bugs page. I was hoping other people would hit this, so there might be a fix, but it seems unlikely now. Is this type of bug likely to be caused by something really simple, like using an int instead of a long? I couldn't think of any other reason why a size calculation would work on 64-bit but fail on 32. I'm not comfortable attempting manual partitioning, so I'll just stick to F24 on that machine for now. Maybe do an upgrade eventually (instead of a preferred clean install).
"Is this type of bug likely to be caused by something really simple, like using an int instead of a long?" It'll be something *like* that, but as anaconda and blivet are Python 3, it won't be *exactly* that unless the issue is in a lower layer that's written in C.
Confirmed this is still valid in F26. On the RECLAIM DISK SPACE dialog, a 20GiB drive is correctly show as 20 GiB in size in the tree view, and the summary at bottom-left reads "1 disk; 19.81 GiB reclaimable space (in file systems)", which also looks correct. But choosing to delete all filesystems on the disk results in the bottom right saying "Total selected space to reclaim: 4 GiB".
I can confirm this bug on 32bit Fedora LXDE. I used it on an older machine that cant run anything heavier and the only way to install it was to have anaconda automatically assign partitions. Trying to key them in manually is impossible.
Hello today i confirmed this bug persists on Fedora 26 LXQt
The bug is in libbytesize's Python binding: >>> import bytesize.bytesize >>> bytesize.bytesize.Size(0) + 2**36 Size (0 B) Well, actually it's in the C part of libbytesize, because for example bs_size_add_bytes (responsible for the error shown above) takes a uint64_t, which it happily passes on to mpz_add_ui, which takes an unsigned long, and thus truncation happens. A workaround would be replacing every occurrence of MAXUINT64 in bytesize.py with sys.maxsize. Of course, it would be better fixing the C interface, which would probably take a bit more work. Although, it would mostly consist of replacing uint64_t with unsigned long.
Stefan: thanks a lot for tracking that down!
Hi all, Any update?
The fix for libbytesize has just been pushed to master a few days ago: https://github.com/storaged-project/libbytesize/commit/084c04c7be762049f375b424e44b1951b0113404
libbytesize-1.0-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-1c03aa9422
libbytesize-1.0-1.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-1c03aa9422
Awesome! Thanks for addressing this!
libbytesize-1.0-1.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.