[Dev] Gumd usage in building images

Dominig ar Foll (Intel OTC) dominig.arfoll at fridu.net
Fri Oct 17 07:18:39 GMT 2014


Hello;

when looking at off line mode (use during image creation) remember that 
we have a fast growing community planing to use Yocto and so your 
solution needs to work with Yocto as well.

Dominig ar Foll
Senior Software Architect
Open Source Technology Centre
Intel SSG

Le 16/10/2014 11:10, Roman Kubiak a écrit :
> 1. I don't know if there is a tizen wiki entry on that, i can say that 
> i used a kickstart file from 
> http://download.tizen.org/snapshots/tizen/common/tizen-common_20141004.2/builddata/images/arm-wayland/image-configurations/common-wayland-2parts-armv7l.ks
> (modified it so that it doesn't install all the crosswalk/UI stuff) an 
> entry for MIC is at: 
> https://source.tizen.org/documentation/reference/mic-image-creator 
> once the image is build i used mic to chroot into the built image and test
>
> 2. I;m building the latest Common profile image
>
> 3. No i don't use IRC, you can email me directly, no problem
>
> On 10/16/2014 10:58 AM, Zaman, Imran wrote:
>> 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 [dev-bounces at lists.tizen.org] on behalf of Roman Kubiak [r.kubiak at samsung.com]
>> Sent: 16 October 2014 11:39
>> To:dev at lists.tizen.org
>> 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.
>>
>>
>
> -- 
> --------------
>   Roman Kubiak
> --------------
>
>
> _______________________________________________
> Dev mailing list
> Dev at lists.tizen.org
> https://lists.tizen.org/listinfo/dev



More information about the Dev mailing list