[Dev] Gbs build messes with binfmt

Krzysztof Jackiewicz k.jackiewicz at samsung.com
Tue Feb 4 08:58:27 GMT 2014


Hi,

 

I just wanted to make sure if anyone is actually dealing (going to deal) with this issue?

 

BRs,

 

Krzysztof Jackiewicz

 

From: dev-bounces at lists.tizen.org [mailto:dev-bounces at lists.tizen.org] On Behalf Of Chen, Gui
Sent: 17 stycznia 2014 06:11
To: Jacek Bukarewicz; dev at lists.tizen.org
Subject: Re: [Dev] Gbs build messes with binfmt

 

Yes, we need to improve this handling in gbs and mic, I agree with the idea that restore binfmt_misc/arm after building.

Thanks very much for your suggestion.

 

From: dev-bounces at lists.tizen.org [mailto:dev-bounces at lists.tizen.org] On Behalf Of Jacek Bukarewicz
Sent: Wednesday, January 15, 2014 8:39 PM
To: dev at lists.tizen.org
Subject: Re: [Dev] Gbs build messes with binfmt

 

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
j.bukarewicz at samsung.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tizen.org/pipermail/dev/attachments/20140204/c0a8fe54/attachment.html>


More information about the Dev mailing list