Description of problem: I'm using a kickstart config that is pretty much identical to what I successfully used on Fedora 21, but it fails for Fedora 22 on i386 computers unless the pesize is set to 1KiB. Here's an excerpt from /tmp/anaconda.log on the failed machine: ERR anaconda: storage configuration failed: The following problem occurred on line 27 of the kickstart file: Volume group given physical extent size of "4 MiB", but must be one of: 1 KiB. If I actually specify "--pesize=1" for the volgroup, then the kickstart works, but the resulting filesystem has an insane number of physical extents. The default pesize of 4 MiB worked fine on the same computer with Fedora 21. This problem doesn't happen on x86_64 kickstarts -- only on i386. Version-Release number of selected component (if applicable): anaconda 22.20.13-1.fc22 How reproducible: 100% Steps to Reproduce: 1. Attempt to kickstart an i386 machine with a volgroup using the default pesize. 2. 3. Actual results: kickstart fails. Expected results: kickstart works. Additional info: Excerpt from kickstart that fails on i386 but works on x86_64: ignoredisk --only-use=sda zerombr clearpart --all --initlabel bootloader --location=mbr --timeout=8 --append="rhgb quiet net.ifnames=0 biosdevname=0" part /boot --fstype=ext4 --asprimary --size=1024 part pv.01 --fstype=lvmpv --asprimary --size=1024 --grow volgroup vg_cecm --pesize=4096 pv.01 logvol swap --name=swap --vgname=vg_cecm --size=8192 logvol / --fstype=ext4 --name=root --vgname=vg_cecm --size=61440 logvol /local-scratch --fstype=xfs --name=scratch --vgname=vg_cecm --size=1024 --grow Excerpt from kickstart that works on i386 but has insane number of physical extents: ignoredisk --only-use=sda zerombr clearpart --all --initlabel bootloader --location=mbr --timeout=8 --append="rhgb quiet net.ifnames=0 biosdevname=0" part /boot --fstype=ext4 --asprimary --size=1024 part pv.01 --fstype=lvmpv --asprimary --size=1024 --grow volgroup vg_cecm --pesize=1 pv.01 logvol swap --name=swap --vgname=vg_cecm --size=8192 logvol / --fstype=ext4 --name=root --vgname=vg_cecm --size=61440 logvol /local-scratch --fstype=xfs --name=scratch --vgname=vg_cecm --size=1024 --grow
This is caused by some bug in the GObject introspection layer between libblockdev and python. libblockdev is used to get the list of supported PE sizes, but the GObject introspection layer mangles the list (array of guint64) and returns it as a list of a single item. This is probably caused by the GObject introspection layer ignoring the type of the list (array) and using a 32bit integer type for it on 32bit architectures. I'll attach a rather minimalistic reproducer that shows that the problem is in the GObject introspection layer.
Created attachment 1075519 [details] tarball with a reproducer sources, shell script to build it plus a python test script showing the behaviour Output on a 64bit architecture: adding 1024 adding 2048 adding 4096 adding 8192 adding 16384 adding 32768 adding 65536 adding 131072 adding 262144 adding 524288 adding 1048576 adding 2097152 adding 4194304 adding 8388608 adding 16777216 adding 33554432 adding 67108864 adding 134217728 adding 268435456 adding 536870912 adding 1073741824 adding 2147483648 adding 4294967296 adding 8589934592 adding 17179869184 adding 34359738368 ret2[0]: 1024 ret2[1]: 0 [1024L, 2048L, 4096L, 8192L, 16384L, 32768L, 65536L, 131072L, 262144L, 524288L, 1048576L, 2097152L, 4194304L, 8388608L, 16777216L, 33554432L, 67108864L, 134217728L, 268435456L, 536870912L, 1073741824L, 2147483648L, 4294967296L, 8589934592L, 17179869184L, 34359738368L] output on a 32bit architecture: adding 1024 adding 2048 adding 4096 adding 8192 adding 16384 adding 32768 adding 65536 adding 131072 adding 262144 adding 524288 adding 1048576 adding 2097152 adding 4194304 adding 8388608 adding 16777216 adding 33554432 adding 67108864 adding 134217728 adding 268435456 adding 536870912 adding 1073741824 adding 2147483648 adding 4294967296 adding 8589934592 adding 17179869184 adding 34359738368 ret2[0]: 1024 ret2[1]: 0 [1024L]
Please note that the two 'ret2' lines show the probable reason of the issue -- they "look" at the guint64 array as on a guint32 array (thus the values are 1024 and 0 which is considered to terminate the array).
Also effects Fedora 23
zerombr # Partition clearing information clearpart --all # Disk partitioning information part /boot --fstype="ext4" --size=300 part pv.01 --grow volgroup atomicos pv.01 logvol / --fstype="xfs" --size=3000 --name=root --vgname=atomicos fails on armv7 with The following problem occurred on line 40 of the kickstart file: Volume group given physical extent size of "4 MiB", but must be one of: 1 KiB. even though nothing is specified
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
This bug still exists in Fedora 24. Same symptoms exactly.
This bug still exists in Fedora 25. Same symptoms exactly.
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.