If you have a call to gumd somewhere in the kickstart and it's not
working (as you wrote) it's haning the "RUnning scripts" parts of the
kickstart, and since it's buffered you won't see what is happening
before unless you kill the qemu process that is emulating your
gumd/gum-utils in mic
try ps axuw | grep qemu
and see if it's running gumd/gum-utils if so kill it, it should continue
with other scripts in the kickstart
then just remove it from the ks file.
On 10/23/2014 04:46 PM, Zaman, Imran wrote:
Hi Rafal!
Rafal, I have pushed the changes for libgum/gum-utils offline support.
Patrick, sysroot support is also added to 'offline' mode.
Both the changes should be available in the next image.
Roman, I have removed offline support from gumd daemon as it was not needed..
So either libgum can be used with offline param for synchronous APIs.. or use
gum-utils with offline command line argument like:
gum-utils -o -a --username=user1 --usertype=4
Please let me know if you find any issues.
Roman, I will try to work on the bug on next thursday as I am off for 3 days
(you can try gumd 1.0.0 and use gum-utils in mic; i guess the problem will be
there still).
It may have to do with glib but lets see if we can figure it out..
Btw i m not able to create images any more so cant try out things on my own for
mic :-( some how it get stuck at the following stage and does not proceed
further. Any idea?
...
INFO: Installing: pciutils ++++++++++++++++++++++++++++++
[154/170]
INFO: Installing: pam-locale ++++++++++++++++++++++++++++++
[155/170]
INFO: Installing: sudo ++++++++++++++++++++++++++++++
[156/170]
INFO: Installing: glibc-locale +++++++++++++++++++++++++++++++
[157/170]
INFO: Installing: tzdata +++++++++++++++++++++++++++++++
[158/170]
INFO: Installing: rsync +++++++++++++++++++++++++++++++
[159/170]
INFO: Installing: unzip +++++++++++++++++++++++++++++++
[160/170]
INFO: Installing: zip +++++++++++++++++++++++++++++++
[161/170]
INFO: Installing: rfkill ++++++++++++++++++++++++++++++++
[162/170]
INFO: Installing: diffutils ++++++++++++++++++++++++++++++++
[163/170]
INFO: Installing: patch ++++++++++++++++++++++++++++++++
[164/170]
INFO: Installing: tree ++++++++++++++++++++++++++++++++
[165/170]
INFO: Installing: tar ++++++++++++++++++++++++++++++++
[166/170]
INFO: Installing: tizen-release +++++++++++++++++++++++++++++++++
[167/170]
INFO: Installing: linux-firmware +++++++++++++++++++++++++++++++++
[168/170]
INFO: Installing: meta-generic-adaptat +++++++++++++++++++++++++++++++++
[169/170]
INFO: Installing: default-ac-domains ++++++++++++++++++++++++++++++++++
[170/170]
INFO: Applying configurations ...
INFO: Running scripts ...
BR
imran
________________________________________
From: Dev [[email protected]] on behalf of Zaman, Imran
[[email protected]]
Sent: 20 October 2014 18:54
To: Rafał Krypa
Cc: [email protected]
Subject: Re: [Dev] Gumd usage in building images
Hi Rafal!
I have started working on making libgum work in offline mode. Its doable and I
should come back to you within 2-3 days.
I will also add support for "offline" to gum-utils. One thing to keep in mind
is that you guys should use libgum (with offline support) instead of gum-utils to avoid
cases like error handling etc.
The way I will change libgum is that user should specify the offline mode when
calling the APIs at object creation time.
e.g. GumUser * gum_user_get_sync (gboolean offline, uid_t uid);
Its better to let the 'user' of the 'libgum'/'gum-utils' to decide whether it
wants offline mode or not rather than automagically switching to one or the
other mode on the fly.
Btw how do you detect if a daemon is running or not? iterating through 'proc'
may not be the best solution that can work out in environments like yocto or at
image creation time.
BR
imran
________________________________________
From: Rafał Krypa [[email protected]]
Sent: 17 October 2014 20:25
To: Zaman, Imran
Cc: Ohly, Patrick; [email protected]; [email protected];
[email protected]
Subject: Re: [Dev] Gumd usage in building images
On 2014-10-17 16:14, Zaman, Imran wrote:
Hi Rafal/Roman!
I agree with patrick, and consequently:
In order to make life easier, I have added "offline" support in gumd, which
means that gumd can be run as simple binary to add/del/update/get user/group.
No (p2p) dbus is needed.
offline mode: user will be added and gumd will exit immediately
# gumd -o -a --username=user1 --usertype=4 (e.g.)
This is fine and solves the problem. But I'd like to suggest other approach,
already mentioned by Patrick:
For gumd, a mode where the client tool embeds the daemon code directly
would be the best solution IMHO.
This is the same approach that we used in cynara and security-manager. It
greatly simplifies usage of the client library, making the client work (to some
extent) in the same way for both off-line and on-line modes.
The exact approach we used was to:
- move some parts of the deamon code to a separate library
- link daemon with it to keep it working as usual
- link client with it to enable offline mode
- inside client implementation, if daemon is not running, invoke the target
routines directly instead of sending requests to daemon
What do you think about doing something similar for gumd? This would allow simple usage
of "gum-utils" during both image-creation time and run-time.
Best regards,
Rafal Krypa
non-offline mode (it needs either p2p dbus or system bus):
# gumd
The changes have already been merged and pushed to tizen, and should show up in
next Tizen common release (hopefully on monday).
Please make sure that you use gumd with version 0.0.6.
Roman, please test user creation at image level with gumd 0.0.6 and let me know
if you face any issues.
BR
imran
________________________________________
From: Dev [[email protected]] on behalf of Patrick Ohly
[[email protected]]
Sent: 17 October 2014 10:37
To: [email protected]
Subject: Re: [Dev] Gumd usage in building images
On Fri, 2014-10-17 at 09:18 +0200, Dominig ar Foll (Intel OTC) wrote:
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.
For those not familiar with Yocto, some background:
* Tools manipulating the root filesystem typically get compiled
for the host system (for example, your Intel-based laptop
running some Linux distro) and then get invoked to modify files
used in the target (for example, ARM). Make sure that your files
don't have architecture dependencies (LSB vs. MSB, 32 vs 64).
* If that's not possible, tools are run under qemu.
* chroot is not used (because it would require root privileges),
so tools need to support manipulating files not at their final
destination (for example, tmp/sysroot/usr/ instead of /usr).
* The environment prepared for the tools only consists of env
variables. There's no concept of spawning additional daemons
(doesn't matter whether it's dbus-daemon or gumd).
For gumd, a mode where the client tool embeds the daemon code directly
would be the best solution IMHO. A --sysroot parameter similar to gcc
would probably be useful/needed, too.
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
[email protected]
https://lists.tizen.org/listinfo/dev
