systemd: /run directory not created

systemd: /run directory not created

[Jack Mitchell]

When I attempt to boot a systemd enabled image I get an error stating 
that the run directory could not be mounted as it doesn't exist. I 
checked the target rootfs and there isn't a /run directory. What is 
responsible for creating this and why is it not doing it's job?

[ 2.631549] systemd[1]: Failed to mount /run: No such file or directory

Possibly of interest is that I am running a custom distro with manually 
specified DISTRO_FEATURES.

-- 

   Jack Mitchell (jack@embed.me.uk)
   Embedded Systems Engineer
   http://www.embed.me.uk

--

Re: systemd: /run directory not created

[Radu Moisan]

On 01/23/2013 05:19 PM, Jack Mitchell wrote:
> When I attempt to boot a systemd enabled image I get an error stating 
> that the run directory could not be mounted as it doesn't exist. I 
> checked the target rootfs and there isn't a /run directory. What is 
> responsible for creating this and why is it not doing it's job?
>
> [ 2.631549] systemd[1]: Failed to mount /run: No such file or directory
>
> Possibly of interest is that I am running a custom distro with 
> manually specified DISTRO_FEATURES.
>

Possibly because /run was a link created by the initscripts which are 
now disabled when systemd is the init manager. I'll look into this and 
update 00-create-volatile.conf so that systemd will handle the link 
creation in stead.

Radu

Re: systemd: /run directory not created

[Burton, Ross]

On 24 January 2013 09:46, Radu Moisan <radu.moisan@intel.com> wrote:
> Possibly because /run was a link created by the initscripts which are now
> disabled when systemd is the init manager. I'll look into this and update
> 00-create-volatile.conf so that systemd will handle the link creation in
> stead.

I wonder how my images booted...  initscripts is sysvinit specific,
the systemd startup should handle this somehow.

(insert standard argument that we should adopt /run across all init systems)

Ross

Re: systemd: /run directory not created

[Radu Moisan]

On 01/24/2013 02:01 PM, Burton, Ross wrote:
> On 24 January 2013 09:46, Radu Moisan <radu.moisan@intel.com> wrote:
>> Possibly because /run was a link created by the initscripts which are now
>> disabled when systemd is the init manager. I'll look into this and update
>> 00-create-volatile.conf so that systemd will handle the link creation in
>> stead.
> I wonder how my images booted...  initscripts is sysvinit specific,
> the systemd startup should handle this somehow.
>
> (insert standard argument that we should adopt /run across all init systems)
>
This is exactly what I was looking for. /run shouldn't be there, yet 
somehow it is. I was looking into how/where systemd is creating /run but 
no lead for now.

Radu

Re: systemd: /run directory not created

[Burton, Ross]

On 24 January 2013 12:11, Radu Moisan <radu.moisan@intel.com> wrote:
> This is exactly what I was looking for. /run shouldn't be there, yet somehow
> it is. I was looking into how/where systemd is creating /run but no lead for
> now.

As far as I'm aware systemd will mount a tmpfs on /run itself on
startup, but the directory needs to exist first.

Ross

Re: systemd: /run directory not created

[Enrico Scholz]

Radu Moisan <radu.moisan-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
writes:

>>> Possibly because /run was a link created by the initscripts which
>>> are now disabled when systemd is the init manager. I'll look into
>>> this and update 00-create-volatile.conf so that systemd will handle
>>> the link creation in stead.
>> I wonder how my images booted...  initscripts is sysvinit specific,
>> the systemd startup should handle this somehow.
>>
>> (insert standard argument that we should adopt /run across all init
>> systems)

yes; that's the best way.  Make /var/run a symlink pointing to /run.


> This is exactly what I was looking for. /run shouldn't be there, yet
> somehow it is. I was looking into how/where systemd is creating /run
> but no lead for now.

/run is part of systemd's api and mounted very early internally by
systemd.  This mountpoint must exist in the filesystem and it will
probably not work when it is symlink into /var/volatile which gets
mounted later.


