The lvcreate, lvresize and some other commands needlessly fail with an error that the passed size (-L) is not a multiple of 512 if such a number is passed as a requested size in bytes. While I understand the resulting size has to be a multiple of 512 the error message doesn't make much sense in case of lvcreate, lvresize and other commands because all of them round the requested size to a multiple of extent size anyway. So such commands fail when parsing the command line arguments while they could just proceed to the phase where the size is rounded to a number of extents without any difference. Just like it does if for example 5.6G is passed instead of 6012954214B (== 5.6 * 1024**3). +++ This bug was initially created as a clone of Bug #1221247 +++ Description of problem: I manually created partitions from two disks on a KVM virtual machine (x86_64): 1) 500MB local disk (VirtIO) 2) 20GB iSCSI disk on remote hardware NAS The partitions were as follows: * 500MB on /boot ext4 on virtio disk. * 7.51 GB on / on iSCSI disk * 10.00 GB on /home on iSCSI disk Error occurred as installation began. Version-Release number of selected component: anaconda-22.20.12-1 The following was filed automatically by anaconda: anaconda 22.20.12-1 exception report Traceback (most recent call first): File "/usr/lib64/python2.7/site-packages/gi/overrides/BlockDev.py", line 384, in wrapped raise transform[1](msg) File "/usr/lib/python2.7/site-packages/blivet/devices/lvm.py", line 696, in resize blockdev.lvm.lvresize(self.vg.name, self._name, self.size) File "/usr/lib/python2.7/site-packages/blivet/deviceaction.py", line 457, in execute self.device.resize() File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 362, in processActions action.execute(callbacks) File "/usr/lib/python2.7/site-packages/blivet/blivet.py", line 162, in doIt self.devicetree.processActions(callbacks) File "/usr/lib/python2.7/site-packages/blivet/osinstall.py", line 1057, in turnOnFilesystems storage.doIt(callbacks) File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 196, in doInstall turnOnFilesystems(storage, mountOnly=flags.flags.dirInstall, callbacks=callbacks_reg) File "/usr/lib64/python2.7/threading.py", line 766, in run self.__target(*self.__args, **self.__kwargs) File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 244, in run threading.Thread.run(self, *args, **kwargs) LVMError: Process reported exit code 768: Size is not a multiple of 512. Try using 8063800832 or 8063801344. Invalid argument for --size: 8063801098b Error during parsing of command line. Additional info: addons: com_redhat_kdump cmdline: /usr/bin/python2 /sbin/anaconda cmdline_file: BOOT_IMAGE=vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=Fedora-22_T3-x86_64 quiet dnf.rpm.log: May 13 14:48:33 INFO --- logging initialized --- executable: /sbin/anaconda hashmarkername: anaconda kernel: 4.0.1-300.fc22.x86_64 product: Fedora release: Cannot get release name. type: anaconda version: 22 --- Additional comment from Stephen Gallagher on 2015-05-13 10:55:32 EDT --- --- Additional comment from Stephen Gallagher on 2015-05-13 10:55:34 EDT --- --- Additional comment from Stephen Gallagher on 2015-05-13 10:55:35 EDT --- --- Additional comment from Stephen Gallagher on 2015-05-13 10:55:36 EDT --- --- Additional comment from Stephen Gallagher on 2015-05-13 10:55:36 EDT --- --- Additional comment from Stephen Gallagher on 2015-05-13 10:55:37 EDT --- --- Additional comment from Stephen Gallagher on 2015-05-13 10:55:38 EDT --- --- Additional comment from Stephen Gallagher on 2015-05-13 10:55:39 EDT --- --- Additional comment from Stephen Gallagher on 2015-05-13 10:55:41 EDT --- --- Additional comment from Stephen Gallagher on 2015-05-13 10:55:42 EDT --- --- Additional comment from Stephen Gallagher on 2015-05-13 10:55:43 EDT --- --- Additional comment from Stephen Gallagher on 2015-05-13 10:55:44 EDT --- --- Additional comment from Kamil Páral on 2015-05-21 08:01:19 EDT --- Another user experienced a similar problem: I tried to reproduce bug 1211746 comment 25 with RC2. It did not crash during partitioning, so I accepted it and tried to run a new installation. Crashed immediatelly after beginning. addons: com_redhat_kdump cmdline: /usr/bin/python2 /sbin/anaconda cmdline_file: BOOT_IMAGE=vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=Fedora-22-x86_64 quiet dnf.rpm.log: May 21 11:56:25 INFO --- logging initialized --- hashmarkername: anaconda kernel: 4.0.2-300.fc22.x86_64 package: anaconda-22.20.13-1 product: Fedora release: Cannot get release name. version: 22 --- Additional comment from Kamil Páral on 2015-05-21 08:03:43 EDT --- --- Additional comment from Kamil Páral on 2015-05-21 08:20:06 EDT --- Another user experienced a similar problem: I seem to trigger this every time I shrink my existing 1 GB LV partition to a 0.8 GB partition. The size gets rewritten to 819.2 MB. I confirm that, start installation, and it crashes. addons: com_redhat_kdump cmdline: /usr/bin/python2 /sbin/anaconda cmdline_file: BOOT_IMAGE=vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=Fedora-22-x86_64 quiet dnf.rpm.log: May 21 12:16:48 INFO --- logging initialized --- hashmarkername: anaconda kernel: 4.0.2-300.fc22.x86_64 package: anaconda-22.20.13-1 product: Fedora release: Cannot get release name. version: 22 --- Additional comment from Kamil Páral on 2015-05-21 08:32:59 EDT --- I have also reproduced this when resizing an existing 8.4 GB LV partition to 7.8 GB partition (ext4 reformat). It seems this is very easy to stumble upon - just attempt to resize LV and be unlucky about the specified size (not sure how much unlucky you need to get, but it seems to happen quite often). Proposing as a blocker bug: "Any installer mechanism for resizing storage volumes must correctly attempt the requested operation. " https://fedoraproject.org/wiki/Fedora_22_Final_Release_Criteria#Storage_volume_resize --- Additional comment from Kamil Páral on 2015-05-21 09:04:41 EDT --- I tried more size targets, resizing to 7.7 and 7.6 GB crashed, 7.5 GB worked. --- Additional comment from Kevin Fenzi on 2015-05-21 09:42:07 EDT --- This is only in manual? ie: https://fedoraproject.org/wiki/QA:Testcase_partitioning_guided_shrink?rd=QA:Testcase_Anaconda_autopart_(shrink)_install passes ok? Also, I assume if you reboot after a crash the partition(s) are not resized? ie, you could reboot and try again? --- Additional comment from Stephen Gallagher on 2015-05-21 11:23:29 EDT --- "(11:21:21 AM) vpodzime: sgallagh: for it to be triggered, user needs to resize LVs and the target size has to be not a multiple of 512 bytes." That sounds like it has to be manual and specifically when resizing an existing LVM partition. I'd be okay with documenting this in Common Bugs just in case, but I'd guess this would be a rare occurrence outside of release validation testing. So I'm -1 blocker. --- Additional comment from Kamil Páral on 2015-05-21 11:53:03 EDT --- (In reply to Kevin Fenzi from comment #18) > This is only in manual? It seems so. In guided mode you can't resize LVs. > > Also, I assume if you reboot after a crash the partition(s) are not resized? > ie, you could reboot and try again? Unfortunately, not that easy. Depending on the order of partitions, some operations already happened before the resize occurred. So the disk has been altered and it's not in the same state it was before. You can definitely try again (and see the same crash again, if you pick the same size). But it's "either we install correctly or your old system is intact". This is more like "we crash and your old system is probably already destroyed". (In reply to Stephen Gallagher from comment #19) > "(11:21:21 AM) vpodzime: sgallagh: for it to be triggered, user needs to > resize LVs and the target size has to be not a multiple of 512 bytes." The user picks sizes like 7.8 GB, which *is* a multiple of 512 bytes. Anaconda just computes it incorrectly. There seems to be little the user can do about it (maybe except specifying the size in bytes, if anaconda allows that). > > That sounds like it has to be manual and specifically when resizing an > existing LVM partition. I'd be okay with documenting this in Common Bugs > just in case, but I'd guess this would be a rare occurrence outside of > release validation testing. I do not share that opinion. LV resize is a very common operation, in my view. If you want to install a new system, you often need to shrink existing partitions to make room for it. > > So I'm -1 blocker. It's going to be difficult to fudge the criterion, because it's quite clear and obvious violation of it, I believe. On top of that, there's very real possibility of data loss. Not just that we don't install correctly, we also destroy some data. --- Additional comment from Kamil Páral on 2015-05-21 12:33:03 EDT --- (In reply to Kamil Páral from comment #20) > The user picks sizes like 7.8 GB, which *is* a multiple of 512 bytes. I was wrong (because I used GiB not GB). Thanks to vpodzime for finding the algorithm in anaconda. It seems to work like this (with an example of 8.6), if you specify GiB or G: <vpodzime> In [3]: int(8.6 * 1024**3) / 512.0 <vpodzime> Out[3]: 18035507.19921875 And if you specify GB: <vpodzime> In [4]: int(8.6 * 1000**3) / 512.0 <vpodzime> Out[4]: 16796875.0 After hacking up a simple script, these values seem to safe: - For G or GiB: * everything that ends in .0, .25, .50 or .75 - For GB: * every multiple of 0.04, so .0, .04, .08, .12, .16, etc Unsafe is everything else, so e.g. "8.2 GiB", "2.6 G", or "10.5 GB". Provided I haven't made any mistake. --- Additional comment from David Lehman on 2015-05-21 12:44:22 EDT --- Using decimal units doesn't make much sense for storage at all given that sectors are 512b. That's why the only way to get decimal units is to specify them explicitly. No unit gets you MiB, "g" gets you GiB, &c. --- Additional comment from Vratislav Podzimek on 2015-05-21 13:25:14 EDT --- This is a bug in the LVM tools (they error out when parsing the options even if they would normally round the size to a multiple of extents later anyway) which can be worked around in libblockdev. --- Additional comment from Fedora Update System on 2015-05-21 13:32:18 EDT --- libblockdev-0.13-2.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/libblockdev-0.13-2.fc22 --- Additional comment from Kamil Páral on 2015-05-21 13:56:57 EDT --- Discussed at today's go/no-go meeting [1]. This bug was accepted as Final Blocker - This bug is a direct violation of the following criterion and has the potential to cause data loss. "Any installer mechanism for resizing storage volumes must correctly attempt the requested operation." [1] http://meetbot.fedoraproject.org/fedora-meeting-2/2015-05-21/f22_final_gono-go_meeting.2015-05-21-17.00.log.txt --- Additional comment from Fedora Update System on 2015-05-21 22:31:13 EDT --- Package libblockdev-0.13-2.fc22: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libblockdev-0.13-2.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-8685/libblockdev-0.13-2.fc22 then log in and leave karma (feedback). --- Additional comment from Kamil Páral on 2015-05-22 04:23:12 EDT --- This seems to be fixed with RC3. --- Additional comment from Fedora Update System on 2015-05-22 15:53:22 EDT --- libblockdev-0.13-2.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to Vratislav Podzimek from comment #0) > Just like it does if for example 5.6G is > passed instead of 6012954214B (== 5.6 * 1024**3). > LVMError: Process reported exit code 768: Size is not a multiple of 512. > Try using 8063800832 or 8063801344. > Invalid argument for --size: 8063801098b > Error during parsing of command line. There's a difference in whether you use decimal point or not when specifying sizes. With the decimal point, the number is always a subject to rounding. On the other hand, if you specify an integer number as size with possible suffix, we consider this as a firm number which is not rounded (rounded here I mean rounded to the 512B multiple). If you define concrete and exact number of bytes, I think LVM behaves fine here as it gives you a pointer that you have specified it incorrectly if not a multiple of 512B. Of course, if you use any of the suffixes (kKmMgGtTpPeE), it's always a multiple of 512B (for lvcreate and similar, the upper-case and lower-case suffix is evaluated the same way and it's always power of 2). Given this, I'm closing this report.
(In reply to Peter Rajnoha from comment #1) > (In reply to Vratislav Podzimek from comment #0) > > Just like it does if for example 5.6G is > > passed instead of 6012954214B (== 5.6 * 1024**3). > > > LVMError: Process reported exit code 768: Size is not a multiple of 512. > > Try using 8063800832 or 8063801344. > > Invalid argument for --size: 8063801098b > > Error during parsing of command line. > > There's a difference in whether you use decimal point or not when specifying > sizes. With the decimal point, the number is always a subject to rounding. > On the other hand, if you specify an integer number as size with possible > suffix, we consider this as a firm number which is not rounded (rounded here > I mean rounded to the 512B multiple). > > If you define concrete and exact number of bytes, I think LVM behaves fine > here as it gives you a pointer that you have specified it incorrectly if not > a multiple of 512B. Of course, if you use any of the suffixes > (kKmMgGtTpPeE), it's always a multiple of 512B (for lvcreate and similar, > the upper-case and lower-case suffix is evaluated the same way and it's > always power of 2). I think these things at least need to be documented somewhere, ideally in the man page as they way they work is not really intuitive.
(In reply to Vratislav Podzimek from comment #2) > (In reply to Peter Rajnoha from comment #1) > > (In reply to Vratislav Podzimek from comment #0) > > > Just like it does if for example 5.6G is > > > passed instead of 6012954214B (== 5.6 * 1024**3). > > > > > LVMError: Process reported exit code 768: Size is not a multiple of 512. > > > Try using 8063800832 or 8063801344. > > > Invalid argument for --size: 8063801098b > > > Error during parsing of command line. > > > > There's a difference in whether you use decimal point or not when specifying > > sizes. With the decimal point, the number is always a subject to rounding. > > On the other hand, if you specify an integer number as size with possible > > suffix, we consider this as a firm number which is not rounded (rounded here > > I mean rounded to the 512B multiple). > > > > If you define concrete and exact number of bytes, I think LVM behaves fine > > here as it gives you a pointer that you have specified it incorrectly if not > > a multiple of 512B. Of course, if you use any of the suffixes > > (kKmMgGtTpPeE), it's always a multiple of 512B (for lvcreate and similar, > > the upper-case and lower-case suffix is evaluated the same way and it's > > always power of 2). > I think these things at least need to be documented somewhere, ideally in > the man page as they way they work is not really intuitive. I agree that man page should be improved to bring clarity to size syntax. I had posted a patch in an attempt to make situation little bit better. https://www.redhat.com/archives/lvm-devel/2015-August/msg00017.html
OK, let's use bug #1224638 to track fixes to documentation about sizes in LVM.
We also have another bug to create lvcreate man page documentation. https://bugzilla.redhat.com/show_bug.cgi?id=1250562