[ELDK] Just starting - ipkg errors

[Wolfgang Denk]

Dear Larry,

In message <BF378513-2519-4847-B86A-8214A478A984 at usgs.gov> you wrote:
> 
> > Well, the "basic" in the name really means what it says: this is a
> > root file system which contains just the very basic tools needed to
> > run a system.  Package management is not considered such a basic tool,
> > so it is not included here.  And without a package database you cannot
> > get any package information.
> 
> The name I use is from the table in the ELDK home page, 1.5. Supported Target Configurations.
> 
> Perhaps I misunderstood the FAQ.

Maybe the FAQ was not explicit enough about the assumptions it was
based on.  Please re-read it now.  I added the following explanation:

	Note: All tools working with software packages have to
	maintain a certain "package database". This may be a real
	database (like Berkeley DB files as used by the rpm tool), or
	a plain text file (like used by the ipkg tool). The important
	message is: without such package database, you will not be
	able to work with packages, like adding new, or listing,
	removing or updating already installed ones.

	The following operations will therefore only be possible on
	file system images that contain such package information. Note
	that most of the "small" root file system images in ELDK (say,
	core-image-minimal or core-image-basic) do not contain any
	package database.

Hope this helps to avoid future confusions.

> I am looking for the commands to execute on the development host
> that will list the packages that are installed on any of the ELDK
> root file systems. I consulted the FAQ and found what appears to be
> exactly that. This is the FAQ question:

This is impossible.  With the ready-to-use file system images, you can
use packing tools only if the required package information is included
with the image.  You cannot operate on any information that is not
present at all.

> This response makes sense to me regarding a package manager on the
> target. I understand that the basic rootfs does not include a package
> manager; I do not want a package manager on the target.

It does not only not contain a package manager, it also does not
contain any packaga database information.

> I have looked at the different ELDK root file systems for the
> services I need. The basic rootfs is the closest. Now I wish to add
> and remove packages from that rootfs. I assumed these example root
> file systems could be customized by adding and removing packages, but
> I do not know how.

The best way to do this is to build a new file system image customized
to your requirements.  that means starting from the source, creating
your own biuld target (by copying one of the existing ones - here say
core-image-basic.bb and modifying it according to your needs), and
then building it.  You may find HOB [1], a graphical user interface
for BitBake, to be helpful, at least for the first steps.

[1] https://www.yoctoproject.org/documentation/hob-manual

> I configured a Linux 3.2.48 kernel with support for systemd, since
> I did not know which init system ELDK uses. I saw the SystemV-style
> links, which is what CentOS uses. I am familiar with
> chkconfig/service on CentOS. I saw chkconfig in the list of ELDK
> packages. I did not know if there was a different command already
> installed on the basic rootfs that I could use. I have seen that
> Debian uses different commands for this purpose. And, systemd uses
> one command, systemctl, to both enable/disable and start/stop
> installed services. I'm trying to learn how to do things the ELDK
> way.

Actually ELDK inherits all these things from the Yocto Project, so
this is more talking about Yocto ways than ELDK ways.  Note that I'm
using the plural form here, as there is not a single, prescribed way
that everybody has to use; instead, Yocto / ELDK offers you the
freedom to chose whichever tools you consider useful for your target
configuration.  The provided root file system images are intended to
allow you  quick start, to have your system running with some
predefined configurations very quickly.  But these are just examples,
which you can copy, or modify, when designing your own target root
file system.

> chkconfig and service will be the tools to manage services on the
> target, exactly as I do on my CentOS systems. This is perfect. I'll
> figure out if the service command is part of the chkconfig package.

It is not. Normally, in standard distributions like Fedora or CentOS,
"service" is part of the (SystemV) initscripts package.  However, the
"initscripts" package as included with OE/Yocto/ELDK does not include
such a script.

> If not, can easily write it.

Or copy it from your host system.

> On the development host, I will use a "machine configuration" to
> either build my own rootfs or modify the basic rootfs (which?). This

Not quite.  A machine configuration describes the hardware you are
running on, i. e. for example the processor architecture etc., but
this is completely independent from the actual content of any root
file system image you may generate.  It will most probably make sense
that you define a custome machine matching your own hardware, but you
will _also_ have to define your own root file system image - these are
two separate tasks.

> sounds like exactly what I need to do next. But, I don't know how to
> do this. Where can I learn these steps? Is there a tutorial anywhere,
> for example, where I can learn the steps to replicate the basic
> rootfs image? (When I develop systems on new hardware/software, I
> like to use the vendor tools to replicate the factory installation. I
> learn about their development process, and I then have a procedure to
> start over from bare metal when I brick the system.)

Please refer to the Yocto Project documentation.  This has lots of
information about all these topics.

Note however that you are entering a very complex set of topics here.
This is not a failure of Yocto, but the comlexity is inherent to the
class of problems we have to solve here (all other build systems are
similar complex).  You have been warned. Here Abide Monsters And
Dragons.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The amount of time between slipping on the peel and  landing  on  the
pavement is precisely 1 bananosecond.