Enrico

Re: systemd: /run directory not created

[Radu Moisan]

On 01/24/2013 02:20 PM, Enrico Scholz wrote:
> Radu Moisan <radu.moisan-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> writes:
>
>>>> Possibly because /run was a link created by the initscripts which
>>>> are now disabled when systemd is the init manager. I'll look into
>>>> this and update 00-create-volatile.conf so that systemd will handle
>>>> the link creation in stead.
>>> I wonder how my images booted...  initscripts is sysvinit specific,
>>> the systemd startup should handle this somehow.
>>>
>>> (insert standard argument that we should adopt /run across all init
>>> systems)
> yes; that's the best way.  Make /var/run a symlink pointing to /run.
>
>
>> This is exactly what I was looking for. /run shouldn't be there, yet
>> somehow it is. I was looking into how/where systemd is creating /run
>> but no lead for now.
> /run is part of systemd's api and mounted very early internally by
> systemd.  This mountpoint must exist in the filesystem and it will
> probably not work when it is symlink into /var/volatile which gets
> mounted later.
>
>
Isn't systemd looking into fstab.systemd for mount points?

Radu

Re: systemd: /run directory not created

[Enrico Scholz]

Radu Moisan <radu.moisan-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
writes:

>> /run is part of systemd's api and mounted very early internally by
>> systemd.  This mountpoint must exist in the filesystem and it will
>> probably not work when it is symlink into /var/volatile which gets
>> mounted later.
>
> Isn't systemd looking into fstab.systemd for mount points?

not for /run or /proc or so. In src/core/mount-setup.c there is a
'mount_table[]' list which is evaluated before fstab is parsed.  You
can override this by setting $SYSTEMD_SKIP_API_MOUNTS but this will
create other problems.


Enrico

Re: systemd: /run directory not created

[Radu Moisan]

On 01/24/2013 02:53 PM, Enrico Scholz wrote:
> Radu Moisan <radu.moisan-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> writes:
>
>>> /run is part of systemd's api and mounted very early internally by
>>> systemd.  This mountpoint must exist in the filesystem and it will
>>> probably not work when it is symlink into /var/volatile which gets
>>> mounted later.
>> Isn't systemd looking into fstab.systemd for mount points?
> not for /run or /proc or so. In src/core/mount-setup.c there is a
> 'mount_table[]' list which is evaluated before fstab is parsed.  You
> can override this by setting $SYSTEMD_SKIP_API_MOUNTS but this will
> create other problems.
>
>
ok, thanks Enrico, this clears the picture for me.
Well then it looks like Jack's problems is coming from some other place.

Radu

Re: systemd: /run directory not created

[Burton, Ross]

On 24 January 2013 13:03, Radu Moisan <radu.moisan@intel.com> wrote:
> ok, thanks Enrico, this clears the picture for me.
> Well then it looks like Jack's problems is coming from some other place.

No - /run needs to exist for the mount to happen, and there isn't a
/run in the filesystem.  Whatever creates the root filesystem
structure should also create /run I guess.

Ross

Re: systemd: /run directory not created

[Radu Moisan]

On 01/24/2013 04:52 PM, Burton, Ross wrote:
> On 24 January 2013 13:03, Radu Moisan <radu.moisan@intel.com> wrote:
>> ok, thanks Enrico, this clears the picture for me.
>> Well then it looks like Jack's problems is coming from some other place.
> No - /run needs to exist for the mount to happen, and there isn't a
> /run in the filesystem.  Whatever creates the root filesystem
> structure should also create /run I guess.

I agree, but what I meant was that my initial assumptions were wrong 
with concern to Jack's problem. I run it on qemu and /run is there. His 
problem related to /run creation while I was thinking about mounting issue.

Radu

Re: systemd: /run directory not created

[Jack Mitchell]

