[yocto] Using devtool for adding a systemd service
Zoran Stojsavljevic
zoran.stojsavljevic at gmail.com
Fri Nov 10 06:36:35 PST 2017
Hello Alan,
I would admit that I did not understand the package you would like to use,
and what is the problem with it.
But I, from the back of my mind (somehow) understood that I need to query
the packages I know, and these packages are mandatory for any Linux.
The following I tried on the host system (which is Fedora 26), transcript
follows:
[root at 192 build]# dnf install systemd
Last metadata expiration check: 3:27:32 ago on Fri 10 Nov 2017 11:54:19 AM
CET.
Package systemd-233-7.fc26.x86_64 is already installed, skipping.
Dependencies resolved.
Nothing to do.
Complete!
[root at 192 build]# dnf install systemctl
Last metadata expiration check: 3:27:43 ago on Fri 10 Nov 2017 11:54:19 AM
CET.
No match for argument: systemctl
Error: Unable to find a match
[root at 192 build]# which systemd-*
/usr/bin/which: no systemd-* in
(/home/user/YOCTO/oe_core_embedded/poky/scripts:/home/user/YOCTO/oe_core_embedded/poky/bitbake/bin:/usr/libexec/python2-sphinx:/usr/lib64/qt-3.3/bin:/usr/lib64/ccache:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/user/.local/bin:/home/user/bin)
[root at 192 build]# which systemd-
systemd-analyze systemd-detect-virt
systemd-mount systemd-socket-activate
systemd-ask-password systemd-escape
systemd-notify systemd-stdio-bridge
systemd-cat systemd-firstboot
systemd-nspawn systemd-sysusers
systemd-cgls systemd-hwdb
systemd-path systemd-tmpfiles
systemd-cgtop systemd-inhibit
systemd-resolve systemd-tty-ask-password-agent
systemd-delta systemd-machine-id-setup
systemd-run systemd-umount
[root at 192 build]# which systemctl
/usr/bin/systemctl
[root at 192 build]#
But, in contrary, using the target YOCTO, despite we have there two
packages:
*/meta/recipes-core/systemd/systemd*
*./meta/recipes-core/systemd/systemd-systemctl*
I do not see them presented in the final qemux86-64 build. I'll repeat (target
CLI transcript follows):
sh-4.4# uname -r
4.12.12-yocto-standard
sh-4.4# which systemd
sh-4.4# which systemctl
sh-4.4#
Maybe it is me... But I think somebody should look also to what I wrote,
since I am, maybe, after all, mistaken!?
I really hope I made it very clear.
Thank you,
Zoran Stojsavljevic
On Fri, Nov 10, 2017 at 1:23 PM, Alan Martinovic <alan.martinovic at senic.com>
wrote:
> Hey Zoran,
> this doesn't really have anything to do with my question.
> Would suggest you to rephrase it to make it more clear.
>
> But we have there both packages??? We do, we do?!
>
> Do we really have problem here, YOCTO maintainers??? Please, could you
>> post sound and logical explanation for NOT having these services in the
>> default YOCTO?
>
>
> Also would suggest you perhaps reiterate on your question style a bit,
> it might result in more people responding.
>
> Be Well,
> Alan
>
>
> On Fri, Nov 10, 2017 at 12:41 PM, Zoran Stojsavljevic <
> zoran.stojsavljevic at gmail.com> wrote:
>
>> It is, after all, interesting question, you posted here, Alan!
>>
>> I did something else, very different than you - I did the following!
>>
>> [user at 192 poky]$ pwd
>> /home/user/YOCTO/oe_core_embedded/poky
>> [user at 192 poky]$ find . -name systemd*
>> ./scripts/lib/wic/canned-wks/systemd-bootdisk.wks
>> ./meta-yocto-bsp/lib/oeqa/selftest/cases/systemd_boot.py
>> ./build/tmp/sysroots-components/core2-64/at-spi2-core/usr/lib/systemd
>> ./build/tmp/sysroots-components/core2-64/rpm/usr/lib/rpm-plu
>> gins/systemd_inhibit.so
>> ./meta/lib/oeqa/runtime/cases/systemd.py
>> ./meta/classes/systemd.bbclass
>> ./meta/classes/systemd-boot.bbclass
>> ./meta/recipes-devtools/systemd-bootchart
>> ./meta/recipes-devtools/systemd-bootchart/systemd-bootchart_231.bb
>> ./meta/recipes-core/systemd
>> ./meta/recipes-core/systemd/systemd_234.bb
>> ./meta/recipes-core/systemd/systemd-machine-units_1.0.bb
>> ./meta/recipes-core/systemd/systemd-serialgetty
>> ./meta/recipes-core/systemd/systemd.inc
>> ./meta/recipes-core/systemd/systemd-boot_234.bb
>> ./meta/recipes-core/systemd/systemd-compat-units.bb
>> ./meta/recipes-core/systemd/systemd-systemctl-native.bb
>> ./meta/recipes-core/systemd/systemd
>> ./meta/recipes-core/systemd/systemd-systemctl
>> ./meta/recipes-core/systemd/systemd-serialgetty.bb
>> [user at 192 poky]$
>>
>> But we have there both packages??? We do, we do?!
>>
>> *./meta/recipes-core/systemd/systemd*
>> *./meta/recipes-core/systemd/systemd-systemctl*
>>
>> So, systemd is still present as package in basic poky master tree:
>> ./meta/recipes-core/systemd/systemd
>> ./meta/recipes-core/systemd/systemd-systemctl
>>
>> And, here are the heads from tree posted from the qemux86-64 target
>> (/etc/build/):
>>
>> -----------------------
>> Build Configuration: |
>> -----------------------
>> DISTRO = poky
>> DISTRO_VERSION = 2.4
>> -----------------------
>> Layer Revisions: |
>> -----------------------
>> meta = rocko:65d23bd7986615fdfb0f1717b615534a2a14ab80
>> -- modified
>> meta-poky = rocko:65d23bd7986615fdfb0f1717b615534a2a14ab80 --
>> modified
>> meta-yocto-bsp = rocko:65d23bd7986615fdfb0f1717b615534a2a14ab80 --
>> modified
>>
>> And, when I queried on the QEMU (qemux86-64) target both systemd and
>> systemctl, I get nothing (at all), which is VERY strange!?
>> Target CLI transcript follows:
>>
>> sh-4.4# uname -r
>> 4.12.12-yocto-standard
>> sh-4.4# which systemd
>> sh-4.4# which systemctl
>> sh-4.4#
>>
>> Do we really have problem here, YOCTO maintainers??? Please, could you
>> post sound and logical explanation for NOT having these services in the
>> default YOCTO?
>>
>> Thank you,
>> Zoran
>>
>> On Fri, Nov 10, 2017 at 11:07 AM, Alan Martinovic <
>> alan.martinovic at senic.com> wrote:
>>
>>> Hi,
>>> I need to add a systemd service that needs no additional sources
>>> compiled, but just needs an available command executed at boot.
>>>
>>> I've created a basis for the recipe in my layer:
>>>
>>> nrf52-usb-systemd/
>>> |-- files
>>> | `-- btattach-nrf-acm.service
>>> `-- nrf52-usb-systemd.bb
>>>
>>>
>>> together with a recipe template (nrf52-usb-systemd.bb)
>>> for which I don't know if works yet.
>>>
>>> SUMMARY = "Writes patterns to the fb device"
>>> LICENSE = "MIT"
>>> LIC_FILES_CHKSUM = "file://COPYING.MIT;md5=3da9cf
>>> bcb788c80a0384361b4de20420"
>>>
>>> inherit systemd
>>>
>>> REQUIRED_DISTRO_FEATURES= "systemd"
>>>
>>> SRC_URI = "file://btattach-nrf-acm.service"
>>>
>>> do_install () {
>>>
>>> install -m 0644 ${WORKDIR}/btattach-nrf-acm.service
>>> ${D}${sysconfdir}/systemd/system
>>> }
>>>
>>> NATIVE_SYSTEMD_SUPPORT = "1"
>>> SYSTEMD_PACKAGES = "${PN}"
>>> SYSTEMD_SERVICE_${PN} = "fb-draw.service"
>>>
>>>
>>> I'm not sure I got the install command right and
>>> if the service file is making it way to the proper location.
>>>
>>> Instead of building the whole image, flashing and checking
>>> it out, I would like to test how devtool could help here.
>>>
>>> I execute:
>>>
>>> devtool build nrf52-usb-systemd
>>>
>>> this results in a creation of a workspace with the sources files.
>>> What I am not seeing is a creation of a device sysroot which would
>>> show me that the do_install was correctly written.
>>>
>>> Given that the device sysroot directory on the host would be called
>>> "sysroot" was hoping to be able do confirm that the following took
>>> place
>>>
>>> ${D}${sysconfdir}/systemd/system -> .sysroot/etc/ssytemd/system
>>>
>>> and confirming there is a
>>>
>>> .sysroot/etc/ssytemd/system/btattach-nrf-acm.service
>>>
>>>
>>> Is this possible with devtool, or am I misinterpreting
>>> what it's purpose is?
>>>
>>>
>>> --
>>> _______________________________________________
>>> yocto mailing list
>>> yocto at yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20171110/f501a4dc/attachment.html>
More information about the yocto
mailing list