Bug 1221247 - 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.
Summary: LVMError: Process reported exit code 768: Size is not a multiple of 512. Tr...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: libblockdev
Version: 22
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Vratislav Podzimek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:efc5e4ca209c9c1d105a5379f81...
Depends On:
Blocks: F22FinalBlocker 1224638
TreeView+ depends on / blocked
 
Reported: 2015-05-13 14:55 UTC by Stephen Gallagher
Modified: 2015-05-25 08:38 UTC (History)
9 users (show)

Fixed In Version: libblockdev-0.13-2.fc22
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1224638 (view as bug list)
Environment:
Last Closed: 2015-05-22 19:53:22 UTC


Attachments (Terms of Use)
File: anaconda-tb (560.37 KB, text/plain)
2015-05-13 14:55 UTC, Stephen Gallagher
no flags Details
File: anaconda.log (87.07 KB, text/plain)
2015-05-13 14:55 UTC, Stephen Gallagher
no flags Details
File: dnf.log (8.44 KB, text/plain)
2015-05-13 14:55 UTC, Stephen Gallagher
no flags Details
File: environ (492 bytes, text/plain)
2015-05-13 14:55 UTC, Stephen Gallagher
no flags Details
File: lsblk_output (1.83 KB, text/plain)
2015-05-13 14:55 UTC, Stephen Gallagher
no flags Details
File: nmcli_dev_list (1.05 KB, text/plain)
2015-05-13 14:55 UTC, Stephen Gallagher
no flags Details
File: os_info (443 bytes, text/plain)
2015-05-13 14:55 UTC, Stephen Gallagher
no flags Details
File: program.log (37.61 KB, text/plain)
2015-05-13 14:55 UTC, Stephen Gallagher
no flags Details
File: storage.log (227.41 KB, text/plain)
2015-05-13 14:55 UTC, Stephen Gallagher
no flags Details
File: syslog (65.84 KB, text/plain)
2015-05-13 14:55 UTC, Stephen Gallagher
no flags Details
File: ifcfg.log (2.25 KB, text/plain)
2015-05-13 14:55 UTC, Stephen Gallagher
no flags Details
File: packaging.log (998 bytes, text/plain)
2015-05-13 14:55 UTC, Stephen Gallagher
no flags Details
anaconda traceback (402.06 KB, text/plain)
2015-05-21 12:03 UTC, Kamil Páral
no flags Details

Description Stephen Gallagher 2015-05-13 14:55:30 UTC
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

Comment 1 Stephen Gallagher 2015-05-13 14:55:32 UTC
Created attachment 1025088 [details]
File: anaconda-tb

Comment 2 Stephen Gallagher 2015-05-13 14:55:34 UTC
Created attachment 1025089 [details]
File: anaconda.log

Comment 3 Stephen Gallagher 2015-05-13 14:55:35 UTC
Created attachment 1025090 [details]
File: dnf.log

Comment 4 Stephen Gallagher 2015-05-13 14:55:36 UTC
Created attachment 1025091 [details]
File: environ

Comment 5 Stephen Gallagher 2015-05-13 14:55:36 UTC
Created attachment 1025092 [details]
File: lsblk_output

Comment 6 Stephen Gallagher 2015-05-13 14:55:37 UTC
Created attachment 1025093 [details]
File: nmcli_dev_list

Comment 7 Stephen Gallagher 2015-05-13 14:55:38 UTC
Created attachment 1025094 [details]
File: os_info

Comment 8 Stephen Gallagher 2015-05-13 14:55:39 UTC
Created attachment 1025095 [details]
File: program.log

Comment 9 Stephen Gallagher 2015-05-13 14:55:41 UTC
Created attachment 1025096 [details]
File: storage.log

Comment 10 Stephen Gallagher 2015-05-13 14:55:42 UTC
Created attachment 1025097 [details]
File: syslog

Comment 11 Stephen Gallagher 2015-05-13 14:55:43 UTC
Created attachment 1025098 [details]
File: ifcfg.log

Comment 12 Stephen Gallagher 2015-05-13 14:55:44 UTC
Created attachment 1025099 [details]
File: packaging.log

Comment 13 Kamil Páral 2015-05-21 12:01:19 UTC
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

Comment 14 Kamil Páral 2015-05-21 12:03:43 UTC
Created attachment 1028110 [details]
anaconda traceback

Comment 15 Kamil Páral 2015-05-21 12:20:06 UTC
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

Comment 16 Kamil Páral 2015-05-21 12:32:59 UTC
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

Comment 17 Kamil Páral 2015-05-21 13:04:41 UTC
I tried more size targets, resizing to 7.7 and 7.6 GB crashed, 7.5 GB worked.

Comment 18 Kevin Fenzi 2015-05-21 13:42:07 UTC
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?

Comment 19 Stephen Gallagher 2015-05-21 15:23:29 UTC
"(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.

Comment 20 Kamil Páral 2015-05-21 15:53:03 UTC
(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.

Comment 21 Kamil Páral 2015-05-21 16:33:03 UTC
(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.

Comment 22 David Lehman 2015-05-21 16:44:22 UTC
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.

Comment 23 Vratislav Podzimek 2015-05-21 17:25:14 UTC
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.

Comment 24 Fedora Update System 2015-05-21 17:32:18 UTC
libblockdev-0.13-2.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/libblockdev-0.13-2.fc22

Comment 25 Kamil Páral 2015-05-21 17:56:57 UTC
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

Comment 26 Fedora Update System 2015-05-22 02:31:13 UTC
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).

Comment 27 Kamil Páral 2015-05-22 08:23:12 UTC
This seems to be fixed with RC3.

Comment 28 Fedora Update System 2015-05-22 19:53:22 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.