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
Created attachment 1025088 [details] File: anaconda-tb
Created attachment 1025089 [details] File: anaconda.log
Created attachment 1025090 [details] File: dnf.log
Created attachment 1025091 [details] File: environ
Created attachment 1025092 [details] File: lsblk_output
Created attachment 1025093 [details] File: nmcli_dev_list
Created attachment 1025094 [details] File: os_info
Created attachment 1025095 [details] File: program.log
Created attachment 1025096 [details] File: storage.log
Created attachment 1025097 [details] File: syslog
Created attachment 1025098 [details] File: ifcfg.log
Created attachment 1025099 [details] File: packaging.log
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
Created attachment 1028110 [details] anaconda traceback
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
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
I tried more size targets, resizing to 7.7 and 7.6 GB crashed, 7.5 GB worked.
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?
"(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.
(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.
(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.
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.
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.
libblockdev-0.13-2.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/libblockdev-0.13-2.fc22
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
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).
This seems to be fixed with RC3.
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.