Dumping sysvinit

Dumping sysvinit

[Andy Pont]

Hello,

Bit of a newbie question (probably) but what is the easiest way to dump
sysvinit and use Busybox init in a core-image-minimal image?

Thanks,

Andy.

Re: Dumping sysvinit

[Mark Hatle]

On 9/15/15 6:16 AM, Andy Pont wrote:
> Hello,
> 
> Bit of a newbie question (probably) but what is the easiest way to dump
> sysvinit and use Busybox init in a core-image-minimal image?

It has been a while since I've done this.  But unless things have changed
dramatically.  You will need to define your own custom image.

One that does not include the sysvinit component or base initscripts.  You will
then have to provide your own base initscripts for your system to startup and
function.  (You might be able to copy some from the initscripts, but many expect
the sysvinit [or systemd] to be present on the device.)

You are moving into pure custom boot optimization and implementation at this point.

--Mark

> Thanks,
> 
> Andy.
> 
> 

Re: Dumping sysvinit

[Andy Pont]

Mark wrote...

> > Bit of a newbie question (probably) but what is the easiest way to dump
> > sysvinit and use Busybox init in a core-image-minimal image?
> 
> It has been a while since I've done this.  But unless things have changed
> dramatically.  You will need to define your own custom image.

On the basis that sounded like more hard work than I have time for I thought
I would try switching to systemd.  Following the instructions in the dev
manual [1].

If I add the extra variables to build/conf/local.conf then with the machine
type set to genericx86 I get this build error:

ERROR: Function failed: do_configure (log file is located at
XXXXX/build/tmp/work/x86_64-linux/qemu-native/2.2.0-r1/temp/log.do_configure
.1926)
ERROR: Logfile of failure stored in:
XXXXX/build/tmp/work/x86_64-linux/qemu-native/2.2.0-r1/temp/log.do_configure
.1926
Log data follows:
| DEBUG: Executing python function sysroot_cleansstate
| DEBUG: Python function sysroot_cleansstate finished
| DEBUG: Executing shell function autotools_preconfigure
| DEBUG: Shell function autotools_preconfigure finished
| DEBUG: Executing python function autotools_copy_aclocals
| DEBUG: Python function autotools_copy_aclocals finished
| DEBUG: Executing shell function do_configure
| 
| ERROR: User requested feature sdl
|        configure was not able to find it.
|        Install SDL devel

I'm guessing that this is me being dim and that build/conf/local.conf isn't
what the documentation refers to as "your distribution configuration file".
Can someone point me in the right direction?

Thanks,

Andy.

[1]
http://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html#selecting-an
-initialization-manager

Re: Dumping sysvinit

[Trevor Woerner]

On 09/15/15 12:03, Andy Pont wrote:
> Mark wrote...
>
>>> Bit of a newbie question (probably) but what is the easiest way to dump
>>> sysvinit and use Busybox init in a core-image-minimal image?
>> It has been a while since I've done this.  But unless things have changed
>> dramatically.  You will need to define your own custom image.
> On the basis that sounded like more hard work than I have time for I thought
> I would try switching to systemd.  Following the instructions in the dev
> manual [1].
>
> If I add the extra variables to build/conf/local.conf then with the machine
> type set to genericx86 I get this build error:
>
> ERROR: Function failed: do_configure (log file is located at
> XXXXX/build/tmp/work/x86_64-linux/qemu-native/2.2.0-r1/temp/log.do_configure
> .1926)
> ERROR: Logfile of failure stored in:
> XXXXX/build/tmp/work/x86_64-linux/qemu-native/2.2.0-r1/temp/log.do_configure
> .1926
> Log data follows:
> | DEBUG: Executing python function sysroot_cleansstate
> | DEBUG: Python function sysroot_cleansstate finished
> | DEBUG: Executing shell function autotools_preconfigure
> | DEBUG: Shell function autotools_preconfigure finished
> | DEBUG: Executing python function autotools_copy_aclocals
> | DEBUG: Python function autotools_copy_aclocals finished
> | DEBUG: Executing shell function do_configure
> | 
> | ERROR: User requested feature sdl
> |        configure was not able to find it.
> |        Install SDL devel
>
> I'm guessing that this is me being dim and that build/conf/local.conf isn't
> what the documentation refers to as "your distribution configuration file".
> Can someone point me in the right direction?

I think the qemu build is looking for your build machine's native SDL
(or SDL-devel) so that the resulting qemu can run. Usually a
conf/local.conf includes the following lines:

    PACKAGECONFIG_append_pn-qemu-native = " sdl"
    PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl"
    ASSUME_PROVIDED += "libsdl-native"

I think if you remove/comment-out the last of those 3 lines or install
your host's SDL-devel package you'll solve this issue (?)

Re: Dumping sysvinit

[Burton, Ross]

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

On 15 September 2015 at 17:27, Trevor Woerner <twoerner@gmail.com> wrote:

> I think if you remove/comment-out the last of those 3 lines or install
> your host's SDL-devel package you'll solve this issue (?)
>

