public inbox for openembedded-core@lists.openembedded.org
 help / color / mirror / Atom feed
From: Jonathan Liu <net147@gmail.com>
To: ml@communistcode.co.uk
Cc: openembedded-core@lists.openembedded.org
Subject: Re: systemd: /run directory not created
Date: Fri, 03 May 2013 01:11:14 +1000	[thread overview]
Message-ID: <51828212.6000600@gmail.com> (raw)
In-Reply-To: <512785CE.5020508@communistcode.co.uk>

On 23/02/2013 1:50 AM, Jack Mitchell wrote:
> On 22/02/13 14:15, Jack Mitchell wrote:
>> 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?
>>
>
> Right,
>
> I think it should be this (minus the debug):
>
>   for d in run log tmp lock; do
>     echo ${D}
>     echo $d
>     ln -sfv ${localstatedir}/volatile/$d ${D}/$d
>   done
>
> Which gives:
>
> 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
> '/mnt/SSD/oe-r0005/r0005/tmp/work/beaglebone-oecore-linux-gnueabi/base-files/3.0.14-r73/image/run' 
> -> '/var/volatile/run'
> /mnt/SSD/oe-r0005/r0005/tmp/work/beaglebone-oecore-linux-gnueabi/base-files/3.0.14-r73/image 
>
> log
> '/mnt/SSD/oe-r0005/r0005/tmp/work/beaglebone-oecore-linux-gnueabi/base-files/3.0.14-r73/image/log' 
> -> '/var/volatile/log'
> /mnt/SSD/oe-r0005/r0005/tmp/work/beaglebone-oecore-linux-gnueabi/base-files/3.0.14-r73/image 
>
> tmp
> '/mnt/SSD/oe-r0005/r0005/tmp/work/beaglebone-oecore-linux-gnueabi/base-files/3.0.14-r73/image/tmp/tmp' 
> -> '/var/volatile/tmp'
> /mnt/SSD/oe-r0005/r0005/tmp/work/beaglebone-oecore-linux-gnueabi/base-files/3.0.14-r73/image 
>
> lock
> '/mnt/SSD/oe-r0005/r0005/tmp/work/beaglebone-oecore-linux-gnueabi/base-files/3.0.14-r73/image/lock' 
> -> '/var/volatile/lock'
> DEBUG: Shell function do_install finished
> ~
>
> The only issue I am having is still the double tmp/tmp thing; anyone 
> know why it is doing it? It seems like a weird substitution or 
> something.....
${D}/tmp is a directory that already exists, so the symbolic link is 
created at ${D}/tmp/tmp instead. Probably need to remove /tmp from dirs1777.

Regards,
Jonathan



      parent reply	other threads:[~2013-05-02 15:33 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
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 [this message]

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=51828212.6000600@gmail.com \
    --to=net147@gmail.com \
    --cc=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