This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1264571 - kickstart fails on 32 bit arches unless pesize is 1KiB
kickstart fails on 32 bit arches unless pesize is 1KiB
Status: NEW
Product: Fedora
Classification: Fedora
Component: pygobject3 (Show other bugs)
25
i386 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Colin Walters
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-18 16:33 EDT by John Hebron
Modified: 2017-10-11 08:58 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-07-19 13:56:58 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
tarball with a reproducer sources, shell script to build it plus a python test script showing the behaviour (1.34 KB, application/x-gzip)
2015-09-21 08:47 EDT, Vratislav Podzimek
no flags Details

  None (edit)
Description John Hebron 2015-09-18 16:33:06 EDT
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
Comment 1 Vratislav Podzimek 2015-09-21 08:41:05 EDT
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.
Comment 2 Vratislav Podzimek 2015-09-21 08:47 EDT
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]
Comment 3 Vratislav Podzimek 2015-09-21 08:49:11 EDT
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).
Comment 4 Rickard von Essen 2015-11-04 05:04:01 EST
Also effects Fedora 23
Comment 5 Dennis Gilmore 2016-01-22 11:08:01 EST
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
Comment 6 Fedora Admin XMLRPC Client 2016-01-27 12:42:46 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 7 Fedora Admin XMLRPC Client 2016-01-27 12:58:59 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 8 Fedora Admin XMLRPC Client 2016-01-27 12:59:58 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 9 Fedora Admin XMLRPC Client 2016-01-27 13:12:00 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 10 Fedora End Of Life 2016-07-19 13:56:58 EDT
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.
Comment 11 John Hebron 2016-09-22 17:06:46 EDT
This bug still exists in Fedora 24.  Same symptoms exactly.
Comment 12 Anders Blomdell 2017-05-18 12:46:51 EDT
This bug still exists in Fedora 25.  Same symptoms exactly.
Comment 13 Fedora End Of Life 2017-07-25 15:17:49 EDT
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.

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