Re: Platform-specific bootstrapping packages?
+++ Bill Gatliff [2010-03-15 10:08 -0500]:
> Guys:
>
>
> Today I use debootstrap to create a basic root filesystem for a foreign
> architecture, and then manually tweak the fstab and inittab files before
> booting into that filesystem to run --second-stage. That process works
> fine, but I'm wondering if there's a way to eliminate that manual step
> by changing or augmenting the package set that debootstrap performs the
> first-stage from.
Multistrap is much nicer than debootstrap for this purpose (and what I
now use for this task). The biggest advantage is that the produces
image is much smaller because it doesn't contain both all the original
package _and_ all the unpacked packages) which is what debootstrap does.
The second biggest is that you can take packages from more than one
repository. So we use emdebian grip for most stuff, debian for
packages that aren't in there and our local repo for all the special
local magic (often proprietary) stuff to go on this particular device.
The 'second stage' still needs to be done on the real device but is a
standard apt-get install -f rather than debootstrap's magic
--second-stage.
The getting in of local config is a thorny issue. I've tried various
things.
> One obvious approach is to hack the main repo packages, and then
> distribute them from a platform-specific repository. That makes it
> certain that the hacks won't be distributed in any other way, however,
> e.g. the main Debian repositories.
This is probably the only fooproof way to do it, but the problem is
that if all you want to do is change the default console in the
inittab it's tiresome having to maintain a corresponding version of
inittab, when Debian/emdebian keep putting in new ones.
> Another idea is to have a platform-specific package that performs the
> tweaks to fstab, inittab, etc., and then include that package in the
> debootstrap first-stage step. If that package's preinst could do
> everything, then what would be left at the end of first-stage would be a
> truly bootable filesystem. Such a package could be distributed in the
> main debian repositories, because it wouldn't require changes to the
> main packages.
So we did this with balloon3-config. It sort-of works, but there are
problems. You can't guarantee that this package will be unpacked first
(or last) so the files it writes may get overwritten by the package
that really owns them. Or you may just get a conflict and either this
package, or another simply won't get configured. It can just be a
script to avoid simple file clasheds, but the ordering problem
remains, and if you upgrade the packages who's files it has messed
with later than the changed config can get changed back (if done to
non-config config files).
You also can't do things like tidy the apt cache: when we were still
using debootstrap we tried to clear out /var/cache/apt/archives to get
rid of the 40MB of guff in there but if this package gets installed
anything other than last then suddenly the archives disappear and
don't get installed until the system gets a chance to download and
install them again.
Equally there are some things that need to be done at 'second-stage'
time, and those are suited to being done in a config-package. e.g.
setting passwords, generating local keys. For these a config-package
is ideal, and balloon3-0config has been relegated to this role.
Other file changes are now done in a 'rootfs-config' script that is
run after multistrap is done unpacking. This works so long as you only
want to change config-files (i.e not owned by a particular package),
and the postinst script of thepackage which does normally create it is
prapred to accept a pre-existing file. This seems to be true of most
of the normal base-files type stuff you might want to fiddle with, but
I can imagine more invasive changes which don't work so well. Anything
you replace here which is owned by a package will get reverted if the
package is re-installed/upgraded. I guess we could use the dpkg-divert
feature to do this properly.
> Yet another alternative is to just craft a debinst for the target. That
> seems like more trouble than it's worth, especially if I want to
> automate rootfs creation.
You mean a debian-installer? Biggest problem there for years has been
lack of flash support. That is now somewhat fixed, but you still have
to do the whole install on the device itself which is intolerably slow
for a production environment.
> Anyone have any ideas and/or suggestions? Is there some obvious reason
> why having a platform-specific package to feed through debootstrap
> _wouldn't_ work?
It does work, but with the significant limitations listed. As
discussed in the multstrap thread we are looking at adding
machine:variant rootfs-creation-time config to multistrap to at least
make it easy to run a hacky script at the right time.
Working out the best way to put in, and maintain, a set of
machine-specific changes is a useful task. Modifying upstream packages
seems to be the only fully reliable and generic way, but that can be
labour-intensive.
I'd like to hear what others have found does and does not work.
Wookey
--
Principal hats: iEndian - Balloonboard - Toby Churchill - Emdebian
http://wookware.org/
Reply to: