On 01/14/2014 03:52 PM, Krzysztof Jackiewicz wrote:
Hi,
Gbs build[1] used with following repo url:
http://download.tizen.org/snapshots/tizen/rd-pq/latest/ modifies
/proc/sys/fs/binfmt_misc/arm. The original contents:
enabled
interpreter /usr/bin/qemu-arm-static
flags:
...
are replaced with:
enabled
interpreter /qemu/qemu-arm-binfmt
flags: P
...
Such interpreter doesn't exist on my local filesystem but there is
/qemu/qemu-arm-binfmt inside gbs chroot.
During initialization gbs reads /<profile>.conf file from chroot. The line
"Runscripts: qemu-accel-armv7l-cross-arm" makes it launch
qemu-accel-armv7l-cross-arm.rpm post installation scripts that perform binfmt modification. It
seems like gbs configuration issue. Can someone verify it?
[1] gbs build -A armv7l --clean --overwrite
Thanks in advance,
--
Krzysztof Jackiewicz
Software Engineer
Samsung R&D Poland
Hi,
Short version:
Not only gbs modifies /proc/sys/fs/binfmt_misc/arm - also mic does. This
makes them conflict in several ways when used for ARM builds:
- gbs build can fail with DB_VERSION_MISMATCH error
- when creating image with mic and using gbs build at the same time
certain packages installed by mic can fail on installation scripts
I don't know if it's possible or practical to make these tools not
modify /proc/sys/fs/binfmt_misc/arm. It would be nice if it was possible
but I'm not too familiar with mic or gbs implementation so it's hard for
me to tell.
However I believe it's possible to make these tools more robust and less
invasive by:
- making them restore /proc/sys/fs/binfmt_misc/arm once they finish
their work
- also, gbs shouldn't modify /proc/sys/fs/binfmt_misc/arm on
qemu-accel-armv7l-cross-arm installation but rather on every gbs build
command (since we never know if /proc/sys/fs/binfmt_misc/arm hasn't been
modified in the meantime)
- they could also use same binfmt_misc ARM configuration (if it's
practical)
Full story:
Yesterday I started investigation of intermittent gbs failure when
building on ARM. People using gbs to build on ARM probably noticed such
error:
[ 6s] [1/95] installing libmagic-data-5.11-3.2
[ 7s] error: db4 error(-30971) from dbenv->open: DB_VERSION_MISMATCH:
Database environment version mismatch
[ 7s] error: cannot open Packages index using db4 - (-30971)
[ 7s] error: cannot open Packages database in /var/lib/rpm
After that build stops and on the next gbs build command environment is
recreated.
It seems like it is also caused by unexpected
/proc/sys/fs/binfmt_misc/arm contents. As you have noticed
/proc/sys/fs/binfmt_misc/arm is modified when
qemu-accel-armv7l-cross-arm.rpm post-installation scripts are run. This
is also problematic for the gbs itself as it expects
/qemu/qemu-arm-binfmt interpreter, but it can also be changed in the
meantime (between gbs build environment is set up and gbs build command
is run).
For example mic create also changes /proc/sys/fs/binfmt_misc/arm, but to
different contents:
enabled
interpreter /usr/bin/qemu-arm
flags:
offset 0
magic 7f454c4601010100000000000000000002002800
mask ffffffffffffff00fffffffffffffffffaffffff
(/usr/bin/qemu-arm doesn't exist either on my host machine by the way)
Another related problem which I noticed is that mic create sometimes
fails because certain packages fail on installation scripts:
INFO: Installing: libsystemd +++++++++ [173/589]
error: %pre(dbus-1.6.12-6.4.armv7l) scriptlet failed, exit status 127
error: dbus-1.6.12-6.4.armv7l: install failed
This also happens because of unexpected binfmt ARM interpreter. When I
start image creation with mic and shortly after I run gbs build which in
turn can recreate build environment and modify ARM interpreter, mic will
end up using /qemu/qemu-arm-binfmt instead of expected /usr/bin/qemu-arm.
So you can see that currently gbs and mic conflict with each other in a
subtle way and it would be nice to make them more robust
My suspicion is that it can be difficult or very impractical to make gbs
and mic not modify /proc/sys/fs/binfmt_misc/arm. If it's possible code
would probably be more complicated and maintainability would suffer.
I suspect however, that at least these tools could save and restore old
version of /proc/sys/fs/binfmt_misc/arm to alleviate negative impact of
this modification.
Also, why mic and gbs use different binfmt_misc configuration? We could
avoid some problems by using common config.
Regards,
--
Jacek Bukarewicz
Samsung R&D Institute Poland
Samsung Electronics
[email protected]
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