On 25/01/13 08:28, Radu Moisan wrote:
>
> On 01/24/2013 04:52 PM, Burton, Ross wrote:
>> On 24 January 2013 13:03, Radu Moisan <radu.moisan@intel.com> wrote:
>>> ok, thanks Enrico, this clears the picture for me.
>>> Well then it looks like Jack's problems is coming from some other 
>>> place.
>> No - /run needs to exist for the mount to happen, and there isn't a
>> /run in the filesystem.  Whatever creates the root filesystem
>> structure should also create /run I guess.
>
> I agree, but what I meant was that my initial assumptions were wrong 
> with concern to Jack's problem. I run it on qemu and /run is there. 
> His problem related to /run creation while I was thinking about 
> mounting issue.
>
> Radu
>

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.

Regards

-- 

   Jack Mitchell (jack@embed.me.uk)
   Embedded Systems Engineer
   http://www.embed.me.uk

--

Re: systemd: /run directory not created

[Burton, Ross]

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

Re: systemd: /run directory not created

[Jack Mitchell]

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.

-- 

   Jack Mitchell (jack@embed.me.uk)
   Embedded Systems Engineer
   http://www.embed.me.uk

--

Re: systemd: /run directory not created

[Jack Mitchell]

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.
>

 From a quick look it seems as though volatiles in initscripts-1.0 
should create the run directory if it's not found. However the 
initscripts package doesn't get pulled in on my image at all, and I 
can't see an equivalent in the systemd package.



-- 

   Jack Mitchell (jack@embed.me.uk)
   Embedded Systems Engineer
   http://www.embed.me.uk

--

Re: systemd: /run directory not created

[Jack Mitchell]

On 02/14/13 15:57, Jack Mitchell 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.
>>
>
> From a quick look it seems as though volatiles in initscripts-1.0 
> should create the run directory if it's not found. However the 
> initscripts package doesn't get pulled in on my image at all, and I 
> can't see an equivalent in the systemd package

Doing a manual ln -s var/run run on my mounted SD card gets systemd to 
the first [OK] part but then the board dies on me, it's a usb ftdi 
serial and even that connection gets wiped. I think there is something 
fundamentally wrong somewhere, which is causing the systemd setup to not 
execute properly, or the fact that there are minimal packages and 
minimal features in my distro image is causing the problem.

What I will maybe try to do tomorrow is build a stock core-image-minimal 
with systemd, then remove distro features one by one and see if it breaks.

Re: systemd: /run directory not created

[Khem Raj]

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

Re: systemd: /run directory not created

[Jack Mitchell]

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...


-- 

   Jack Mitchell (jack@embed.me.uk)
   Embedded Systems Engineer
   http://www.embed.me.uk

--

Re: systemd: /run directory not created

[Jack Mitchell]

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

--

Re: systemd: /run directory not created

[Jack Mitchell]

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.....




-- 

   Jack Mitchell (jack@embed.me.uk)
   Embedded Systems Engineer
   http://www.embed.me.uk

--

Re: systemd: /run directory not created

[Jack Mitchell]

Ok, I have just come back to trying out the new systemd implementation, 
and this bug still exists.

Exactly the same error as before:

[    2.390730] systemd[1]: Failed to mount /run: No such file or directory

