From: Jack Mitchell <ml@communistcode.co.uk>
To: openembedded-core@lists.openembedded.org
Subject: Re: systemd: /run directory not created
Date: Fri, 22 Feb 2013 14:15:35 +0000 [thread overview]
Message-ID: <51277D87.3090703@communistcode.co.uk> (raw)
In-Reply-To: <512738BF.9000404@communistcode.co.uk>
On 22/02/13 09:22, Jack Mitchell wrote:
> On 21/02/13 22:27, Khem Raj wrote:
>> On (14/02/13 15:44), Jack Mitchell wrote:
>>> On 14/02/13 15:31, Burton, Ross wrote:
>>>> On 14 February 2013 14:31, Jack Mitchell <ml@communistcode.co.uk>
>>>> wrote:
>>>>> Did this ever go anywhere? I have just tried again today with
>>>>> exactly the
>>>>> same result, all I did was change the DISTRO_FEATURES_INITMAN to
>>>>> systemd.
>>>> Odd, as I just built and booted a systemd image (core-image-sato, in
>>>> poky master), and it worked fine.
>>>>
>>>> Ross
>>> I have a custom distro definition that cuts a lot of features out.
>>> Can you find out which package is supposed to create run and I can
>>> check if it is pulled in properly on my setup?
>>>
>>> I think something must be assumed somewhere and I don't have the
>>> features enabled to trigger it.
>> its created by base-files package. If you need hint how it works
>> with systemd take a look at bbappend that angstrom has for base-files
>> in meta-angstrom
> Ah, I see. Thanks Khem.
>
> So, the next question is; how come Angstrom requires these files to be
> appended to base-files in order to get systemd going, when oe-core
> doesn't?
>
> I notice there is:
>
> ${localstatedir}/volatile/run \
>
> In the base-files oe-core package, while in Angstrom we have:
>
> ${localstatedir}/run \
> /run \
>
> I understand oe-core having it as a volatile; but I don't understand
> why it doesn't create the /run directory. I see some kind of logic
> regarding it here:
>
> volatiles = "run log lock tmp"
>
> for d in ${volatiles}; do
> ln -sf volatile/$d ${D}${localstatedir}/$d
> done
>
> However, if it doesn't create the directory on my target filesystem
> then something must be wrong...
>
>
Ok, some oddities and questions.
I have slightly altered the base-files volatiles create loop from:
for d in ${volatiles}; do
ln -sf volatile/$d ${D}${localstatedir}/$d
done
to
for d in ${volatiles}; do
ln -sfv /volatile/$d ${D}/$d
done
Which gives the output:
DEBUG: Executing shell function do_install
'/mnt/SSD/oe-r0005/r0005/tmp/work/beaglebone-oecore-linux-gnueabi/base-files/3.0.14-r73/image/run'
-> '/volatile/run'
'/mnt/SSD/oe-r0005/r0005/tmp/work/beaglebone-oecore-linux-gnueabi/base-files/3.0.14-r73/image/log'
-> '/volatile/log'
'/mnt/SSD/oe-r0005/r0005/tmp/work/beaglebone-oecore-linux-gnueabi/base-files/3.0.14-r73/image/lock'
-> '/volatile/lock'
'/mnt/SSD/oe-r0005/r0005/tmp/work/beaglebone-oecore-linux-gnueabi/base-files/3.0.14-r73/image/tmp/tmp'
-> '/volatile/tmp'
DEBUG: Shell function do_install finished
The oddity is the volatiles variable looks like this:
volatiles = "run log lock tmp"
So why do we get:
'/mnt/SSD/oe-r0005/r0005/tmp/work/beaglebone-oecore-linux-gnueabi/base-files/3.0.14-r73/image/tmp/tmp'
-> '/volatile/tmp'
with /tmp/tmp?
I have also removed the ${localstatedir} otherwise I was getting this:
'/mnt/SSD/oe-r0005/r0005/tmp/work/beaglebone-oecore-linux-gnueabi/base-files/3.0.14-r73/image/var/run'
-> '/volatile/run'
With the extra var/ in. Which would make sense for why I wasn't getting
directories made in the root folder. I suppose the issue is, why was
everyone else?
Can anyone shed any light on this?
--
Jack Mitchell (jack@embed.me.uk)
Embedded Systems Engineer
http://www.embed.me.uk
--
next prev parent reply other threads:[~2013-02-22 14:32 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-23 15:19 systemd: /run directory not created Jack Mitchell
2013-01-24 9:46 ` Radu Moisan
2013-01-24 12:01 ` Burton, Ross
2013-01-24 12:11 ` Radu Moisan
2013-01-24 12:11 ` Burton, Ross
2013-01-24 12:20 ` Enrico Scholz
2013-01-24 12:34 ` Radu Moisan
2013-01-24 12:53 ` Enrico Scholz
2013-01-24 13:03 ` Radu Moisan
2013-01-24 14:52 ` Burton, Ross
2013-01-25 8:28 ` Radu Moisan
2013-02-14 14:31 ` Jack Mitchell
2013-02-14 15:31 ` Burton, Ross
2013-02-14 15:44 ` Jack Mitchell
2013-02-14 15:57 ` Jack Mitchell
2013-02-14 20:23 ` Jack Mitchell
2013-02-21 22:27 ` Khem Raj
2013-02-22 9:22 ` Jack Mitchell
2013-02-22 14:15 ` Jack Mitchell [this message]
2013-02-22 14:50 ` Jack Mitchell
2013-04-15 12:58 ` Jack Mitchell
2013-04-15 13:10 ` Martin Jansa
2013-04-15 13:45 ` Jack Mitchell
2013-05-02 15:01 ` Jonathan Liu
2013-05-02 15:11 ` Jonathan Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51277D87.3090703@communistcode.co.uk \
--to=ml@communistcode.co.uk \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox