[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: some issues with the init scripts and other stuff as well... :)

On Thu, 2008-08-28 at 00:29 +0100, chgans wrote:
> Hi all,
> OK, this is not a bug report, but it's time to go to bed now! 

I really would prefer bug reports simply because it helps me show that
the changes Emdebian will need to make in Debian after the Lenny release
are being made due to real user problems - i.e. things will be a lot
easier for me with an "audit trail" of bug reports (which are far easier
to track than mailing list posts). For this reason, individual problems
need also to be separated into individual bug reports.

Whilst we are waiting for the pseudo-package, those bugs need to be
filed against emdebian-tools with a wishlist or minor severity - I'll
organise the tags and re-assigns later.

> I prefer 
> to send an email on the list to avoid to forget everything, as I'll be 
> out of the office until Monday (This follows discussion on IRC).

OK, even if I fix most of these things by then, I'd still like bug
reports that I can track whilst in Extremadura. Thanks.

> * /etc/rc.d/udev-mtab use "grep --quiet --no-messages", which 
> busybox's grep doesn't understand, should use "grep -q -s"

This is part of the reasoning - there may well be cases where we can
either change the busybox config or make patches for inclusion into
busybox upstream to enable the few extra bytes that allows busybox to
understand that --quiet == -q. This is a much more sustainable fix than
patching the Debian package or expecting every Debian package to switch
to short options.

Bug reports will help me optimise the busybox config so that the
majority of users are happy whilst providing clear guidance on what
options people need to retain in their customised builds of busybox for
devices that need that. Mailing list posts just get lost in the archive,
bug reports show up on all my tracking pages and can be reorganised
quickly and repeatedly, as appropriate.

> * mountoverflowtmp: df -kP | grep -v Filesystem => df -k | grep -v 
> Filesystem
>    Not sure about the impact of not using -P (posix compatibility)
>    The only difference with -P on a debian machine is the header of 
> the output, which is ignore by the script via the grep -v

Another situation where there might be a need to fix the Debian package
to not be so picky - then, in consultation with the maintainer, we can
work out whether -P is used for some ports (maybe hurd-i386 or
kfreebsd-amd64 etc.) or just out of habit.

> * when installing ssh client and server
> /var/lib/dpkg/info/openssh-server.postinst: line 453: perl: not found
> /var/lib/dpkg/info/openssh-client.postinst: line 51: syntax error: "}" 
> unexpected

That is a bug in emdebian-tools - lintian should have caught that.
Please report it, including the full lintian report from using:
$ lintian -iIC em /path/to/.changes

> Then i tried to make some changes to update-rc.d, i've attached the 
> file, there are some comments in the header about why and how i did 
> that (it's just an idea, experimental stuff).

update-rc.d can be replaced using machine-variant support during

There are five ways of modifying files in the root filesystem (in order
of the point at which the change is actioned):

modified suite script - if you want to drop / reorder certain components
of the debootstrap process beyond simply changing the package selection.
Requires some familiarity with debootstrap processes.

packages.conf - to add packages, mirrors or proxies, rename the tarball,
specify the kernel image/modules location, etc.

$machine-config - bespoke package if the change needs to replace the
default Emdebian files or simply to collate changes for similar devices.
(Possibly using the PROXY or MIRROR settings of packages.conf). Certain
default files may already exist but package files will be used instead
of the default files as long as the files exist in the package (i.e.
listed in dpkg -c foo.deb). Maintainer scripts in the -config package
are processed as normal by ./emsecondstage. Files generated from -config
maintainer scripts might need to replace the Emdebian default file.
Overall, this is the easiest method.

setup.sh - if the change is first needed before creating the rootfs
tarball (i.e. before running ./emsecondstage) and can be done from the
build machine (binaries within the rootfs cannot be executed). This is
where you can replace any file that is called by the maintainer scripts,
e.g. update-rc.d because packages have been unpacked but are not yet

config.sh - if the change is only needed before the first boot
(after ./emsecondstage) or if the change needs to be made by running
binaries within the rootfs. config.sh can assume that all packages are
fully configured on the target device before it is called and it can
assume that it is running on the target device (albeit within a chroot).
config.sh is provided to support modifying the results of running the
maintainer scripts, should things go wrong, or other tasks necessary
prior to the first boot and is the only method that can execute binaries
on the target device.

> Actually i tried to rely as much as possible on the debian init 
> scripts, i would like to use only this in my inittab:
> # /etc/inittab
> # Note: BusyBox init doesn't support runlevels.
> # Start-up the system
> ::sysinit:/etc/init.d/rcS start
> # Put a getty on the console
> ttyAM0::respawn:/sbin/getty -L ttyAM0 115200 vt100
> # Stuff to do before rebooting
> ::shutdown:/etc/init.d/rcS stop

You can do so either by writing this in setup.sh or (if you have a few
changes to make) by packaging the file in a package - as we do with

If you use a local repository with emsandbox, put the package into that
repository and add the name of that package to your packages.conf
INCLUDE and the repository to PROXY or MIRROR. (MIRROR will be used as
the default apt source for the device after installation, PROXY is

If you want the -config package to be included in Emdebian, it would
need to be sufficiently generic (or have suitable maintainer scripts) to
cope with most (if not all) variants of the machine in question and then
be called $machine-config. As with any other package, it needs to be
compliant with Debian Policy and the DFSG (and then built in Emdebian to
comply with Emdebian Policy). This means making the source package
(.dsc) available so that I can use 'apt-get source' to cross-build it.
Most -config packages will be Architecture: all but will still be
cross-built to remove docs etc. In reality, most -config packages will
only be usable on one specific architecture or a few related
architectures (like arm and armel).

If anyone fancies integrating some of that into the Wiki . . . . 


Neil Williams

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: