I did some tests on how to rung gumd in the MIC-CHROOT environment and it looks
like gumd (or more likely gum-utils) won't work well with
qemu emulation.
It looks like some socket options set and used by gumd (gio/glib) cause
problems with writing to the socket.
A connection can be established but no data passes through the socket. This is
a strace of the qemu running the MIC chroot:
[pid 4940] connect(4, {sa_family=AF_FILE,
sun_path="/root/.cache/gumd/bus-sock"}, 110) = 0
[pid 4938] <... poll resumed> ) = 1 ([{fd=4, revents=POLLIN}])
[pid 4938] read(3, 0x7eff0a76c608, 16) = -1 EAGAIN (Resource temporarily
unavailable)
[pid 4938] write(3, "\1\0\0\0\0\0\0\0", 8) = 8
[pid 4938] write(3, "\1\0\0\0\0\0\0\0", 8) = 8
[pid 4938] clock_gettime(CLOCK_MONOTONIC, {190173, 584805428}) = 0
[pid 4938] poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}], 2, -1) = 1
([{fd=4, revents=POLLIN}])
[pid 4938] accept4(4, 0, NULL, 0) = 7
[pid 4938] fcntl(7, F_GETFD) = 0
[pid 4938] fcntl(7, F_SETFD, FD_CLOEXEC) = 0
[pid 4938] getsockopt(7, SOL_SOCKET, SO_TYPE, [1], [4]) = 0
[pid 4938] getsockname(7, {sa_family=AF_FILE,
sun_path="/root/.cache/gumd/bus-sock"}, [29]) = 0
[pid 4938] getpeername(7, {sa_family=AF_FILE, NULL}, [2]) = 0
[pid 4938] getsockopt(7, SOL_SOCKET, SO_KEEPALIVE, [0], [4]) = 0
[pid 4938] fcntl(7, F_GETFL) = 0x2 (flags O_RDWR)
[pid 4938] fcntl(7, F_SETFL, O_RDWR|O_NONBLOCK) = 0
[pid 4938] clock_gettime(CLOCK_MONOTONIC, {190173, 590249707}) = 0
[pid 4940] geteuid() = 0
[pid 4940] getegid() = 0
[pid 4940] geteuid() = 0
[pid 4940] getegid() = 0
[pid 4940] clock_gettime(CLOCK_MONOTONIC, {190173, 592245553}) = 0
[pid 4940] poll([{fd=4, events=POLLOUT}], 1, -1) = 1 ([{fd=4,
revents=POLLOUT}])
[pid 4940] write(2, "Unsupported ancillary data: 1/2\n", 32) = 32
[pid 4940] sendmsg(4, {msg_name(0)=NULL, msg_iov(1)=[{"\0", 1}],
msg_controllen=32, {cmsg_len=28, cmsg_level=SOL_SOCKET,
cmsg_type=SCM_CREDENTIALS{pid=4940, uid=0, gid=0}}, msg_flags=0}, MSG_NOSIGNAL) = 1
[pid 4940] clock_gettime(CLOCK_MONOTONIC, {190173, 593237340}) = 0
[pid 4940] poll([{fd=4, events=POLLOUT}], 1, -1) = 1 ([{fd=4,
revents=POLLOUT}])
[pid 4940] sendto(4, "AUTH\r\n", 6, MSG_NOSIGNAL, NULL, 0) = 6
[pid 4940] clock_gettime(CLOCK_MONOTONIC, {190173, 593926997}) = 0
[pid 4940] poll([{fd=4, events=POLLIN}], 1, -1 <unfinished ...>
[pid 4938] mmap(0x7eff0896d000, 8388608, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7eff0896d000
[pid 4938] mmap(NULL, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x7efe136a2000
[pid 4938] mmap(NULL, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x7efe1369a000
[pid 4938] mprotect(0x7eff0896d000, 4096, PROT_NONE) = 0
[pid 4938] mmap(NULL, 151552, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x7efe13675000
[pid 4938] brk(0x639b1000) = 0x639b1000
[pid 4938] rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 8) = 0
[pid 4938] mmap(NULL, 266240, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7efe13634000
[pid 4938] mprotect(0x7efe13634000, 4096, PROT_NONE) = 0
[pid 4938] clone(Process 4941 attached
child_stack=0x7efe13673e30,
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
parent_tidptr=0x7efe136749d0, tls=0x7efe13674700,
[pid 4941] set_robust_list(0x7efe136749e0, 24 <unfinished ...>
[pid 4938] rt_sigprocmask(SIG_SETMASK, [], <unfinished ...>
The line: "Unsupported ancillary data: 1/2" is a log from qemu so that leads me
to think that this might be the issue.
Anyway when testing everything works until you actually want to communicate
using gum-utils, you get a timeout each time trying to execute any action.
best regards
Roman KUbiak
Hello,
Thanks for the suggestions. I'll gladly check out the p2p DBUS solution.
If this doesn't work, we can also try to make a development tool
which somehow directly links to gumd (or libgum) and is used only during
image creation. Just a rough idea.
On 22.09.2014 15:49, Zaman, Imran wrote:
/ Hi
/>/
/>/ As jussi highlighted below, gumd release has been pushed to Tizen with the
required changes (updated gumd should end up in Tizen in a day or two hopefully)
/>/
/>/ Krzysztof, you can try out (p2p) gumd (version 0.0.5) at image creation
time:
/>/ 1- export GUM_BUS_TYPE=p2p; and
/>/ 2- start gumd daemon manually before calling gum-util (it doesn't need
dbus-daemon running)
/>/
/>/ Please let us know if you need any help in using gumd.
/>/
/>/ BR
/>/ imran
/>/ ________________________________________
/>/ From: Dev [dev-bounces at lists.tizen.org
<https://lists.tizen.org/listinfo/dev>] on behalf of Jussi Laako [jussi.laako at
linux.intel.com <https://lists.tizen.org/listinfo/dev>]
/>/ Sent: 19 September 2014 17:24
/>/ To:dev at lists.tizen.org <https://lists.tizen.org/listinfo/dev>
/>/ Subject: Re: [Dev] Gumd usage in building images
/>/
/>/ Since gumd supports both p2p dbus and system bus, we just added support
/>/ to override the configured default using environment variable. If you
/>/ set GUM_BUS_TYPE=p2p and start the daemon manually before calling
/>/ gum-util it doesn't need dbus-daemon running. This still won't affect
/>/ the system-bus auto-invocation on the final install.
/>/
/>/ We'll make a new release today with this change.
/>/
/>>/ 2) come up with some 'first boot/configure target' that runs gumd user
/>>/ config defined by tizen-<profile>-user-config package
/>>/
/>>/ The latter would be generic for all first boot configs.
/>/ This is good idea, we'll look into it. Cleans up some cases where salts
/>/ are used as the hash salts would be different on each result instead of
/>/ being static on the same image.
/>/
/>/ Of course there are number of first boot items where similar is already
/>/ used/needed, such as generating sshd host keys...
/>/
/>/ _______________________________________________
/>/ Dev mailing list
/>/ Dev at lists.tizen.org <https://lists.tizen.org/listinfo/dev>
/>/ https://lists.tizen.org/listinfo/dev
/>/ ---------------------------------------------------------------------
/>/ Intel Finland Oy
/>/ Registered Address: PL 281, 00181 Helsinki
/>/ Business Identity Code: 0357606 - 4
/>/ Domiciled in Helsinki
/>/
/>/ This e-mail and any attachments may contain confidential material for
/>/ the sole use of the intended recipient(s). Any review or distribution
/>/ by others is strictly prohibited. If you are not the intended
/>/ recipient, please contact the sender and delete all copies.
/>/
/>/
/
--
Samsung Enterprise Portal mySingle
Samsung_Logo_for_Mail_Signature
Krzysztof Sasiak
Samsung R&D Institute Poland
Samsung Electronics
k.sasiak at samsung.com <https://lists.tizen.org/listinfo/dev>
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev