Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1375732 - 32-bit installer incorrectly calculates space that will be freed by deleting a PV
Summary: 32-bit installer incorrectly calculates space that will be freed by deleting ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: libbytesize
Version: 26
Hardware: i686
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Vratislav Podzimek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: https://fedoraproject.org/wiki/Common...
Depends On:
Blocks: FE-ExcludeArch-x86, F-ExcludeArch-x86
TreeView+ depends on / blocked
 
Reported: 2016-09-13 20:50 UTC by Adam Williamson
Modified: 2017-09-30 06:29 UTC (History)
8 users (show)

Fixed In Version: libbytesize-1.0-1.fc27
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-09-30 06:29:26 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)
anaconda.log (35.40 KB, text/plain)
2016-09-13 20:52 UTC, Adam Williamson 		no flags Details
program.log (37.06 KB, text/plain)
2016-09-13 21:12 UTC, Adam Williamson 		no flags Details
storage.log (89.87 KB, text/plain)
2016-09-13 21:15 UTC, Adam Williamson 		no flags Details
lvm.log (239.67 KB, text/plain)
2016-09-13 21:16 UTC, Adam Williamson 		no flags Details
View All

Description Adam Williamson 2016-09-13 20:50:32 UTC 
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...
Comment 1 Adam Williamson 2016-09-13 20:52:49 UTC 
Created attachment 1200618 [details]
anaconda.log
Comment 2 Adam Williamson 2016-09-13 21:12:36 UTC 
Created attachment 1200622 [details]
program.log
Comment 3 Adam Williamson 2016-09-13 21:15:26 UTC 
Created attachment 1200627 [details]
storage.log
Comment 4 Adam Williamson 2016-09-13 21:16:43 UTC 
Created attachment 1200628 [details]
lvm.log
Comment 5 Andre Robatino 2016-11-19 17:28:38 UTC 
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?
Comment 6 joerg.lechner 2016-11-24 10:40:27 UTC 
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.
Comment 7 Adam Williamson 2016-11-29 00:42:39 UTC 
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.
Comment 8 Andre Robatino 2016-11-29 00:52:40 UTC 
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).
Comment 9 Adam Williamson 2016-11-29 01:35:38 UTC 
"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.
Comment 10 Adam Williamson 2017-04-05 01:41:16 UTC 
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".
Comment 11 Allan 2017-04-09 14:41:13 UTC 
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.
Comment 12 Allan 2017-07-15 15:07:33 UTC 
Hello today i confirmed this bug persists on Fedora 26 LXQt
Comment 13 Stefan Ring 2017-07-25 22:21:14 UTC 
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.
Comment 14 Adam Williamson 2017-07-25 23:24:18 UTC 
Stefan: thanks a lot for tracking that down!
Comment 15 Jeff Backus 2017-09-11 17:11:56 UTC 
Hi all,

Any update?
Comment 16 Stefan Ring 2017-09-11 21:22:36 UTC 
The fix for libbytesize has just been pushed to master a few days ago: https://github.com/storaged-project/libbytesize/commit/084c04c7be762049f375b424e44b1951b0113404
Comment 17 Fedora Update System 2017-09-14 10:16:46 UTC 
libbytesize-1.0-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-1c03aa9422
Comment 18 Fedora Update System 2017-09-14 18:22:44 UTC 
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
Comment 19 Jeff Backus 2017-09-17 15:17:58 UTC 
Awesome! Thanks for addressing this!
Comment 20 Fedora Update System 2017-09-30 06:29:26 UTC 
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.
Note You need to log in before you can comment on or make changes to this bug.