Can we shed any light on why this directory is failing to be created and 
what can be done to fix it. Having looked in my final target filesystem 
there are no links to the volatiles in /var/voltatile/* to /*, should 
there be? The base-files packages looks like it should do it but 
obviously something is going wrong.

   for d in ${volatiles}; do
     ln -sf volatile/$d ${D}${localstatedir}/$d
   done

Cheers,
Jack.

-- 

   Jack Mitchell (jack@embed.me.uk)
   Embedded Systems Engineer
   http://www.embed.me.uk

--

Re: systemd: /run directory not created

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1072 bytes --]

On Mon, Apr 15, 2013 at 01:58:52PM +0100, Jack Mitchell wrote:
> Ok, I have just come back to trying out the new systemd implementation, 
> and this bug still exists.
> 
> Exactly the same error as before:
> 
> [    2.390730] systemd[1]: Failed to mount /run: No such file or directory
> 
> Can we shed any light on why this directory is failing to be created and 
> what can be done to fix it. Having looked in my final target filesystem 
> there are no links to the volatiles in /var/voltatile/* to /*, should 
> there be? The base-files packages looks like it should do it but 
> obviously something is going wrong.
> 
>    for d in ${volatiles}; do
>      ln -sf volatile/$d ${D}${localstatedir}/$d
>    done

We're using base-files bbappend to create it and also replacing few
symlinks to volatile with real directories (not mandatory for systemd
iirc, but useful in some cases).

https://github.com/shr-distribution/meta-smartphone/commit/24161eed3c185867b2fd91aab6532f370d327cdd

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: systemd: /run directory not created

[Jack Mitchell]

On 15/04/13 14:10, Martin Jansa wrote:
> On Mon, Apr 15, 2013 at 01:58:52PM +0100, Jack Mitchell wrote:
>> Ok, I have just come back to trying out the new systemd implementation,
>> and this bug still exists.
>>
>> Exactly the same error as before:
>>
>> [    2.390730] systemd[1]: Failed to mount /run: No such file or directory
>>
>> Can we shed any light on why this directory is failing to be created and
>> what can be done to fix it. Having looked in my final target filesystem
>> there are no links to the volatiles in /var/voltatile/* to /*, should
>> there be? The base-files packages looks like it should do it but
>> obviously something is going wrong.
>>
>>     for d in ${volatiles}; do
>>       ln -sf volatile/$d ${D}${localstatedir}/$d
>>     done
> We're using base-files bbappend to create it and also replacing few
> symlinks to volatile with real directories (not mandatory for systemd
> iirc, but useful in some cases).
>
> https://github.com/shr-distribution/meta-smartphone/commit/24161eed3c185867b2fd91aab6532f370d327cdd
>

Ok, manually adding /run to 775dirs in a base-files append fixed this 
for me. I still don't understand why this should be needed as an 
addition though...

-- 

   Jack Mitchell (jack@embed.me.uk)
   Embedded Systems Engineer
   http://www.embed.me.uk

--

Re: systemd: /run directory not created

[Jonathan Liu]

On 15/04/2013 11:45 PM, Jack Mitchell wrote:
> On 15/04/13 14:10, Martin Jansa wrote:
>> On Mon, Apr 15, 2013 at 01:58:52PM +0100, Jack Mitchell wrote:
>>> Ok, I have just come back to trying out the new systemd implementation,
>>> and this bug still exists.
>>>
>>> Exactly the same error as before:
>>>
>>> [    2.390730] systemd[1]: Failed to mount /run: No such file or 
>>> directory
>>>
>>> Can we shed any light on why this directory is failing to be created 
>>> and
>>> what can be done to fix it. Having looked in my final target filesystem
>>> there are no links to the volatiles in /var/voltatile/* to /*, should
>>> there be? The base-files packages looks like it should do it but
>>> obviously something is going wrong.
>>>
>>>     for d in ${volatiles}; do
>>>       ln -sf volatile/$d ${D}${localstatedir}/$d
>>>     done
>> We're using base-files bbappend to create it and also replacing few
>> symlinks to volatile with real directories (not mandatory for systemd
>> iirc, but useful in some cases).
>>
>> https://github.com/shr-distribution/meta-smartphone/commit/24161eed3c185867b2fd91aab6532f370d327cdd 
>>
>>
>
> Ok, manually adding /run to 775dirs in a base-files append fixed this 
> for me. I still don't understand why this should be needed as an 
> addition though...
>
I get this error booting hdddirect/vmdk image (no initrd) but not when 
booting hddimg (uses initrd).

Regards,
Jonathan

Re: systemd: /run directory not created

[Jonathan Liu]

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