Thanks Roman for trying it out. I want to look into it. - Do you have some instructions on how to build images somewhere in Tizen wiki that I can use? i.e. I want to try out as well and see if I can resolve the issue somehow. - Which image you are trying to build? IVI? - Are you ##tizen-dev irc channel so that we can communicate easily when we are trying it out?
BR imran ________________________________________ From: Dev [[email protected]] on behalf of Roman Kubiak [[email protected]] Sent: 16 October 2014 11:39 To: [email protected] Subject: Re: [Dev] Gumd usage in building images 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> --------------------------------------------------------------------- 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. _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
