+++ 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/ -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
