Bug 1221247

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.