https://bugzilla.novell.com/show_bug.cgi?id=832337
https://bugzilla.novell.com/show_bug.cgi?id=832337#c2
Yarny Yarny changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |NEW
InfoProvider|Yarny@public-files.de |
--- Comment #2 from Yarny Yarny 2013-08-14 22:22:51 UTC ---
I put a perl breakpoint in KIWIGlobals.pm in the function callContained, just
before the second lxc-execute (that is line 836 here). Then I manually called
the lxc-execute command -> Nothing.
The perl debugger says $lxcinit=$root/usr/lib64/lxc/lxc-init, and indeed this
file contains my config.sh. So kiwi copied config.sh into
$root/usr/lib64/lxc/lxc-init, but it left $root/usr/lib/lxc/lxc-init untouched.
Then I did
$ cp $root/usr/lib{64,}/lxc/lxc-init
and called the lxc-execute command again -> $root/config.sh.tag is created!
It appears that lxc-execute uses /usr/lib/lxc/lxc-init even on 64bit systems
whereas kiwi prepares /usr/lib64/lxc/lxc-init. The result is lxc-execute just
executing true as instructed by kiwi, which certainly is successful but without
effect.
At this point I don't know how to proceed. The lxc manpage isn't very
talkative about lxc-init and there is not lxc-init manpage. How is lxc-execute
supposed to call lxc-init?
BTW, another issue crossed my mind while reading the kiwi code. Is replacing
lxc-init really the correct way to execute scripts in linux containers? I have
almost no knowledge about linux container technology, but I appears to me that
lxc-init, as it is provided by the lxc package, is not meant to be replaced by
some user-provided script. Wouldn't the replacement of lxc-init in the image
root break lxc-execute in the target system?
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.