Yes, that's right.  Either disable the graphical qemu support, or install
the host's sdl-devel package so it can build.

Ross

[-- Attachment #2: Type: text/html, Size: 758 bytes --]

Re: Dumping sysvinit

[Andy Pont]

Hello all,

> > I think if you remove/comment-out the last of those 3 lines or install
> > your host's SDL-devel package you'll solve this issue (?)
> >
> Yes, that's right.  Either disable the graphical qemu support, or install
> the host's sdl-devel package so it can build.

On my CentOS 6.7 host system running the package manager reports that SDL-devel is already installed:

# yum install SDL-devel
Package SDL-devel-1.2.14-6.el6.x86_64 already installed and latest version
Nothing to do

This is probably something to do with the fact that in order to get Fido to build I have to use the devtoolset-2.1 package to get a recent gcc version and it probably isn't aware of the standard SDL-devel libraries.

Commenting out just the last line of the 3 QEMU/SDL related lines throws out a couple of errors whereas removing all of them gives me a build.

Now to figure out why the tar.gz file for the root file system has grown from just under 3MiB to almost 15MiB!

Thanks for all the help and advice.

Andy.

Re: Dumping sysvinit

[Burton, Ross]

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

On 16 September 2015 at 10:24, Andy Pont <andy.pont@sdcsystems.com> wrote:

> Now to figure out why the tar.gz file for the root file system has grown
> from just under 3MiB to almost 15MiB!
>

That would be systemd... it pulls in a lot of libraries that are fairly
common on complex systems but on a minimal image less so.

Ross

[-- Attachment #2: Type: text/html, Size: 747 bytes --]

Re: Dumping sysvinit

[Andy Pont]

Ross wrote...

> > Now to figure out why the tar.gz file for the root file system has grown 
> > from just under 3MiB to almost 15MiB!
> 
> That would be systemd... it pulls in a lot of libraries that are fairly common
> on complex systems but on a minimal image less so.

Back to plan A then, trying to figure out how to get Busybox init and mdev as the defaults in the image.

Thanks for the feedback!

Andy.

Re: Dumping sysvinit

[Mike Looijmans]

On 16-09-15 16:13, Andy Pont wrote:
> Ross wrote...
>
>>> Now to figure out why the tar.gz file for the root file system has grown
>>> from just under 3MiB to almost 15MiB!
>>
>> That would be systemd... it pulls in a lot of libraries that are fairly common
>> on complex systems but on a minimal image less so.
>
> Back to plan A then, trying to figure out how to get Busybox init and mdev as the defaults in the image.

Create your own distro, here's an example that uses mdev:

https://github.com/topic-embedded-products/meta-topic/blob/master/conf/distro/tiny.conf

Re: Dumping sysvinit

[Andy Pont]

Hi Mike,

> > Back to plan A then, trying to figure out how to get Busybox init and
> mdev as the defaults in the image.
> 
> Create your own distro, here's an example that uses mdev:
> 
> https://github.com/topic-embedded-products/meta-
> topic/blob/master/conf/distro/tiny.conf

Thanks for pointing me in the direction of this.  I have cloned it and used
it as the basis of my distro, tweaked it a bit and it is starting to behave
how I want.  There are a few anomalies that I haven't managed to figure out
yet...

Despite having VIRTUAL-RUNTIME_initscripts = "" the root file system still
contains /etc/rcX.d directories

On other embedded Linux projects that boot using Busybox init the
/etc/init.d directory contained the individual service start and kill files
e.g. S50-dropbear and K50-dropbear but I can't see how to make Yocto
populate this directory in that form.

Thoughts and guidance from anyone would be much appreciated!

Andy.

Re: Dumping sysvinit

[Mike Looijmans]

On 21-09-15 12:48, Andy Pont wrote:
> Hi Mike,
>
>>> Back to plan A then, trying to figure out how to get Busybox init and
>> mdev as the defaults in the image.
>>
>> Create your own distro, here's an example that uses mdev:
>>
>> https://github.com/topic-embedded-products/meta-
>> topic/blob/master/conf/distro/tiny.conf
>
> Thanks for pointing me in the direction of this.  I have cloned it and used
> it as the basis of my distro, tweaked it a bit and it is starting to behave
> how I want.  There are a few anomalies that I haven't managed to figure out
> yet...
>
> Despite having VIRTUAL-RUNTIME_initscripts = "" the root file system still
> contains /etc/rcX.d directories
>
> On other embedded Linux projects that boot using Busybox init the
> /etc/init.d directory contained the individual service start and kill files
> e.g. S50-dropbear and K50-dropbear but I can't see how to make Yocto
> populate this directory in that form.
>
> Thoughts and guidance from anyone would be much appreciated!

I didn't go as far as attempting to get rid of initscripts as well. I just 
patched the initscripts to remove the things I did not want in a 
do_install_append.

Many recipes will create /etc/rcX.d entries to start/stop things.



Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijmans@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail